After years of trying different approaches, I’ve noticed common threads that appear to work best for me and now inform my work on a day to day basis. Similar ideas are echoed by todays leading UX designers, including respected practitioners Jon Kolko (Frog, AC4D), Tim Brown (IDEO), agencies like Clearleft and the Lean UX movement.

Over the next few pages I'd like to run through my design process in depth (TL;DR), from researching, through synthesis to testing and final outputs. First though, I want to set what I believe are the foundations for creating successful products and services.

My Principles for Successful Design:

Test the questions, then answer the correct one

Old but true - requirements are just hypotheses that need testing, otherwise you stand to deliver the perfect solution to the wrong problem.

Small, beautiful and manageable

Small, focussed teams get the most done in the shortest time frame. They have better communication and greater understanding of the problems to be solved. Often referred to as two pizza teams - a team small enough that you can feed them with two pizzas (I love good pizza).

Sign Off

Sign-off should sit with as few people as possible - Ideally just the management whose teams will be directly affected by the delivery. You need to make sure that the people you are engaged with have the authority to make that sign-off too.

Look forward

Depending on the scale of the project, the team needs to understand the future direction of the business in order to build appropriate solutions in both scale and robustness.

Access to people

The project team should be able to access the people they need to talk to, no matter what level and what area of the business - this often means direct access to ’worker bees’ rather than just their line managers. Front-line staff often know more about the true issues and pain points of the service. They understand first hand the issues that affect their customers, and that affect their ability to serve those customers. These people will have more insight than any business report you’re likely to get your hands on.

Better together

Developers need a seat at the design table and vice versa. In an ideal world these teams will be co-located to enable better ‘one team’ thinking and the ability for the natural osmosis of ideas, thoughts and culture to flow. One big win here is that you actually need to think less about communication. Get everything else correct and this happens as a natural and happy consequence.

Don't be wasteful

Documentation for the sake of it is a waste of both time and resource. It just needs to show where you came from, what you’ve learned so far and the direction of travel. It (the documentation) should be robust and detailed enough to progress to the next stage, no more, no less.

Prototype with wild abandon

Prototype like your life depends on it, but... build the right prototype for the job at hand. A rough mockup in a browser can help you test your assumptions - working through a task flow or such like with end users. A pixel perfect mock up will do wonders for business sign off, even without all of the functionality hooked up. Give an executive a URL to your design and letting them interact with it on their phone, while you continue with your pitch makes your designs very real, much richer than a Photoshop mock-up or wireframe on a projector screen could ever be.

Somewhere between these two resolutions is an ideal place for testing the ergonomics and affordances of a design across devices. This medium fidelity prototype with buttons, forms, inputs and first draft content all in the correct place, will let you tackle issues you didn’t know existed, and before a single line of back-end code has been written. Another benefit of this level of prototype is that it can also paint a rich picture for developers thinking about architecting the solution.

The other benefit of prototyping is that your work here, if done correctly, can take pressure off the design and development team further down the line, where lots of your design or front-end code has already been written. Building on this idea, I find that a pattern library is a great complementary deliverable - allowing more rapid high-fidelity prototyping and front-end dev in the future.


None of these methods are groundbreaking or new of course, but these are the main things that I have tried out and learned from. They have helped me design successful outcomes time and time again.


Getting good work done is about teamwork, not a lone genius designer, so I thought I'd share this piece of wisdom from Jessica Walsh (Sagmeister & Walsh):

"be nice, because no one wants to hire assholes or egomaniacs, no matter how talented you are."

Indeed :-)