My design process
The user interface has quickly become the place where important decisions are made. The modern designer needs to be aware of business use cases, software engineering constraints and most importantly, what the user needs. Balancing all of these can be tricky at times.
It’s the responsibility of the designer to be the voice of the user. You can’t be a user advocate if you don’t understand your users. This leads to the logical conclusion that designers must have a strong understanding of what the user wants. The most effective way to accomplish this is to receive a range of inputs. In no particular order:
- Learn who in the business has a lot of domain knowledge. This is generally (but not always) a software engineer or someone in a BA type role. I build strong relationships with them in order to have a strong understanding of the historical context of the product.
- Depending on the business, I cast my net wider to other stakeholders who are in frequent contact with users. This is generally account managers or customer service.
- Speaking to users directly. This is the best way to energise your design efforts.
- And lastly: my experience as a designer. This is an X factor. Sometimes you need to take what someone has said with a grain of salt. Other times you need to recognise that someone isn’t pushing hard enough for what is a genuine need. And it’s not uncommon for a user to request something which is unique to them. Solving their problem while ignoring the consequences on all other users is not conducive to good user interface design.
This process of speaking with people and building relationships is vital. Using user interface improvements as a way to build trust and rapport with other departments is crucial. When people discover that the UI designer is empathetic to user needs, you’ll find it hard to get some people to stop talking! This is a good thing.
This above ongoing process of understanding user needs and applying them to various projects is at the core of how I work. As time progresses my own domain knowledge grows. This causes design decisions to increase in speed and quality, generally speaking. At the start of a new major project there should always be time allocated to orientation. Too frequently, solutions are proposed to problems when the problem hasn’t yet fully been explored or understood. Driving to the core of any given problem generally creates a new awareness and sheds light to a better approach. Your first idea is rarely your best.
In practice this looks like:
- Being embedded in software engineering teams (attending stand-ups/sprint retros/testing/etc). Seeing the design through to the end, including writing production CSS.
- Making everyone in the business aware of the importance of user interface design. Sharing work-in-progress visuals with other stakeholders in the business to ensure alignment.
- Using Figma/Sketch/etc for visual prototypes, HTML/CSS for interactive prototypes, whiteboards/pen and paper for brainstorming sessions and so on.
- Performing validation in the form of user research when required. Phone calls, workshops, zoom calls, Google Form surveys… whatever the need is.
