Technology Blogs by SAP
Learn how to extend and personalize SAP applications. Follow the SAP technology blog for insights into SAP BTP, ABAP, SAP Analytics Cloud, SAP HANA, and more.
Showing results for 
Search instead for 
Did you mean: 
Product and Topic Expert
Product and Topic Expert
When taking your first steps into User Experience Discovery and Design there are 2 important questions to ask yourself.  These 2 questions will reveal if you have made a fundamental shift in approach, or are just playing lip-service to UX methodologies.  They also challenge you … and can stop you falling back into old habits and practices.  The 2 questions are these:

  • Am I asking the right questions?

  • Am I solving the right problems?

Or to put it more memorably:

  • Am I avoiding “faster horses” – the right answers to the wrong questions

  • Am I avoiding “dead baby frogs” – the right solutions to the wrong problems

Image source: Author's own illustration

Over the last few weeks I’ve had the privilege of visiting two customers and reviewing their first steps into user experience discovery and design.  These are real customers both based in Australia.  One is in the private sector and the other in the public sector.  Both have a sizeable numbers of end users.  Just like observing extreme users, seeing newbies at work brings into stark relief what works, what doesn’t, and why.  For obvious reasons, I won’t mention their names.

Both customers have strategically chosen to use Fiori design and SAPUI5 technology for their user interfaces.  Both customers have built and deployed user interfaces including Fiori user interfaces before.  Their technical credentials as developers are not in doubt.

Both customers are looking to scale their user experiences to involve more critical use cases with custom-tailored user interfaces.

Both customers have grasped the importance of UX Discovery and UX Design to ensure the right user experiences – and associated user interfaces – are delivered to end users. Both customers are as a consequence taking their first steps into discovery and design.

That’s where the similarities end.

Customer A is on a pathway to risk and potential failure.  They will deliver something, but will their end users be delivered good user experiences? Will they deliver user experiences that increase user adoption, drive innovation, and reduce TCO? It’s seems unlikely. You see Customer A believes they have made a fundamental shift, but in fact has only made incremental changes.

Customer B is on a pathway to success.  Whatever they deliver, it probably won’t be perfect. Yet even now it’s easy to tell that what they deliver at the end of the project will solve real end user problems.  What they deliver will provide real business value and reduced TCO.  And even at this early stage it’s already delivering benefits in increased collaboration and understanding between end users, business process experts, and developers.  Customer B has made a fundamental shift.

But that’s them and this is you.

What are the signs to watch out for that can tell if you are on track or not? Let’s have a brief look at Customer A and B’s UX Discovery and Design approaches and what’s making the difference.  And we'll finish with how you can make sure your UX Discovery and Design approaches are effective.

Avoiding Faster Horses in UX Discovery

There’s a famous apocryphal quote by Henry Ford – inventor of the early popular Model T-Ford motor car – “If I had asked people what they wanted, they would have said faster horses”.

Regardless of how you approach end user research in your Discovery phase, there are 2 major indicators of whether you are on track or not:

  • Engage with real end users (or as close to real end users as you can reach)

  • Ask the right questions – and listen hard to both the spoken and unspoken answers

Both Customer A and Customer B have managed to engage with real end users – and are to be congratulated on that!  If your organisational culture drives teams into silos, navigating internal politics and corporate culture to engage with real end users is big first step.

How they engage with end users is telling.

Customer A has invited their end users to their design workshops.  They talked to their business process experts. They emailed out some questions asking what end users needed and collated the answers.  They put together a design proposal. Then in the design workshop they show the users the possibilities of the new solution, they present a proposed design, and ask the users the fatal question. The innocent question that looks so promising.  But It’s the wrong question that will always get you the answer you do NOT need. The answer that will lead you to the wrong outcome.

The question they ask is this… “so given what we’ve shown you… WHAT DO YOU WANT?”

The reason “what do you want” is the wrong question is it only gets you “faster horse” answers.  You see it’s very difficult for people to imagine the future, so they answer from their own current reality.  “Oh well we have 3 reports like that now… and I guess I’d want a 4th report too”.

What did the team notice about the responses? “The end users really didn’t ask for as much as we thought”.  The team thought that meant they were on the right track. Maybe that should have been a warning sign.

What’s wrong with this approach? It’s the same approach ICT people have been using with business process experts for years – the one that’s been delivering over 40 years of poor user experiences.  The only real difference is that instead of simply inviting the business process experts to the workshop, they are inviting end users.   The subliminal message to end users is:

  • ICT retains its arrogant Expert status over end users – “We are the experts, you come to us, we are much too busy to go to you”

  • ICT will apportion the blame to end users if the design is wrong – “We asked you what you wanted, we did what you asked, it’s your own fault if it’s wrong”.

Customer A doesn’t know much about the daily reality of their end users. They’ve never even visited end users sited in the same building.

Customer B has a very different Discovery approach.  Customer B has questions too - but they are very different questions and they are asked in a very different way. They put a lot of effort into making sure they are asking good questions – questions that will help them achieve the right outcomes. They ask questions to reveal answers they need to achieve their outcomes including:

  • Who are our end users? Are they old or young? Are they active or sedentary? What’s their educational background? What devices do they use at work and at home? How often & how do they use their devices now?

  • What is the working environment of our end users? Is it noisy or quiet? Is it crowded or spacious? Is it bright or dim? Is it inside or outside? Do they move around a lot or stay mostly in the one place?

  • When do end users do the tasks in scope? Do they have a special time of a day or specific triggers? Are they under time pressures to get it done?

  • What gets in their way of getting the task done? What happens when they make a mistake? Are problems fixed quickly or is it complex and protracted to resolve errors? Do they understand the predecessor and successor steps of the process? What feedback do they get they tells them the process has been completed? What problems does it cause for them outside of the system when there are delays or revisions?

  • They ask end users: Can you explain how you do this task? Then they ask: Can you show us how you do this task? And finally: Are there things we haven’t even thought to ask?

Every question was mapped to how the answer would serve the UX Discovery and Design process. Some were aimed at creating evidence-based Personas, Points of View, use cases and story boards.  They asked questions that uncovered real user needs, desires and pain points.  A very few questions were aimed at uncovering initial ideas towards a solution. And several were aimed at uncovering the mental model of the user, to uncover criteria that might be used to later assess the to-be design and judge if it was intuitive.

The team set aside time to meet with their selected end users at the end user’s place of work.  They put their questions into interview scripts and practiced them with nearby colleagues before going to a wider group.   While they couldn’t observe every end user, they pushed to meet and observe as many as they could.  And they took note of what they were seeing:

  • “Even the process of selecting the end users revealed how little our business process experts knew their own end users. We even found 2 roles that weren’t officially covered by the business process”

  • “When we asked them what they did and then watched what they did … there were 3 extra steps they hadn’t even mentioned!”

Everything Customer B did in Discovery gave this subliminal message to their end users:

  • “As ICT, we are here to serve you. We may be the technical experts, but you are the experts in your user experience. We don’t know what we don’t know. Help us to understand so we can serve you better.”

  • “We want to work with you, so we achieve mutual benefits. Your success is our success”.

Customer B is getting all sorts of useful insights into their end users, their challenges, and how they think about the work they do.  Along the way they are getting noticed by managers – some even offered to be interview practice subjects – and business process experts who are getting new insights into gaps and oversights to be addressed in the overarching business process.

How do you avoid “faster horse” answers? By making sure you are asking the right questions.

Avoiding Dead Baby Frogs in UX Design

When I was a child a feral cat brought its kittens into our house and left with them with us. We loved those kittens to bits! We named them, fed them milk in dolly bottles, petted them, played with them, toilet trained them and took as much joy in their development as any parent does with a toddler.

As the kittens grew into cats they started to exhibit hunting behaviours – batting away at little lizards and jumping to try to reach butterflies. As children we applauded and encouraged them. They were so cute!

Then one day there’s a meowing at the back door, I open the door and my cat is sitting their pleased as punch with himself.  I look down and see…

A dead baby frog.

It’s at this moment that I have a new and uncomfortable insight… “Tiger and I think very differently about some things”.

When you are from different species it’s easy to understand that the two of you think differently.  When it’s two humans, it’s less obvious when we don’t think the same way.

Which is how we end up with too many projects where ICT delivers “dead baby frog” user experiences to end users.

A dead baby frog is the right solution to the wrong problem.  If I was a cat, and I was hungry, I might be glad of a dead baby frog to chew on. But that’s not my problem.

Customer A has worked out the design within the ICT team. They’ve seen all the possibilities of their new solution and – like most ICT people – reached immediately for the “shiny new toy”.

They’ve zoned in on the most sophisticated user experience option available, the option aimed at expert  users, and they are creating complex reuse patterns to propagate this throughout their design.

They’ve mostly ignored the Fiori design guidelines on how and where such patterns should be used or not used.

Instead they are looking to add complex navigation patterns on top of sophisticated user interfaces.

They’ve taken the Fiori Design Principle “Simple” and decided to create something complex instead. 

Worse they’ve taken ICT reuse principles and gone feral with them – every user will see the same user interface with the same data – just with different navigation paths.  I wonder if every user needs the same data? I wonder if every user makes much the same decisions? I wonder if users will have the persistence to follow such complex navigation patterns?

Instead of identifying real end user needs and pain points, they are putting a lot of effort into creating a solution that *might* be useful for end users.  But hey, never mind, it will certainly be easy for ICT to support, and satisfy ICT’s needs for reusable architectural patterns.

I’m getting a whiff of dead baby frog!

Frustratingly, that’s not their biggest misstep.

Like my cat Tiger, they’ve proudly presented their proposed design to the end users as “prototypes” and thereby claim they are doing design. They showed me their prototypes.  Their prototypes are essentially collages of screenshots. Some prototypes are even full-blown proof of concepts.  And they’ve told their users this is the design they need. It’s the latest and greatest UX – and of course you want the latest just like you want the latest gadget or smartphone.

End result: They have stopped their end users from giving useful feedback.   Because how could anyone refuse the latest and greatest? And they’ve biased their users towards a particular end state design.  Even before they have understood if it’s something their end user actually needs.

I never did have the heart to explain to my cat Tiger that I didn’t want his dead baby frog. I just quietly disposed of it.

Customer B has a very different Design approach.  Customer B has worked with low-fidelity (paper/pen mockups), medium-fidelity, and high-fidelity prototypes.  Sure there’s more work they could do on including end user representatives more directly in their design process – and they are already planning for that.  In the meantime what they have done is been careful to circulate the simplest design prototypes first and get feedback.

They make sure that everything they suggest is technically feasible and fits with the recommendations in the Fiori Design Guidelines before they show it to end users.

Each time they get feedback they incorporate it into a new and higher fidelity version of the prototype, and send it out to an even wider group of end users for more feedback.

Even in their earliest attempts, they made sure they went through 2-3 iterations of prototypes to make sure they had sufficient input. Sure they did some proof of concepts just to check technical feasibility.  But only once they were satisfied the design was right did they start coding the final user interfaces.

How do you avoid dead baby frogs? By making sure you are solving the right problem… and that you have validated that your solution will actually meet the pragmatic needs of your end users.

The Challenge for YOUR next UX Project

I’m watching both of these customers with interest to see where they go to from here. I’m fearful for Customer A but hope they can turn it around and learn from early missteps.  I’m excited for Customer B and keen to see them speak up at events and webinars to explain to others how they approached Discovery and Design.

But that’s them and this is you.

It’s normal and natural to make a few missteps when learning any new skills.  Focus on getting the fundamentals right, on learning the lessons, and you’ll deliver on the promise of great user experience.

So here’s my challenge for you…

Are you avoiding faster horse answers?

Are you avoiding dead baby frog solutions?

Are you making a fundamental shift… or just an incremental one?

Want to find out more about UX Discovery and UX Design for your Fiori project? Customer B recommends OpenSAP course Design for Non-Designers