Designing your design process

I was asked this week to explain my design process for a designer who recently joined Home Office Digital. As a designer, I really like patterns. In the design world, a pattern is a set of regular decisions taken to solve a problem. When faced with a problem, my first instinct is to see if I have solved something similar before. My design process is a pattern, one that I have been adjusting and iterating for many years.

Gain understanding

Why does this thing I am designing exist? That's a pretty good question to start with. Knowing ‘why’ holds together all your future design decisions. I then move onto learning who the users are and learning about the environment.

I need to understand the people I am designing for: who they are, what they do and how they do it. I also need to understand the environment I am designing in. An important part of a designer's role is questioning why things are done a certain way. A lot of the time, decisions are made arbitrarily. Why does this form need to collect a person's age? Do we really need their age or are we merely asking for it now because we’ve always asked for it in the past? By simply asking questions, we can sometimes make great leaps in progress.

Break problems into manageable chunks

In the UK government we are all about user-centred design. This means creating services and products that meet the needs of all our users. But meeting users’ needs does not mean designing everything at once. Start small. I take one user need and draft the components to meet that need. Each question on a form for example should be looked at as a unique design component that might meet a user need. I then mock up each component so I can start to see potential solutions. Then I can start testing.

Accept that your designs might fail

Becoming okay with failure was a significant part of my journey as a designer. I was afraid of failure when I first started designing. I tried to avoid failure by creating what I thought was the perfect solution before showing it to anyone. What I wish I had known in those early days was that feedback and critique are a designer’s best friend. As soon as we are comfortable with the fact that we can’t solve the problem ourselves, we are able to get into a really quick cycle of testing and iterating.

Test ideas early. Get working prototypes in users’ hands or show quick sketches to your team. Design as a team, gathering ideas and feedback from others. Anyone can solve problems, it’s not a job solely for designers. Do whatever you can to get closer to finding a solution to any given user need.

The look and feel

In my opinion a bad design processes means spending too long creating the look and feel. Look and feel are important. They help solve many design problems. Some colours and font choices will be made early as I build an accessible design solution.

But most of a designer’s time should be spent understanding and testing. This is the only way to know we are building the right things for our users.

Become best friends with the person building your designs

The relationship between the designer and front-end developer is really important. I don’t just want to hand over my designs and be done with the process. I want to be involved in the making, so I can continue designing as the product forms.

One of the reasons I think it’s helpful for designers to be able to code, is that it helps this relationship. I can build relationships by doing a bit of pair-developing on a part of my design. I can be a part of development discussions and come up with ideas to help solve build problems.

A design process should be fluid and flexible; not a check-list of things to be ticked off. If I look back, the most meaningful change in my process has been spending more time gaining understanding and less time creating a look. My process revolves around others and that's how it should be. Design should be inclusive.