Design the “right it”, before you design “it right”

Share this post:

(Second of three blog posts in this series)

In the last post, we introduced UX as a key competence for projects to succeed. This post looks into the value of empathizing with users and how to generate (many) good ideas.

Know your users before knowing your solution

It is easy to skip UX research in the early phase of a project and start designing the solution. But these solutions will often be based on assumptions. The risk is that the solution will need a lot of (expensive) rework after development or in the worst case will never be used if user needs are not met. In fact, “at least 50% of a programmers’  time during the project is spent doing rework that could be avoided with a little UX research” (Source: Human Factors International, 2013).

In other words, we need to find the “right it” before we design “it right”. This requires that we empathize with the users we are designing for and understand the context they are in. This is where user research comes into the picture.

To give an example, we once experienced that a client presented a rather narrow design briefing, in which the solution was more or less given from the beginning. The client approached us with the desire to have us help them digitize their several manual processes. The solution should be based on blockchain, where collaborating parties would be able to upload and share information.

Only two days were planned to conduct user research, so we spent one day with the client observing their processes, and the following day we interviewed two different user groups. During the first day, the anticipated need was made clear, but the insights from the second day challenged our assumptions significantly, as it turned out that the client’s largest pain point was not equal to that of the rest of the user group. Where the client faced problems with sharing and sorting of information, the other user groups’ primary pain points were related to a lack of communication between collaborators and a need for more transparency in the system. As the success of the new solution was dependent on engagement from all user groups, the client now decided to broaden the scope of the solution and set aside more days for user research in order to further examine the different stakeholders’ needs.

This paid off, as the design of the solution was now characterized by user needs, which resulted in a solution that provided value for all participants. If we had designed a solution directly from the initial project briefing, it would have looked a lot different, and an important main component would have been left out since no one would have been able to come up with the idea out of the blue.

This doesn’t mean that you have to set one month aside to do user research. A little user research is better than no research, and you cannot know everything anyway, so the key is to gain just enough understanding to start generating ideas that create value.

Good ideas come from many ideas

There is not only one right solution, and it may often be hard to imagine how a solution will look like. The mentality of the ideation phase is the more the merrier. This is where simple, as well as crazy ideas, can fly. The only way to find the right idea is to generate as many as possible. Initial ideas, no matter how uncreative they might seem, inspire new, better ideas, which then can be reduced to the best, most practical and innovative ideas. In this step, it can be hard as an outsider of the process to know every way new ideas can benefit the stakeholders. So to provide valuable outcomes that feel closer to the users, let them, the stakeholders, and your development team help you generate ideas in a co-creation workshop. This ensures a more united front in the project team and creates shared ownership of the solution.

“61% of 554 business executives say that co-creation has enabled them to produce more successful products and services” (Source: Longitude Research, 2016).

In a client case, we had a two-day workshop to get from the as-is stage to ideas to concepts. The project scope was very complex and relied on individual knowledge of a legal team on a case-to-case basis, as well as dealing with up to 70 stakeholders in each case.
The workshop participants from IBM were a combination of a UX consultant, a data scientist, a business analyst, and AI subject matter experts, and from the client future system users and stakeholders. In an initial discussion of Hopes and Fears, the users raised specific concern that they couldn’t visualize a solution that was able to capture the range of pain points they faced. This was a direct concern that we had to address during the workshop. The workshop encompassed adapted design thinking exercises, starting with the good and bad processes, personas, an empathy map, and as-is scenarios. Each of them led to the next, ending up in both an individual and collaborative brainstorm of WOW ideas. While these were clustered and prioritized, a scope of a solution became clearer. The ideas were then divided into four main concepts that would function in parallel. The concepts were described in WOW statements ready for validation in each their own PoT (Proof of Technology), and consist of the following six elements:

1. Persona – the person using the solution.
2. Capability – something the solution lets the user do.
3. WOW interaction – what part of the solution the user interacts with.
4. WOW how – how the user interacts with the solution.
5. WOW data – what data the idea is initially based on.
6. WOW impact – what the main outcome of the new solution is.

To use Airbnb as an example, it would look something like this:

“[1] The traveler [2] can find personal and cozy housing for his/hers vacation [3] by searching in one place [4] that provides a list of available private housing, [5] based on the travelers search query, the house owners data input and the travelers search history, [6] which allows the traveler to choose the best and most compatible place without having to ask each home owner himself“.

The statements shouldn’t be perfect, but provide a foundation on which to build a minimal viable product to show the general functionality. The statements should then be backed up by success criteria that work as proof that the concept has passed the test. These are important as they provide a time to stop prototyping and start building the real thing.

The participants’ confidence grew in their own involvement, as they saw the value of their inputs become the base of the ideas. Furthermore, the participants’ initial worries slowly faded as they became more and more confident that the project wouldn’t end up in yet another product they were forced to use on top of everything else.

Not only did this collaborative method provide a stronger client/IBM relationship, but more importantly, the ideas were first-hand validated by users on the scene, ensuring that only productive and valuable ideas survived.

This was the second blog post of three, where we dive deeper into the UX and design process steps with examples from client projects. The next post will look into the prototyping and test phase.

If you have any further questions, please do not hesitate contact one os us at lforss-cic@ibm.com or kmlorenzen-cic@ibm.com