UX Designer’s Framework for Product Development
UX design has matured as a field over the past decade, overcoming numerous misconceptions and the disregard of logic. Designers have arrived at best practices through aggregating similar approaches while accepting the evolving process of design. However, there is no universal workflow for UX design. Each project is grounded in its unique context, based on technological limitations, users’ mental models, business goals and environmental influences amongst other factors. As such, even if a workflow worked well in the past, it might not work well again in a different context. It’s challenging to fit UX design into product development, yet if it’s not factored into, business runs the greater risk of pouring resources into developing a solution to a problem which is not real or relevant to users.
The KEY Design Process is adaptable guideline that can help designers manage their workflow. It consists of two parts: an Opportunity segment and a Solution segment. The goal of the KEY process is to not impose restrictions or substitute logic. The KEY process is simply a reminder to consider the context, to understand users, and to validate conjectures before developing the solution.
Opportunity: discovering and validating a problem
The elements of Opportunity, in no particular order, are
Opportunity, the first part of the KEY process, emphasizes discovering or validating a problem. Note that this segment is not named the “Problem” segment. After all, if we’re looking for problems, that’s all we’ll find. Since we want to learn about the subject matter, context, cause, causality, users’ behavior, attitude, product features, possible vacuums in the market, the possibility for innovation, or an opportunity in general, it’s more appropriate to name this segment “Opportunity”. As users often don’t know what they want until we show it to them, the Opportunity segment is not just about catering to users’ requests. Rather, we have to gain knowledge to make better presumptions or recognize the possibility to move ideas laterally into a new context.
The Opportunity segment is adaptable, meaning that it can start with any element that makes sense in our setting and circle around to gain actionable insight. Depending on how much time we have, we could organize reviews with stakeholders after each step or share reports with developers to keep them in the loop and enable them to think about system architecture. Here are few examples of the Opportunity segment.
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:
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.
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.