Design Process

I use a blend of Goal-directed™ design, Lean UX and gorilla UX methods.

Build a shared understanding of the project

Explore and understand what problems we are trying to solve

Agree a definition of success and how we are going to measure it.

Understanding business goals is an essential part of any brief, but UX design often seeks to uncover and clarify business values, vision and mission as well as these will underpin the approach to user engagement.

Speak to users, observe them if possible, understand their pain points and goals. What are their concerns, you want to understand how and where your product fits into their lives and see the bigger picture.

We want to know about the environments they work in, what tasks they perform, how often the perform them, their level of IT competency, what are they trying to achieve, the issues and problems they encounter, the other sites and services they use.

You may also want to

  • Collate existing user feedback and prior feature requests
  • Gather anecdotal evidence and insights from customer services

A first port of call for many is Google analytics as it can help identify many aspects of user behaviour. Facets such as bounce rates, depth of engagement and traffic sources will help you identify problems and opportunities.

For the Royal Pavilion and Museums website, analytics helped us identify many users trying to find opening times which on inspection were difficult to find.

Other sources of quantitative date may include market research and customer segmentation data.

User experience design

UX design creates more effective user experiences by exploring users’ needs and understanding project goals.

It is the user that has the experience – the designer shapes the experience.



Map illegal animal trading across the globe. Trademapper in an interactive mapping tool to visualise trade data developed by TRAFFIC.

Weather Station

Weather Station

Desktop PC software to set up and monitor professional weather stations.

Remedy e-Democracy

Remedy e-Democracy

Remedy UK was a pressure group representing junior doctors in the United Kingdom. Helped to formulate their communications strategy and harness the power of their constituency.


Personas are individuals that represent groups of users with the same goals. We represent them as realistic individuals with names and short narratives to describe their goals, attitudes, engagement and motivation.

Three example persona highlights

Personas describe behaviours that are common to specific groups of users, not average ones.

There will be primary personas – our target users – and secondary personas whose goals and behaviours differ but should be accommodated.

In museum design, we also refer to Falk profiles which are described in more detail on the Huguenot Museum project page.


Using our personas we create short narratives that describe ideal user interactions with the product, called scenarios.

We have previously found out how our users currently interact with the product, we know what tasks they undertake and have researched what they are trying to achieve. When we create scenarios, we are exploring the ‘what if’ questions that seek to create an idealised ‘day in the life’ set of interactions with the product.

Example scenario

Originally developed for MetView weather station software.

… let’s take the scenario of the crane driver Murree told me about. Let’s call him Johan, he’s 33 and operates a crane at the docks in Aarhus in Denmark.

Johan is up at 5:30 with his young children and while his wife is giving them breakfast, he checks his mobile to see if it’s OK to work in the crane today. If it’s too windy, Johan works at the depot and wears different clothes. There are no alerts so he gets ready as usual and drops the children off on his way to the docks.

By lunchtime the weather is getting worse and his manager Morten calls him to to let him know that it’s looking like the day will be cut short and to prioritise unloading Container B. Johan calls his wife to let her know he might be able to pick up the children later on.

At 3pm Johan’s phone is alerting him because the wind is nearing the cut off safety point that has been set. It takes him ten minutes to shut down and get down from the crane and that needs to happen before it becomes unsafe.

He dismisses the alert so his boss knows that he’s seen it and carries on unloading Container B. By 3:45pm he receives an alert to stop working, acknowledges that he has received and is acting upon the alert and calmy shuts down the crane and leaves. By 4pm he’s at the depot and calls his wife to say he can pick up the children.

As we can see from this scenario, Johan has a specific set of goals – to work safely and know when that isn’t the case – and has limited interaction with the product – an alert is perhaps all he needs. He is a secondary user.

His manager Morten however, manages 24 other cranes in different ports around Aarhus and has a very different relationship with the product. He is looking at trending information, scheduling work and planning the day ahead. He needs to see the bigger picture and is more focused on prediction. As a primary user, we would draw up a persona for Morten which expresses his goals and a scenario that describes his idealised interaction.


Together, personas and scenarios help us to define requirements with confidence and create a blueprint that can be implemented in the user interface design phase that follows. 

Wireframes are commonly used to do this, though increasingly prototypes are seen as a faster way to refine and prove a design solution.

A wireframe is a simple document that outlines what goes on each page and should convey the relative importance of the elements on the page. Although it is not an exercise in layout design, it’s hard to separate the two. Not always a good idea to share with the client (‘we like the white, but it’s a bit plain’) but essential if you’re working in a team.


Bring ideas to life quickly, explore user journeys and refine the user experience.

A prototype is easier to understand, easier to test and an effective way to explore new ideas and concepts quickly.

Refine the user experience, make better products and speed up development time.

Explore these prototypes

Remote and recorded tests

Remote testing

User interviews


Loop 11


User interface design

We don’t really notice well designed interfaces – they cause no friction. Poorly designed interfaces however, can quickly bring you to your knees.

No matter how cool your interface is, less of it would be better

Alan Cooper, Cooper Design



Map illegal animal trading across the globe. Trademapper in an interactive mapping tool to visualise trade data developed by TRAFFIC.

Weather Station

Weather Station

Desktop PC software to set up and monitor professional weather stations.

Vocal Eyes

Vocal Eyes

An acccessible & responsive website for renown charity that provides audio description and touch tours to theatres and arts organisations for the visually impaired.

What can we do about this?

Poor user interfaces are often focused more on the input that the system requires to move forward – known as a system-centric view – rather than the messier way humans work.

A user-centric view places the needs of the user at the centre of things and the system works towards satisfying them.

  • How can we reduce cognitive load?
  • Is there an established design pattern for this?
  • Have we established the visual hierarchy?
  • Does the user need this right now?
  • Is it clear what the user should do next?
  • Does it scan well?
  • Is the look and feel appropriate to the brand?

A user interface designer advocates for the user, they accept responsibility for them.

Consider how the interface will keep the user informed; to let them know when they’re doing it right and when they’re doing it wrong. It doesn’t take much to feel out of your depth if things don’t make sense and often it takes only a little intervention to smooth out any bumps. It does take time though.

A UI designer’s job is to build trust, reassure and stop things getting out of hand.

Following established design patterns in an interface reduces cognitive load – how much we need to think about something – by following established mechanisms and interactions.

Anticipate where and when users may need further tools or help and help them orient themselves by providing a consistent and obvious structure.

We all know how to use a key; you push it in and turn. Make your UI like a key by using established design patterns rather than trying to come up with something new that will cause the user to have to think way more than they need to. Check out

The UI needs to be provide some kind of feedback loop so the user knows something is happening, that the system is working and is responsive.

Setting different states to your links and buttons is a an easy win. Active, clicked, visited and default states provide a lot of orientation information to the user.

*Target focus states too as not everyone uses a mouse.

Designing for mobile means you have to cut out a whole load of features simply because you can’t show it all on a tiny device. The small screen size means you have to focus on a much smaller set of controls.

Part of the reason the iPod was so widely adopted was because it made playing music really easy, a one-fingered exercise. It was simple because it had few features. Making a playlist was a nightmare for example, it was not a primary function. Sacrifices were made, options were dropped.

When the iPod was released, the dominant thinking on the web at least was that everything needed to be available in two clicks – at most.

Apple made bold moves and created better products.

If you still need to have seven items in a right-click menu list, please get in touch.

Design speak for ‘looks like what it is’. If your buttons don’t look like buttons, if your links aren’t distinguished from the things around them, how are we going to know we can click on them?

Give users a chance.

Do you really expect users to be using this everyday? Maybe, but it’s more likely less frequently. You need to hide a whole load of great things your interface can do. Focus on core tasks. Be brave. Do less.

If you are developing a product you know will be used frequently, you’re going to need to think about how users needs change over time. Work out how to reveal advanced functionality gracefully, decide on how you can support the needs of power users. Keyboard short-cuts are your friend.

Use language appropriate to your research and knowledge about your audience. Use the terms the audience uses. There’s a big difference between ‘Upload’ and ‘Beam me up Scotty’ – so choose the appropriate tone.

It’s all about the labels. Labelling menu items, buttons, lists and especially forms is really important to get right, yet it is both difficult and notoriously under-valued.

As a UI designer you’ll probably end up doing most of it yourself. And writing most of the home page copy.

Use simple common verbs to label things. ‘Send’ is easier to process than ‘Send this message’.

Reduce the amount of thinking your user needs to do. Jared Spool has interesting things to say about trigger words in links.

Understand your users’ needs and then design the interaction flows before going into production, it’s much cheaper in the end.

Focus on showing more content and less of your UI. Think mobile first, make some tough decisions about limiting options, get your interface out of my way – please.

Think about how dense the content is – is it appropriate to the context?

In a search mechanism it may be appropriate to show lots of tools and search results and be information dense.

In a reading environment, we may need want our information less dense.

If you don’t use real content, you are designing a dream – lorem ipsum just doesn’t cut it in UI design.

App design

In some ways, designing for mobile devices is easier than designing for desktop, as the small scale factor means you have to make many more decisions about how content is structured and flows.

Design with less

With a much smaller canvas, you have to prioritise first and foremost what the user sees.

Everyone wants to achieve the feel of a simple app, one that feels easy to understand and use, but understanding how you achieve that is less well understood.

Making something user-friendly is not added on by a designer once the content is ready, you need to design with the content and for the user.  If you want it to be simple, make the content simple. Make some hard decisions and cut things out. Do less … but do less brilliantly.

A user-centred design process is a great framework to follow for success.

Why go native?

There are many advantages to designing a native app

  • smoother transitions
  • finer control
  • integration with other applications such as camera/gps/sharing
  • distribution via the appstore, the in-built payment model.

However, HTML5 has enabled browser-based websites to access many of these features too and with support for local storage, HTML5 websites can now work offline too.



something here


It’s a busy competitive market out there and users have high expectations for your product, they want it to be great, to deliver real value to them. Finding out how competitors do things, what design patterns they use, the style and language they adopt, the features they stress all help you benchmark the market in terms of approach and user expectation. You may need to position yourself against these markers, but these elements form your toolkit, they’re part of your brand. If you don’t have any competition, think again my friend, at the very least you’re competing for people’s attention and time. Find out more about how to conduct a competitor review.


If the answer to the question ‘Who is the target market?‘ is ‘our product’s for everyone!’ then please read on …

… Try this clumsy analogy … let’s assume that we all use soap. While I may like soap that wakes me up in the morning with an acrid bouquet, you may prefer a more subtler start to the day and hey my kids want stripes in theirs. It’s all soap, but when I last looked there were 20 different types and that’s not even including shower gels. The point is, we have different tastes and motivations and what I like you may not. Your product is going to be targeted at a set of people who share some things in common – what are they? It’s probably not that they all like soap, but it might be something that motivated them to look at your product, they want to feel something when they use your soap.

Vocal Eyes

Vocal Eyes

An acccessible & responsive website for renown charity that provides audio description and touch tours to theatres and arts organisations for the visually impaired.

Royal College of Music

Royal College of Music

A responsive search interface to the RCM catalogue for research professionals and general users.

Modern Poetry in Translation

Modern Poetry in Translation

A website to celebrate 50 years of this esteemed poetry publication.

Remote and recorded tests

Remote testing

User interviews


Loop 11




jQuery & libraries

LAMP stack




Custom Content Management