Why you shouldn’t align your actual project work to standardized UX and design process templates

UX and product design templates are everywhere nowadays; you can’t open social media without running into them. Well-designed and colorful PDFs about templated processes exist for everything. I didn’t create or include any templates or predefined methods in this book about how to do your job as a designer, and I would like to write about why. As I wrote before, the first reason was that I wanted to write a personal book. I did not want to write a design study book. I wanted to show my views about this industry and give some personal advice to you. Some advice is for the novice; others are for the more advanced. Hopefully, everyone will be able to find something that helps them become better designers.

I did not write about anything not based on my experiences as a designer and the 17+ years I spent in this field. Another reason is I don’t think encouraging designers to use predefined “industry standard” templates for processes is a good idea. The gap between using templates to complete design tasks and doing the actual work is pretty wild. I might be the only one brave enough to tell you this, but I could never fit any “design/UX templates” to my work entirely, as all real-life projects need a mixture of research and design techniques to succeed. 

No design process goes by the book. 

As novice designers, we dreamt of perfect projects where everything goes by the book and everything is in place and optimal. Let me tell you, in 17 years, I have not had one of these projects. There are cornerstones of every UX process:

1. the research, 

2. defining the problem, 

3. creating some prototype and design, 

4. validating it with users, 

5. doing iterating rounds if necessary, 

6. building the actual thing, testing it,

7. releasing the product. 

And start all over again with the iterations of the solution. So there is a process you usually go through. Every project is a repetition of these cycles. These parts of the process are always there, but how you complete them differs in almost all the projects you work on. I’m not saying that every project is totally custom. But there is no perfect, one-size-fits-all process in UX design or an ultimate, absolute solution that always works. Reality always kicks in and has nothing to do with fancy templates. The circumstances, the specifics of the company and the team, and the context of the problem you are trying to solve impact the process required. A real-life project always requires the right amount of mixture of different methods. This is a bit like cooking with different ingredients. You need to find the right balance between them for the best outcome. 

When someone asks about your preferred research methods throughout a project, especially during a job interview, the correct response is that it depends on the situation. The proper research methods will depend on several factors, including the problem that needs to be solved, the people you're working with, the time and budget you have, and the level of access to stakeholders and users. In short, there's no one-size-fits-all approach to research, and you have to adapt to each project's unique circumstances.

Fully aligning the work to what different templates tell you to do is just good for ‘UX Theatre’. It might seem significant in a stakeholder presentation to back up that your work is valuable for the organization and might benefit internal conversations. Still, it is far from the sweaty daily design work you must do. You must deep-dive much more ‘into the swam’ for an excellent outcome. Templates don’t ‘talk’ about tradeoffs that are there with you at almost every step you make to a successful outcome. In this book, I wrote about the power of finding the right balance between inevitable tradeoffs. 

Being against standardized templates. 

The other problem with using pre-defined templated methods that go by the book is focusing too much on the actual process rather than the outcome. No one cares what process or tool you use when you design and create user-centric experiences with outstanding future-proof results. 

Design is not a linear and happy path.

Most of the predefined processes are waterfall-like, linear ones, which can make you believe that designing things is like assembly line work. In that type of work, you put the necessary items at the start, do the process defined by a template, and have a successful outcome. If design were this linear, easy, and explicable, many more products would succeed. The truth is design is a messy non-linear process most of the time, a balancing act between the needs and the tradeoffs being made. 

The main thing you need to focus on as a designer is understanding the problem you need to solve from the user’s perspective, and there is no single way to go deep enough to understand a problem entirely. Templates aren’t created to fit actual project needs. Finding out the ‘Why’ for a specific project to get closer to understanding the ‘How” is what no template is talking about.

Other predefined processes, like “Design Sprints,” involves waiting for miracles to happen. If getting 5-6 people in a room together for five days would solve all the problems a product can face, making successful products would be pretty straightforward, but it is not. The main advantage here is, getting people together in a room and getting them to talk and add their part.

All these standardized and boxed solutions are just theatrical moves that sometimes do more harm than good since they give teams the impression of innovating. Even the Double Diamond method is just theoretical and, while the method is great to know and use, it is based on an ideal world that rarely happens in real life. A double diamond is never an exact and spotless double diamond. It is not the double diamond model that will save you if things go south but common sense and experience.   

Templates can be a good starting point in some cases. I’m not saying you should never use a template when you work. Instead, if you use templates, adapt them to the specific project need and don’t stick to them blindly. Before you stick to any methods, find the proper method that fits the project's needs.