What is a design process?
A design process is simply the steps you take and the order in which you take them to get through a project to create the final solution.
Design processes are double-layered; first how you structure your design project then how you decide when and what work you should be doing within that structure. There are a number of ways to organise your work some are more flexible than others allowing you to pick and choose what and when you carry out certain activities, others come with their own methodology built-in. If you decide to implement the following processes and methods, you'll be entering the world of Design Operations - the process of establishing optimised workflow processes and operationalisation of design within your organization.
What are some of these design methods?
The three main methods people use are: Lean, Agile, and Sprint. Each has their pros and cons, however fundamentally they are all aiming for the same thing - a researched validated experience for the user which has to be tweaked as little as possible after the fact.
Lean UX
The one you are most likely to have heard of is ‘Lean UX’. The basis of lean is that your first project on a product should always be working towards the MVP (Minimal Viable Product). This means you should be prioritising the functionalities that you want to put into your product, against one another. Every feature should be created to satisfy a user's need and to help reach a specific business goal. There will always be some features which you can’t get rid of due to them being required for a product to function but anything additional to these should be weighed against one another and prioritised to ensure only the most vital features will be built. These core functionalities are called MVP. In other words, it’s your basic product.
The general lean flow is to create a ‘benefit hypothesis’ this is generally in the form of a user requirement stemming from a user frustration. This feature is then designed collaboratively with development input before it is built. Once it is built it must be measured against the initial benefit hypothesis to see if it is filling the user's needs appropriately.
MMF means ‘minimum marketable feature’ think of it as a snippet of the MVP (minimum viable product).
Lean UX encourages designers to extend their understanding of a feature beyond how and why a user will interact with a component. Instead, the designer should know; what it takes to implement that component, how it supports business goals, if there is any surrounding functionality required that needs to be implemented for it to work, and what metrics should be measured to define whether it is a success or not. This should all be considered when prioritising features.
This can be a bit stressful for designers who want to add delightful features as well as just the base requirements. Being forced to forgo the niceties can be a bit jarring. But as everyone knows tech is such an ever-changing environment, that businesses and their products need to be able to react to a change in the market and pivot on what they need to build. Being lean in what you are building at any one time makes it easier and quicker to change direction to focus on a new feature or pivot entirely.
If you are interested in reading more about the lean methodology there is a book by Jeff Gothelf called ‘Lean UX: Applying Lean Principles to Improve User Experience’ which goes into this method in much more detail.
Agile
Agile takes a more iterative approach. The process of building the product is broken down into smaller chunks called ‘sprints’. At the end of each sprint, and before the next sprint, a review is conducted of the work completed that allows space for in-project prioritisation of features and functionality. This allows for tweaks to existing features if research or market change shows it should be pivoted, as this work can be prioritised alongside the new work to be done.
This approach is more flexible, which works best for businesses who are situated in a fast-paced sector which changes a lot. Features can be prioritised based on market and user research. This means less budget impact for pivoting than with Lean, which generally has fewer breakpoints for designers and developers to stop working on a feature. The agile approach allows teams to be a bit more cross-functional, designers and software engineers need to work closely as cooperation between design and development ensures an understanding of what work is upcoming for development, and from that, what designs are required for the next sprint.
UX design can also input into a sprint with iterative research such as user interviews and testing which can be conducted on individual features. This means the product can be tested thoroughly before it is even fully released.
We recently spoke to Ania Yaki, a designer in Russia’s largest bank, who gave us an insight into how she uses agile as part of her companies design process.
“We have a backlog, where we collect current tasks: if something needs to be done - it goes to the backlog and stays there until the product owner and the director of IT initiate a setup meeting. In that meeting all the tasks from the backlog are discussed, and then a Product Owner forms the sprint.
For us, the sprint is normally two weeks and is equal to the release cycle. After it's done, there is a business-acceptance procedure, which runs in parallel with testing. Then the team fixes all the bugs, if there aren’t many bugs we fix them and send it to production, if not - the tasks get put back into development, and the release cycle goes on.
As for the research phase: we usually discuss this verbally, accompanied by paper or digital sketching. Then the idea has to pass a couple of filters: lawyers, risk assessment, and CEO. After that it gets sent back to us as a full business-oriented task.”
Design Sprint
The design sprint method is technically an agile method, however, it’s slightly stricter in its requirements and is specifically aimed at designers. The main focus of the design sprint methodology is validation. Design sprint uses the design thinking methodology which helps validate ideas, solve product design challenges, and align the vision of a product across teams all while setting clear goals and objectives.
Design thinking is generally a one week sprint during which the design challenge (the goal/problem to be solved) is worked through, solutions are generated, the prototype is constructed and checked with target users. These solutions are then created post sprint, either by development or as a prototype which is tested with real users. This is a very intensive way of designing and can be stressful unless you are properly prepared for it. To keep it within a week you need to be certain ahead of time what features you are going to include and what the main user problems are that you are trying to solve.
The Design Sprint is a framework for you to use and can be adapted to different situations which means you can increase or decrease the time depending on your requirements. Often it’s used across a few days in workshops with clients. But it also works well in tandem with development sprints which often run over two weeks. Giving you a bit more time to finesse the design. This option can give you a time restriction on a design that can help you make tough decisions because you know you only have a set amount of time in which to complete the designs.
If you are interested in reading more about the sprint design methodology there is a book by Jake Knapp called ‘Sprint: How To Solve Big Problems and Test New Ideas in Just Five Days’ which goes into this method in much more detail.
But what about the process?
The above lays out ways in which a designer can output work for development but not what work should be done and when (apart from design sprint but we’ll get to that in a minute). Luckily some people have laid out a few different ways to approach the work you do. Let’s go over some of these processes.
Double Diamond
The Double Diamond is a structured design approach to tackle challenges in four specific phases:
- Discover/Research - insight into the problem (diverging)
- Define/Synthesis - the area to focus upon (converging)
- Develop/Ideation - potential solutions (diverging)
- Deliver/Implementation - solutions that work (converging)
As you can see, each phase is either a diverging or converging phase. In a diverging phase your aim is to be as broad as possible; gather as much insight, iterate on designs as much as possible, etc. Whereas with the converging phase you are narrowing in; synthesising your research into solid findings, deciding which design should be developed.
The above diagram outlines the vernal flow for a double diamond approach. If you were to Google double diamond you’d find a myriad of styles some specify exactly what tasks and research should be done when. However, generally in design, no matter how much you plan to stick to a strict method of task ‘x’ after task ‘y’ you generally find you will have to be a bit flexible in the research methods you use. Things like budget, time, team size, and access to users all dictate what you can do, when.
Design Thinking
You’ll remember we mentioned design thinking when talking about design sprint methodology. Design sprint is one of the few methods that has a design process built-in. The design thinking process is simple; it’s an iterative process in which we seek to understand the user, challenge our assumptions, and redefine problems in an attempt to identify solutions that we might not be able to see with our initial level of understanding. Generally conducted over one week but can be adapted to different situations to match dev sprints which can be longer.
The five phases of Design Thinking are:
- Empathise – with your users
- Define – your users’ needs, their problem, and your insights
- Ideate – by challenging assumptions and creating ideas for innovative solutions
- Prototype – to start creating solutions
- Test – solutions
The design thinking mindset is an iterative process so often these phases repeat and can run in parallel, especially if you are working on a few areas of a design at once. You could go through a phase and test it only to find out that something needs tweaking, this means going back to the ideate phase to iterate on your final design. Or it could mean going all the way back to the start to check to see if your original research matches the findings from the test phase.
So What’s the Difference?
If all these sound like different flavours of the same drink well that’s because they are. At the heart of it, all these methods all we are trying to do is verbalise a design process for others to understand and to give ourselves a little blueprint to follow to stop us from getting overwhelmed. It can stop you from forgetting steps or skipping some accidentally and reminds us of the importance of research, discovery, and iterative design. Whichever method you use, remember that they are only there as a guide for you to start off from and everything can be tweaked to meet your specific circumstance.
