Considering that not everything in life fits perfectly, sometimes it might take more than 3 steps to discover relevant story. We should communicate any delays to our team and avoid making rash decisions or falling under the pressure of sprint deadline. In an ideal world we would move to the Solution part only when we’re confident about the insight, but more often than not, we’ll have to balance comprehension and efficiency. There’s also a possibility that we learn something important after the first step. A light bulb might go off during a user interview or competitive audit, so we will not need to blindly follow the cycle illustrated above.

You might notice some similarities between the Scientific Method and the KEY process. However, the KEY process does not advocate for scientific research in a product development context. We want actionable insight as soon as possible. If we set out to scientifically prove what users do or how they interact with the product, we would need a strict test scenario, controlled environment, and the possibility to replicate outcomes under the same circumstances. Considering return on such investment and the fast pace of IT industry, this is not plausible.

With the newly found insight we confidently proceed to the Solution segment.

Solution: working towards a deliverable

The Solution segment of the KEY process consists of the following:

Ideation

Iteration

Delivery

Solution part

We always start with Ideation, trying to break pattern entrainment and ignoring constraints. We want to generate an abundance of ideas, like we would do on the second day of the Design Sprint. We can ideate individually or together with team, engaging in brainstorming, Jobs To Be Done, How Might We’s, or Design Thinking.

Once we identify prospective idea(s) we might want to iterate and shape them further. Iteration is the step where we might consider design compromises depending on technical constraints or business goals. Since we already have an idea about what we’re making, developers can choose the technology and start working on the backend.

The last element of the Solution segment is Delivery, where the output of our work might be an interaction, prototype, design system or a complete product specification with defined success metrics. From there, we can shift the focus to developers or move back to the Opportunity segment to test our solution.

However, not everything in life fits perfectly. Sometimes, we might start with the Solution segment. I would prefer to do some research before designing, but not everyone works like this. An idea might just pop into mind, we want to experiment with an improvement, we might already be familiar with the context or have a pain point that we share with users, so we make a smoke screen, prototype, or minimum viable product, then move on to the Opportunity part to validate the solution.

Starting with the Solution, then going through Opportunity part to discover product/market fit

Conclusion

Theory and practice can often be very divergent. We’re trying to create a successful product and there is no clear path to that goal. The KEY design process is versatile like the real world. It’s not about procedures and tools: it’s a reminder to consider the context or caption that tells our team what we’re doing.

Keep in mind that for every successful product that follows these rules, there is a successful maverick, such as Reddit, Craigslist, Wikipedia, Amazon… If we build successful product, does it matter if we flipped a coin or had a clear design process? It does matter if we want to replicate the success and eradicate misconceptions related to UX design.