Have you ever heard someone say, We don’t have time for UX on this project?
Have you ever thought that you might need to take some shortcuts to launch a design quickly?
I thought so.
The ongoing battle between nailing the user experience on a design project and getting it released quickly has been raging for years. At UXPin we’re creating a comprehensive UX Design application and, after months of work, we’re still going through it over and over again. This from a company was established by experienced designers!
The temptation to optimize the product development process is huge, although, as Twin Peaks taught us, “the owls are not what they seem.” Things can work out in completely twisted ways. Eliminating UX activities may not result in a higher overall speed and can easily lead to unfortunate results.
In the following article I’ll try to provide a path that walks the fine line between UX and speed.
User Experience Is Always Present
Whenever somebody tells you to hurry up and “do all this user experience stuff later,” you can be sure they have a total misunderstanding of what user experience is and what it entails.
Ladies and gentlemen: user experience is always present. It’s not something you can skip now and do later. If you decide to move past the design-focused activities to the next phase of the project, you’ll create a Minimal Viable Product (MVP) with shitty user experience. User experience is present whether you design for it or not, and if you don’t take care of it, it will just get out of control.
Now, if you love the lean approach to product development (like we do at UXPin) you have to ask: shouldn’t we just ship something quickly and learn? Of course you should, but think about the way your users will perceive your product.
I bet for your users your design is your product. You cannot expect people to abstract and separate the concept from your product and assess it. If the experience that you serve occupies the minds of your users with sad feelings and irritability, the game is over. Often, a speedy development cycle produces useless crap (perhaps with a lovely concept underneath the terrible experience).
It’s not as if by skipping the design you can create a product that will be OK and then in the next phase add all the shiny jewels to make the experience pretty. By designing UX you’re crafting and shaping the experience of your users. You’re changing the experience in a planned way. User experience design is a strategy of product development and it should be present right from the beginning. Focusing on the experience of your future users should lay at the heart of your approach to product development. There’s no other way.
Limit the Scope of the Project, Don’t Limit the Design
Are we doomed then? Should every product development process run for ages before finally shipping anything to the market? We all know that doing the full User-Centered Design (UCD) process is time-consuming no matter how proficient you are. That doesn’t mean, however, that UX design has to set a speed limit for the whole project.
UX design is a strategy of product development and it should be present right from the beginning.
A good strategy is to start limiting the scope of the project right from the first iteration. Focus on one well-understood problem. Build a solution that creates a positive experience for the users and learn whether this is a foundation to build on.
Right, but what about learning quickly from testing prototypes? Hardly any UX designer will refute the value of testing prototypes. But should we prototype the whole project and divide it into a couple of parts that will be developed and tested with final users, or perhaps prototype only the first iteration, develop it, test the final product with users, prototype the next iteration, etc.?
Let me offer you a rule of thumb:
- If, at the beginning of a project, you possess only knowledge from in-depth interviews with the target group about the scope of the first iteration and you’re working on a new product (for example), prototype only the first iteration and test it.
- If you have certain knowledge about the whole project and you’re working on a new part of an existing system, prototype the whole project up-front and test it.
Simple, right?
In the first situation the nature of the product may change significantly after the first iteration. You might expect a change in the scope of the project or even a significant pivot. Prototyping the whole concept could be a waste of time. Your task is to test the core of your idea with users.
In the second situation you probably know quite a lot about the general problem that you’re solving. The project is more about polishing and introducing a new quality. You’re focused on crafting the perfect experience rather than testing the core concept. To save time, prototype everything at the beginning and test it. That will take significantly less time than a series of tests of specific iterations of the project.
In Action
To illustrate the second situation consider a project that we’re working on at UXPin:
Project Dashboard
Goal: Creation of the perfect dashboard for UXPin the UX Design App. Finishing up a design storytelling feature and UX document templates, improving iterations, account management, and refreshing the visual side of the dashboard. Eliminating issues that customers complain about.
Knowledge foundation: In-depth interviews with customers, bugs and feature requests from customers, and usability testing of the prototype.
Phases:
- Navigation improvements and eliminating bugs
- Design storytelling and UX document templates
- Improvement of iterations and version control
- Account management
This is a broad and demanding project, so we’ve divided it into four phases of development, but we’re starting with a full mid-fidelity prototype that we’ll test with our target group. That’s our time-saver, as it will limit the need for improvements in the project after the development phase.
To give us even more speed we’re using previously gathered knowledge (as a rule we never stop talking to our customers). After testing the whole prototype, we’ll work on the visual design and development of the first phase and we’ll iterate quickly on it based on customer feedback and an analysis of the metrics. Then we’ll move to phase two, repeating the iterative approach, and so on.
Conclusion
UX design is deeply integrated into our product development process, and, in our experience, UX ultimately increases speed rather than limiting it. Rapid prototyping with the clear goal of testing the prototype decreases the number of after-launch changes. Limiting the scope to the most important problems based on the customers’ voices lets us focus clearly on the pain and salve it iteratively, providing the optimal balance between designing a great experience and getting it done quickly.
To give you some more ammunition, here’s a short presentation you can show your stakeholders when you hear: “Let’s move User Experience to the second iteration.”
Image of racing motorcycle courtesy Ahmad Faizal Yahya/Shutterstock.
