What is the best way to build a fantastic user experience in the shortest amount of time?
You could ask a hundred UX designers and not get the same answer. While there are methods to guide you to success in design, there is no formula that promises a good solution.
When you are working on a new product, speed is very often an important factor. Investors or stakeholders want to break even or become profitable, as quickly as possible to stop the bleeding of money on a new project.
Many software and web development teams utilise the Agile process as their project management framework of choice to accommodate this quick speed. This framework developed from a group of software professionals in 2001 has grown like wildfire throughout the software development community ever since.
Speaking of wildfire… sometimes that is how it feels like when designing with these teams. Designing at such a rapid pace, without time to do adequate research and explore design options goes against some of the fundamental methods and strategies of UX design.
Unfortunately on many projects, especially for software or applications, this is the norm. The culprits for the problem: Agile Methodology and Minimum Viable Product (MVP) strategies. While the usage of MVP and Agile are not tied at the hip, they are very frequently used together in web and software development.
What is a designer to do when put in this position? Fight, flight or adapt.
- You can fight for more time to achieve the level of design you feel is appropriate for the project. This will probably not line up with the rest of the project schedule, so you will have a significant sell to make to win this one.
- You could also quit, but you probably have rent or a mortgage to pay.
- Another option is to adapt your process to fit within in the sprint confines of your team. It is not an easy problem to solve – UX designers struggle to bridge the gap between creating user-friendly designs vs designs that are feasible to build (in relation to time and budget).
Working with Agile Teams
Working with Agile teams is often a shock to the system for many designers – especially if you have been working in a slow-moving, waterfall environment where there are many levels of approvals or drafts.
If you are working in tandem with Agile or scrum teams, you are going to be working at a much more condensed and focused pace than in the past.
Agile teams bite off small, deliverable chunks of a project, and focus on it for usually two weeks. Sometimes it is longer and sometimes it is shorter, but the intention is always to have a shippable product at the end of the sprint. If you are not yet familiar with how a design sprint might unfold, a good resource to check out is the book Sprint, by Jake Knapp.
Your goal in a design sprint will be similar – design a chunk of something that is buildable, meets project requirements, and is usable.
Working within the Agile or Lean process can work for UX design, but it is not always easy and involves frequent pivoting. The whole process of conception to research to design has to be executed in the period of a sprint.
Practicing design in the Agile model is a difficult concept for designers to grasp – I know I struggled with it. Design is traditionally taught as a process of taking the time to get everything right in a one time process, not as an iterative one. But to work effectively in tandem with product teams, development and design schedules need to align much closer than process would allow in the past. Because of this, you will probably not have time to perfect the design, iteration will become a necessity.
As covered in his book, Lean UX, author Jeff Gothelf explains the reasons why working in tandem with a product team (and not in a design-waterfall method) is a good idea. In short, it keeps designers and developers on the same page working together towards a common goal with a common understanding.
To keep up with the typical 2-week sprint cadence of development teams, many designers have adjusted their design process to fit the mold of the Agile process.
What does this new cadence require for you as the designer?
- Being able to execute the design process much quicker
- Working in much smaller pieces of the overall product
- Staying in close, constant communication with developers
- Being willing, or even expecting, to fail
You will have a chance to test your design with users or potential users for the duration of your sprint. It might be testing with a finished prototype, or if you are ambitious and have the help of a developer, it might mean doing it with a coded prototype. Usability problems can and will present themselves in the testing of the prototypes.
Heads up – chances are something will probably fail a usability test here. Do not worry, it is fine. A side effect of designing at such a rapid pace is making mistakes. It is inevitable. Failure is almost welcomed in the Agile process. What is key to point out here is that you will probably realise a problem at this point before you would have with any other method. What is most important about what you do after those mistakes – iterate.
Iteration is when you go back and improve the product where there was a failure in testing.
Minimum Viable Product (MVP)
Being part of the team involved in creating a minimum viable product can be very challenging for you as a UX designer. Sometimes you will feel like you are being pulled in many directions and do not have control, or even a grasp, on the experiences your product is creating in the world.
From a holistic perspective, the idea behind building an MVP is to build the most valuable part of the product that customers need. And to build something that customers will want, enjoy and hopefully pay for.
In The Art of UX in MVP, Yona Gidalevitz, proposes a cycle for UXers to practice when working on MVPs:
[UX → Measure → Learn → Repeat]
As opposed to the traditional MVP cycle of:
[Build → Measure → Learn]
This highlights and addresses a key qualitative difference in the traditional cycle missing from MVP – iteration.
From a UX perspective, a minimum viable product means letting go of some of the parts of the product that may not have as much customer value. Some interactions are not that important to the overall user experience, so you can push them aside and focus on the ones that have high user experience value.
Remember that the whole intent behind building a Minimum Viable Product is to get something out there and get feedback from users. There will almost definitely be bumps in the road along the way, but you will learn from them. This should excite you more than anything because with this process you will constantly be iterating to provide the best experience possible.
(Lead image: Depositphotos – affiliate link)