My Ways of Working

As with most designers, I have a method of working that I try to apply to every project I'm involved with. Here's a top level breakdown of how I prefer to work:

1. Establish the brief

It's always important to know exactly what goal you're working to. As part of this process I'd normally look at the following:

  • What do I think the core business needs are?
  • What are the user needs and motivations?
  • What already exists and how does it meet any of the needs outlined above?
  • What do stakeholders think the core business needs are?
  • Plan a scope and rough timeframe for delivery, and establish KPIs
  • Share the plan

2. Research

Every project starts with research. It normally falls into these categories:

  • Competitor analysis: who, if anyone, meets the identified needs outlined above? what do they do right and wrong?
  • User testing on current solution (if one exists)
  • Subject research: often there are other research papers written about the subject I'm looking at, and they can be useful references
  • Analytics deep dive: the deeper the dive, the better, but if time is short then identifying interesting behavioural anomalies can provide results
  • Agree problem statements with stakeholders
  • Personas: How do users behave? What motivates these users? Which motivations lead to which behaviours?

3. Design

When it's ready to start designing, I like to follow this modern process:

  • Divergence: Sketching sessions with other team members, up to 6 people in total. It's good to involve UI designers, developers and product managers in these sessions.
  • Convergence: Working alone, or with a select few people to pull the ideas together into three or so solid, workable solutions
  • Rapid prototyping: At this point, I'll have enough to create initial wireframes and rapid prototypes, normally using Axure, InVision or Flinto.
  • User testing: This happens as often as it needs to in the design process. When testing three designs, it can be via comparison, or in parallel. I prefer to test on the device, with as high a fidelity prototype as time allows.
  • Iteration: it's important to work through the details, and stress test any designs. Changes will almost certainly be required in some shape or form.
  • Handover and further amends: Normally, a UI designer had been close at hand throughout this process, and when it gets to the UI stage, I can be flexible with suggestions and changes that a UI designer may want to make in order to provide a cohesive experience.

4. Regular Dev Reviews

In all projects, it's important to have regular reviews of what's being developed. Sometimes, changes may need to be made to the experience when built due to unforeseen technical constraints or device nuances. This is a pretty common occurrence in my experience, and can be beneficial as long as time for this was baked in when the development plans were estimated. As a UX, it's important to push dev planners to be flexible. The developers themselves are normally happy to experiment a little, as it gives them a chance to have their input.

5. UAT (User Acceptance Testing)

It's vitally important that the UX designer goes through a round, or several rounds, of UAT when the development process is nearing it's conclusion.

Many times, only the UX designer will have the full experiential view, and it's important to keep checking on key flows, and stay in constant communication at this point in a project. Small mistakes can have a big impact on the end experience.

While some compromises are acceptable, it's important to stay strong. Being polite, but firm when challenged, is normally how I get the best results.

6. Plan for Optimisation

As KPIs will have been measured after release, it's important to keep track of them to learn whether you've been truly successful or not. Every digital release of any kind will require some form of optimisation when real people start using it. Here are the regular steps I take:

  • Wait: Assessing any product or release within a short time frame is a very dangerous practice. Users will have cycles of behaviour, and it's good to wait until they've been through a couple of these cycles at least before making any judgements. On eCommerce platforms, for example, this can be two end of month payment cycles, so you can account for anomalies in a particular month.
  • Plan: Optimisation always needs a plan. How much needs improvement?
  • User test: if figures are pointing you in a direction, clarify the direction by asking real people where any issues lie
  • Design and A/B test: When performing optimisation, it's always important to test a limited piece of functionality against a control. That way, you know which elements are providing the benefit. Patience is a virtue here :)

Hopefully this helps you to understand my mental processes, and how I work. I'm a realist, of course, but creative thinking doesn't need to be hampered by reality. Knowing when to diverge and converge is the key to any successful piece of work.