Process. That is what readers want to see in design portfolios, right? To understand how people think and approach the design. And then you are shown the typical phases of research, ideation, prototyping, evaluation and iteration. Or they pull out the ever famous double diamond or refer to Bill Buxton’s funnels. Pictures of flows and post-it filled walls. But let me tell you, there is no one process.
There are processes for different situations, but those vary wildly. Projects in different stages require different approaches. Age of a product or business affects this as well – at times you have long history that should be respected and at times you’re looking for a direction for a completely new product.
There are some commonalities, however, about how to get things done with high quality. Here are some approaches that have been working for me.
Create Without Fear
This is the Indiana Jones part – you’re discovering the unknown. There is a red dot on a map where a mountain far away is supposed to be. Nobody really knows exactly where it is. But as you get closer, your aim gets better – you start to see the mountain yourself, in horizon, the mountain emerging from the clouds and haze. You alter your course as the route reveals itself. Till you eventually find your way up there.
But how does this relate to work in design, in the work we do every day? You’d be surprised how often you run into situations where you are set to improve aspects of businesses without clear goals, only armed with vague ideas on what a client might want to accomplish. It is then your job to come up with the how part – and preferably, keeping feasibility in mind as well.
Create without fear is a process that aims to come up with answers on what you should be doing. Not “how”, but “what is the right thing” for the business. The length of this process is adaptable and benefits from multiple iterations, but it can also be shrunken down to fast paced sprints. With more time, more comprehensive research can, and should, be done as part of the process to minimize risk of going astray. It’s also worth noting, that the sprint teams should include developers and prototyping in it.
This starts with background research that is consolidated into key learnings. The key learnings are shared with team members to facilitate ideation – often taking the form of post-it slams against specific topics that appear most impactful for business goals. The best ideas are then turned into one paragraphers, mini-stories no longer than a paragraph or two, that put the ideas into consumers’ language in realistic situations. The best stories are combined into a single story that works on its own. A prototype is produced to illustrate the golden path, the key user benefit.
These are then packaged to a deliverable that includes:
- One Line Concept: A single sentence that defines the target users, what makes the solution differentiated and the positive outcome it accomplishes.
- 5×5 features: 5 main features and 5 supporting features. The number of features is not really important, this only aims to concentrate what is the soul of the product and what is really relevant for it.
- Story of the golden path. Seinfeld it often. Don’t know what I mean by this? Happy to talk to you.
- Prototype/ripo demonstration
If accepted, this would then get turned into a design brief.
Dealing With More Established Products
There are also cases where it is clear what needs to be done to improve a product and there is little need to start exploring possible new directions for a product. In these cases, scenario based approaches can be utilized. Books could be written about how to form good scenarios, but ultimately it comes down to a few key points.
First is to identify business goals, if these are not given already in the design brief. These should describe what the business wants to accomplish without resorting to how that is to be done. The goals should be distilled into metrics to understand if the designs are working and how to measure progress. Proper metrics are especially important if various designs can be tested in live product and choices need to be made between these alternatives. These may not always need to be numerical as “experience” is often hard to measure, but they need to be something that you can use to tell if you are improving the product. Utilizing tools such as Lean Canvas can help in keeping track what relevant questions should be answered.
Goals and metrics help to identify and prioritize touch-points for maximum product impact. Another useful tool is product lifecycle mapping – giving consideration whether the users are experiencing the product for the first time, in continual use and what happens after the users stop using the product. Covering different stages of life cycle helps to address more holistic experience people have, hopefully forming a virtuous cycle that keeps users delighted.
Scenarios themselves are written against the metrics and they should be reasonably implementation independent. They should cover both the relevant parts of the products life cycle and be relatively brief – few paragraphs. Budget and time allowing, it would be very good to do user research to testing against the scenarios to make sure they are based on reality and real customer problems.
These scenarios are easily broken down to individual use cases in engineering jargon which can be tracked via project management tools such as TFS. Additionally scenario process can then be measured via the metrics to prioritize delivery. However, I believe there is a better way of doing things…
Getting Things Done
A common problem with many organizations is getting things done and not letting good ideas die along the way. Design department is often isolated from engineering and plans are forward heavy – some call this waterfall. Some companies try to address this with agile development, but end up doing waterfall as specifications are set in stone.
This just won’t produce good results. Getting good, new products out depends on teams that have clear goals and autonomy. The team needs to be small and start with the most fundamental questions first, iterating towards finer and finer details. They should consist of a business person to make sure the goals keep on track, designer or a few to craft the product and selected key developers who are used to ambiguity and can quickly iterate with code.
In my ideal world, this would start with a product brief – a document that describes what the team is set to accomplish and what are the relevant use cases and metrics. As a bonus, a list of non-goals that describe what is irrelevant is extremely helpful as well.
The team starts by validating the most crucial assumptions of the creative brief the cheapest, lightest, fastest way possible. This can include user research, usability, interviews, prototypes, videos or any other artifact that helps with the goal of identifying the largest risks. The main purpose is to gather knowledge, quickly. Fail fast, accept you may be wrong and assume you will need to course correct.
At times this is called ‘Grey Box’ approach – the term coming from gaming industry where the core use case is prototyped by simply putting grey boxes in place. They are supposed to give the feel of how the product could work. The basic flow is then expanded to cover the rest of the features and functionality. Polish and refinement are put in once it is established that the use cases bring value to the target users and the business. This is also when you can scale up to a production team to deliver faster.
The reason why this gets products made with quality is that the process has inbuilt mechanisms to minimize risk and ability to course correct where needed. Each iteration is fast, cheap and testable. Bad design ideas are eliminated quickly. There is no time wasted for coding features that do not provide value. Prioritization can be done with a running prototype or product to define what is the next most valuable feature.
And since all the key stake holders are expected to be present, they understand why plans are changing – and make no mistake, the plans will change!