The irony of revolutionary technologies is that it can often be a challenge to figure out what to do with them. Take the Internet of Things (IoT). Very interesting! Soon there will be loads of devices and sensors communicating with each other autonomously! A new frontier! But how does this help us solve the daily problems of human beings and businesses? Will people embrace or reject the applications we invent? What can we do to ensure that people will buy or accept this new technology?

These are not trivial questions.

You can sink a lot of money, time, hopes and dreams into developing a product or service based on cutting-edge technology. If you get it right, you can be a super star. But if people aren’t ready for what you’ve built or you missed an important aspect that makes people shy away from it, then it’s game over.

This is as true for IoT, self-driving cars, robotics, etc. as it is for digital assistants (which, stay with me, will be the focus of this blog).

Meeting users’ expectations and goals

When we think of getting a cutting-edge product or service right, we often think of getting the technology right. And although that is hard and important, what’s also hard and important is making sure that people are going to need or want the product or service we are creating.

The way to get that right is through user experience (UX) research. This means that UX researchers and others in the project team use observation techniques, task analysis, and feedback methodologies to understand how people behave and what motivates them. You may be thinking, “Why all the fuss? Why don’t they just ask people? How hard can that be?” Well, that’s the tough thing. People often have a hard time explaining in enough detail what they actually do and find it difficult to express their real needs and motivations. UX researchers usually have a background in psychology as well as a large toolbox of methods from which to choose in order to get accurate and useful feedback from users. And of course, the feedback they get from many different users has to be synthesized and converted into input that a product team can act on and incorporate into their product development.

Furthermore, each project and each phase of a project has different needs. If you are already in beta, the time for blue sky requirements gathering has past. Similarly nonsensical is usability testing if you are so early in the project that there is no prototype or product to test yet.

Conducting UX research for SAP CoPilot

For SAP CoPilot, our new digital assistant for the enterprise, a team of UX researchers from SAP is currently working with the product team to:

  • learn how people would interact with a digital assistant in a work environment
  • understand and define how SAP CoPilot can assist support personnel in the process of handling users problems with a product (known as Digital Support Experience, which we will talk about more in the next blog in this series)
  • learn what language people use when talking to a virtual agent and share that input with the team developing a conversational UI engine for SAP CoPilot

Over the course of the last 9 months, the team has brought together customers, IT experts, business experts, and potential end users to conduct their research. Some of the research methods sound straight-forward, like 1:1 on-site interviews, customer workshops, and usability tests, whereas others sound very exotic, for example:

  • Wizard of Oz studies” allow the team to observe how participants interact with a digital assistant through a conversational user interface. Here a human being in another location “plays” the part of the system and interacts with the test participant as if he or she were a digital assistant. This interaction gives the team many insights into how people would expect and like a digital assistant to respond.
  • With the “fishbowl approach,” a few chairs are placed in the center of a large room. More chairs are arranged in concentric circles around the center “fishbowl” chairs. A conversation among those people sitting in the middle – and intermittent participation from those sitting outside of the center – help the team to understand how employees with the target profile work today and how SAP CoPilot could help them do their work better in the future.
  • The Future/Current/Barriers method helps the team to understand today’s barriers and pain points in users’ current work process and what could hinder them from applying CoPilot in the future.

I asked Conny Kinateder, lead UX researcher for SAP CoPilot, which findings surprised her the most by the research so far. “In a typical UX research project, we may need 2 or 3 different methods to get the input we need to move forward. For this project we have used 7 so far and there is no end in sight. It’s very interesting, and also very intense.” After a moment’s pause, Kinateder added, “The more I talk with users and the deeper involved I get in this project, the clearer it is to me that users’ expectations from a digital assistant are very high. Getting there is going to be a lot of work, but we are looking forward to the challenge.”

A lot done, much more to come

As you can see, there is a lot going on behind the scenes. The SAP CoPilot team is currently working on incorporating many findings from the UX research into the product. The work is on-going and will continue.


This was the fourth in a series of blog articles about SAP CoPilot. Want to stay informed about SAP CoPilot? Check out the Twitter hashtag #SAPCoPilot.

You can also stay on top of what SAP is doing with regard to user experience and design by following @SAP_designs on Twitter.

 

To report this post you need to login first.

Be the first to leave a comment

You must be Logged on to comment or reply to a post.

Leave a Reply