How do you tell someone about your work, when you can't tell anyone about your work?

I really wanted to get across how I work on my UX projects, but much of my work is under strict NDA. So, here's a generalised process. Of course it doesn't take into account time, budget or the work that's already been done, so I wouldn't expect all projects to contain all of the below. But it should give you an idea of the sorts of things I do.

Completely new to User Experience Design? Starting with a quick read of the UX Design wikipedia article; that’ll give you an idea of what we’re all about.

Understand the problem

Kick off the project

  • What do we want to achieve?
  • Why has this come about?
  • Who will it impact?
  • What are the constraints? E.g. time, resources, platforms, tools
  • Is there another service or tool that behaves similarly?

Review any existing research

  • Has there been any research so far?
  • Why was it commissioned?
  • Who was involved?
  • What were the outputs?
  • What do we know we don’t know?
  • Stakeholders, including – but not limited to – the person commissioning the project
  • UX designers
  • User researchers
  • Business analysts (if applicable)

For all stages, it is desired that as much of the project team is involved as possible

Typically there aren’t many outputs from this stage, other than the team knowing why it is that they’re there! However, this discussion can produce:

  • A bullet-point list of project goals, if this doesn’t already exist
  • A summary of what’s known so far
  • The beginnings of some personas, if the prior research already covered this
  • A project!

Personas can be created as soon as we know a bit about the users – so if, for example, the product or service is for internal use, a lot of the information’s already available. Of course this means making a lot of assumptions, but that’s fine as long as the personas are tested and iterated.

Here’s a censored example of a persona I recently created for a client:

Censored persona

It’s important to treat clients well; why not meet in an artisan coffee house and order them a glass of tap water?

Agree the project principles

Agree the project principles

  • Understand accessibility goals – does the product or service need to meet a specific level of accessibility guidelines, e.g. AA or AAA?
  • Identify usability goals – what’s most important, given the context and user base? Is it more important that it’s efficient, or safe? Is it more important to be credible or helpful? While of course we’d like products and services to do all these things, it’s important to focus on what’s top priority.
  • Agree user experience goals – it’s great that the product or service will be reliable, but how can we cater to the emotional needs of users? Should the service be fun, or is it more important that it’s sleek, on brand and aesthetically pleasing? Users having fun with a product or service is great – but not always appropriate given the context.
  • Waterfall, Agile, or…? – not every organisation wants Agile, for all sorts of reasons. Agree from the start whether this is an Agile or Waterfall approach, and provide the appropriate level of documentation – remembering that even if it is Agile, anyone could leave the project at any point.

Create a UX strategy

  • Understand and articulate the challenges that have led to the project.
  • Describe the aspirations for the finished product or service.
  • List the deliverables to be created, with the understanding that these may change as the project develops.
  • Agree guiding principles, e.g. user-centred design, drawing on industry norms, mobile-first, etc.
  • Agree measures to be used in ongoing research, e.g. main tasks to test, and task success rates.

Map out a calendar plan

  • Using agreed deliverables and taking resource into account, create a plan of when activities will take place, and when deliverables will be shared – taking into account the need for reviews and editing.
  • Ensure compliance (e.g. legal review) is addressed.
  • Stakeholders, including – but not limited to – the person commissioning the project
  • Product owner
  • Project manager
  • UX designers
  • User researchers
  • UI designers

For all stages, it is desired that as much of the project team is involved as possible

  • A signed-off UX strategy and principles deck
  • A list of expected deliverables
  • A rough calendar plan for involved parties (which has been communicated to them!)

Here’s an example of how a short UX project plan could look:

Plan what you’re going to do, and when… but for goodness sake write it in pencil!

Really understand the problem

Heuristic evaluation

  • This can be really useful, and doesn’t require huge costs or resources.
  • Nielsen’s heuristic principles provide an excellent basis – information can be found on the Nielsen Norman Group website.
  • Completing a heuristic evaluation prior to any user research means the ‘obvious’ issues can be addressed without eating up precious user time, meaning research relates more to how end users will use the product or service, and problems they may encounter.

Current journey mapping

  • Whether creating a new product or service, or redesigning an old one – there’s almost always an existing journey that the user completes to achieve their goal.
  • Mapping this journey generally uncovers steps and touchpoints previously unknown to, or considered unimportant by, the project team.
  • While an initial journey can be created from the team’s understanding of the process, this should always be validated with user research, as users will invent processes and workarounds to make life easier.
  • A great by-product of completing this with users is to identify current pain points.

User research

  • If there’s anything to test, test it! There’s no point trying to fix something if you don’t understand the problem.
  • Test the product with the agreed user base, and prioritise the main users.
  • Apply the measures agreed during planning; these will give a baseline score for the team to improve upon.
  • Depending on time, budget and resource, this can 2-minute guerrilla testing on the street, or full-blown usability testing in a snazzy lab with eye-tracking – whatever is appropriate. Some useful research methods include group sessions, surveys, A/B testing and analytics on existing products and services, interviews, diary studies, and ethnographic research.
  • Everyone
  • Everyone
  • No, really, everyone

Of course the UX designer (or dedicated user researcher, if you have one) is going to lead the research and prepare the materials, but every single person on the team should be involved in viewing the sessions, getting involved where possible, and evaluating the outcomes. A great exercise is, after every single session, to get all the observers to agree the top 3 “things to fix”, based on what that user had said and done. Themes will very quickly emerge.

  • Heuristic write-up
  • Journey map – or preferably, an experience map with pain points
  • Main research conclusions, with photos or videos
  • A detailed research report

Here’s a blog post I wrote while working with Land Registry, about research with external stakeholders, and how I mapped the conveyancing user journey:

Included in this post, I show a few deliverables I created for them. Here’s the user journey, mid-research. You can see it’s totally covered in scribbles – and this is just from one research session!

When testing on any device, an important step is to turn it on.

Figure out what to design

If you’ve done all the other stuff, this should be fairly straightforward! Many projects will have a requirements list or spreadsheet which will feed into this – but it’s important to know if requirements have been created based on user research or not. There can be a mismatch between user needs and business requirements; and it’s key to find a balance that works for everyone.

Personas

  • We’ve already created personas, but like other documentation these should never be considered “finished”.
  • Go back over the personas, and compare them with the research. If anything doesn’t add up, change them! We may find we need to create a new persona – but more than 8 should be avoided.

Task model

  • Now the current journey is understood, and we’ve figured out our goal, I find a task model can be incredibly useful.
  • I don’t mean this in a “what exactly will it do” way – think more along the lines of: “what are all the things that this product or service could possibly do, ever”. For now, don’t worry much about “how”.
  • Some of these tasks will have already been validated by users, or the business. Others will be ideas from the team, or just filling in gaps.
  • When this is prepared, it can be validated with the users and the business. Just like personas, this is never “finished”. Later, this same document can annotated to show what’s in each release. I think FreeMind and Coggle are great tools for this – or it can be done in Omnigraffle, or Google Drawings, etc.

Information models

  • Now that we understand our users’ mental models, we can map out different pieces of information, start thinking about taxonomies and how all these relate to each other.
  • Information models list out the different entities involved in a product or service (think anything that can be described as a noun, like a “basket” or “product”), what information is associated with each of them, what actions can be taken on them, and how they are related to one another – check out the examples tab for an eCommerce example.
  • Like task models, these should be edited, iterated and scribbled on whenever possible.

State models

  • Especially useful for complex products or services where your different ‘entities’ (the things you used in your information model) move through a number of different states. This diagram helps you to understand the different states they can move through – and what causes the change.
  • This diagram can be used as a checklist to ensure all states are designed for, and can also help to facilitate discussion within the project team about what needs to be built, and how.

User flows

  • Finally, based on the tasks we’ve identified that the user wants to complete, and using personas to select the primary user journeys, we can define main user flows.
  • These will be used for testing and can help in focus design and prototyping effort to the most important parts of a product or service.
  • UX designers
  • User researchers
  • Product owners and project managers, for validation of scope
  • Developers, for validation of ideas
  • Stakeholders should be involved when reviewing the outputs from this stage

For all stages, it is desired that as much of the project team is involved as possible

  • Updated personas
  • Task model
  • Information model
  • State models
  • User flows

There’s all sorts of useful diagrams that can be created to help the team understand how a product or service will work. Here’s an example of an information model, useful for designers to know what to display, and useful for developers to create relationships in the system. This is a great example of something that can be created in collaboration with the dev team.

Next is an example of a state model. In this example, it maps the different states that a ‘basket’ on an eCommerce site could move through. As you can see, this not only helps to facilitate conversations with the developers on your team, but can help you to understand the different states and error messages you’ll need to design.

Never take a designer seriously unless they have three or more highlighter colours.

Create initial designs

The scale of this step entirely depends on the project. We can create any, or all, of the following:

Whiteboard sketches

  • I love whiteboards. I love them so much that I bought one for my flat. What I love about whiteboards is that you can scribble something, and if you get it wrong, it’s gone in half a second. Almost everything I create in any wireframe or prototype has previously existed on my whiteboard. Because sometimes, it just takes drawing something to figure out what you need to do.

Paper prototypes

  • I’m not a big fan of paper prototypes in the traditional “draw with a pencil” sense. The reason is because while they work like whiteboard sketching, they take much, much longer. To drag, drop and resize a box in Axure takes me a few seconds. To draw the right sized box on paper takes double. And then if it needs to be a bit bigger, or smaller..? However – I do like to print digital wireframes and ask users to scribble on them. People love to get stuck in, and you can get a lot from users if you ask them to draw circles around things they think are good or bad.

Low-fidelity wireframes

  • Great for simpler products and services that don’t have a lot of states. I particularly like being able to see all the screens laid out side by side, to see the journey and number of steps at a glance. This sometimes isn’t practical if elements have a lot of states or are very complex, as there’s so many versions of the same screen that you don’t know where to look.

High-fidelity wireframes

  • Generally avoided unless producing concept work or comms. Why? Because people get hung up on the colours, or the shadows, or parts of the style that – at this point – aren’t the focus.

Wireframe prototypes

  • Most projects I work on ask for a prototype. They’re great because, especially if you use something like Axure or InVision, you can build up interactivity while wireframing, and also export the wireframe specification detail for developers. I prefer to keep these low-fidelity to avoid the wrong discussions; though it’s easy to substitute grey boxes for visual designs if needed. An important note when using these is to avoid creating absolutely every tiny detail of the product or service. It’s not a good use of time.

HTML prototypes

  • I can do a bit of HTML (I built a website from scratch once, because I’d done an HTML5 course on Lynda.com and wanted to put my powers to the test), but I’m no HTML prototyper. Some organisations – like GDS, for example – have dedicated front-end designers who’ll work with the research teams to create these. It’s nice that they feel more like using a ‘real thing’ when you test, but with that comes dangers; some users may not want to give lots of feedback if something looks ‘finished’, and HTML prototyping can take longer.
  • UX designers
  • User researchers
  • Developers, for validation of ideas
  • Stakeholders should be involved when reviewing the outputs from this stage

For all stages, it is desired that as much of the project team is involved as possible

  • Wireframes and/or a prototype
Coming soon!

As a rule, designers all have super-contemporary home offices with very stylish, slightly uncomfortable furniture. Surf boards are optional.

Test, fix, rinse and repeat