When beginning a project, clients and stakeholders will have an idea of what they want the project to achieve. Most at this stage will also have an idea of how they want it to be achieved.

Gathering and reviewing requirements will give us an idea of what we will need to produce to result in a successful project. It will also give us an idea of what research to perform with the users to find out if the project is needed to solve a problem that they are having. If the project isn’t solving a problem, is it worth doing?


Identifying the scope of the project early is very important. One of the things that has delayed most projects has been scope creep. When the team working on the project begin to work on areas that are not required at that stage, it will result in key parts of the project suffering from not having enough time to spend on them. The scope also covers what level of fidelity we’re working on with the project. Some projects will be full end-to-end projects, others just cover the elaboration phase, or require mocking up high level concepts.


With the level of complexity involved in the project, what resources will we need on it? If there is a large research portion, do we need dedicated user researchers involved? If the project is to produce a proof of concept a user interface developer may be needed. If the project is to support a bid for a larger pieces of work, a visual designer for high fidelity mockups may be required. Knowing who we need for the project and for how long will help us provide more accurate time and cost estimates for the project.

Target users

What users are we targeting with this particular project? Are there current users of the system? Are we targeting all of them? A subset? Maybe we’re branching out and targeting a completely new user group that, so far, we had not considered. Knowing who we’re designing and building for has a big impact on the project. A system that needs to be used by high school age teenagers will work very differently than one being used by business executives nearing retirement age.

User surveys

I like to send out surveys to wider user groups early in the project. This is to get an understanding of any user wide trends that we should be aware of. It can help to identify that out of one of the user groups we had identified, it can be further broken down into those with high technical ability and low technical ability. This information can help to provide more specific information for creating personas.

Stakeholder interviews

Who are the main stakeholders for the project? A stakeholder is anyone who has an investment in a project. These can be company directors, board members, project team members, users of the system, and even suppliers and other people external to the business that the project may affect.

I like to talk to these stakeholders about what they would like from the project?What are their ambitions for it? How would they like to see it support them, or it’s users.

Ethnographic research

This refers to researching how users perform their task and in what context. Using ethnographic research lets me see how people do their jobs, or perform tasks in context. These tasks my happen completely outside the system that we’re creating, but it lets me empathise with what the users do on a day to day basis. Knowing the context that they will use the system can have a massive impact on how the project is structured.

Competitor analysis

What are other businesses in this space doing? Are there any trends that we should be aware of? What works well, so we can make sure it’s considered? What doesn’t work well, so we know to avoid? This can give us a great insight into what people expect.

Competitor analysis can also include businesses in different fields. Ideas from banking can help to solve problems in healthcare. Those from e-commerce can help with stock management..


User experience design means designing for users. When working on projects it can be easy to lose sight of this. Personas let me keep an eye on the user, or at least an approximation of the user, that I’m designing for.

Personas aren’t only useful for me. They’re also useful in keeping stakeholders on the right track and remember who the system is designed for.

Journey mapping

Taking storyboarding to the next level, journey maps are used to show an overall view of a users entire experience. They’re especially useful for identifying gaps in the experience. They show where users move between processes, departments or devices when engaging with the system. They also show the more intangible elements of the experience such as feelings and questions.


Especially useful for breaking down the journey into individual tasks. Swim lanes are very flexible in that the lanes can be appropriated to show different information depending on what needs to be presented.

Lanes can show a user performing a task and moving between systems, across physical locations, or across devices.


I use wire flows to present how the flow of screen will work together. I find it useful to talk about how the user will progress through the system and the interactions that will happen at each stage without going into detail. It can help solidify how multiple interactions can happen on one screen, and what types of information would be displayed on each screen.

Card sorting

I’ve used a card sorting exercise on nearly every project that I’ve worked on. It’s a clear and engaging way of organising information, and can be done as an individual task or as part of a group. The low fidelity of this activity means that those taking part are encouraged to move cards around and even start from scratch without feeling like they’re throwing work away.


Pen and paper sketching is the quickest way to get ideas across, and get feedback. They can be used to look at the overall layout of a page, or pick out individual elements more specifically.

Due to the nature of sketches as being throwaway, they can be used to explore multiple ideas quickly using methods such as "6 up sketching".

Information architecture

This looks at the structure of the system. How the information relates to each other, and how it is presented. Information architecture involved looking at the content of the system and organising it so that it makes sense. It groups and categorises information so that the user can find the information that they need and perform their tasks in a logical way.


These are the blueprints of the screens. I tend to keep these at a low fidelity. The idea of wireframes is to work out the structure of the screens in a format that can be changed quickly and easily based on testing and feedback. Changing layouts and design elements at this stage saves much time rather than changing things at a later stage.


A prototype is an extension of the wireframe.

Interactive elements are added that help to test the concept of the design.

I create prototypes in prototyping software so that ideas can be tested and iterated on as quickly as possible.


Although I rarely create full concept mockups, occasionally I will create them for key screen in the system. These are usually used for presentations to high level stakeholders.

I also sometimes create mockups to help me visualise the visual design of the system when creating the style guides.

Style guides

I create consistency across a system by creating a style guide.

The style guide can cover design philosophies to be used on the project, information on layout and structure, visual and typographical styles, and in some cases will include guides on content creation.

Show and tells

As part of the design process I will usually present the design solutions to the stakeholders and walk them through whatever deliverables that have been created. The deliverables may by user journeys, wire flows, visual designs or prototypes.

The stakeholders can see the progress that we have made and can give feed back and have discussions on the direction of the project.

User testing

Testing can happen at various stages during the process to get feedback and discover problems. A number of different method such as focus groups, moderated usability testing or a/b testing, can be used for this depending on what needs to be tested.

Analysis and iteration

The results of user testing need to be analysed. The feedback is grouped and prioritised so that improvements can be made to the design. The design is then updated and tested again to test that they changes improves the design. These iterations can occur multiple times during the process.