Fixing our Design Process

Simon Deichsel
Project A Insights
Published in
5 min readFeb 27, 2015

When Project A was founded three years ago, we wanted to build great products with excellent UX and sleek design. Unfortunately, our approach was very similar to those of web agencies and wasn’t really suitable for our particular projects. We needed to restructure our design process so we could keep up with the fast pace and agile workflows in both software development and the startup ecosystem.

Design Process: Caught in the Loop

Design processes involve a number of working steps and different professional roles. CEOs, product managers, designers, and developers all have different areas of responsibility and as a consequence are focussed on different goals. The business side aims for specific KPIs, the UX expert wants a great user experience, the product manager wants certain functionalities, and the developer wants clean and maintainable code. This kind of task separation can be extremely efficient, and works well for highly structured and organized processes. However, in highly creative and individual environments, such as software development, the interactions between people of different professions requires careful management in order to avoid confusion and misunderstandings, which result in processes that are inefficient, frustrating, and difficult to follow. Everyone involved in the design process should pay attention to what is important for the people who work on the product at the next stage of development. Unfortunately, this is often not the case.

Outlining a typical design process will help to illustrate and exemplify the problems, but be warned, this may sound all too familiar for many startup teams:

A project is kicked off. The PM sits at his computer and creates mock-ups in his favorite wireframing tool. The mock-up is handed over to the web designer who adds the final touches in Photoshop, selects stock photos, and creates a logo — done, easy! or so it seems… but now the founder has a first look and, as you might have already guessed, it’s quite likely that the design is not exactly what was expected. After all, founders care a lot about their (startup) babies, so they request changes. Since founders usually aren’t design experts, it happens that they want seemingly small changes which, in fact, require a totally different approach. So we start from scratch and build a new design. This time, the concept is approved by the founder, but now the product manager starts to play “art director” and asks for gazillions of tiny little changes (talking about design is always a very welcome distraction!). In some cases, we had about 20 iterations until the product manager, designer, and founder were happy. This was even without any customer feedback. Obviously, we had to change our design process.

Improving our Design Process

In software development, different teams and their decisions are simply too interwoven and interdependent to be able to handle different development steps in isolation. Up to a certain degree, everyone needs to know what everyone else is doing now, and what they will be doing at the next stage. Knowing the requirements, restrictions, or even wishes of your co-workers helps you to view your own work within a broader picture, and you might be more willing to implement changes if it helps somebody else and, in turn, is good for the product. A properly orchestrated design process will avoid a lot of problems from the outset.

After struggling for a while with agency-like design processes, we looked for an alternative so that we could make our design processes more efficient. The web is full of ideas on how to improve design processes. We especially liked the Google Ventures approach and adapted it to our needs:

Design Process

We will not go through every single step involved, rather we want to stress the changes, which have helped us the most:

First, we now take the preliminary research much more seriously. We talk about user needs first. We know the competition and we create personas. A user story helps us to refrain from using personal opinions and to strengthen a shared vision of the product.

Second, we now run early-stage user tests. Most of the time, we don’t even need to go out of the building to get some feedback. We just go to another floor and ask a few people to check out what we’ve got so far. Although this isn’t strictly a scientific approach, it still provides valuable feedback. Furthermore, it creates a totally different mindset when working with wireframes.

Third, we diverge much more. We never let just one product manager do some initial scribbling. At least three people should come up with different solutions. Pen, paper, and a time limit of 5 to 10 minutes per scribble work really well for us.

Last but not least, there is one decisive twist in our new design process: The CEO or a member of the founders’ team is always involved already in the initial research and scribbling sessions. This has the very positive effect that the CEO and founders own their product right from the start. They are enabled to influence and understand design decisions, which reduces the likelihood that they will request changes later. In the early stages we sometimes even involve back-end developers, people from the marketing team, or anybody else who wants to join, but never more than 6 people. Involving different stakeholders at an early stage reinforces a working culture of shared responsibilities. UX is no longer perceived as the sole responsibility of the UX expert, of the product manager, or of the designer. It is literally the responsibility of everyone.

These changes were obviously a big win for us. There is still some room for improvements in the early stages of our design process, however the decreased number of iterations in the mockup phase, or even after the implementation of a design, more than compensates for that. For us, it is a very rare case of a process change that doesn’t only lead to better results but also decreases development time.

This post was written in collaboration with Tamer El-Hawari.

--

--