A detailed breakdown of my process when researching, designing, and building projects.

My Process

I make my process around creating Artefacts and Deliverable that detail the work I am doing. This creates a library which circulated around the team, and to stakeholders, detailing the research, journey flows, design or analysis we have done. I find that building a process around documents helps focus us on identifying problems and working solutions.

My Research Process

My Research Process is designed to be flexible, adapting to the specific demands and constraints of each project.

  • Define the problem we are going to be addressing.
  • Outline what I will be going to investigate the problem.
  • Find some users and talk to them about their behaviours, and how they use our product.
  • Find some data and analyse it to find out what people do on our product.

The goal is to validate our existing theories and uncover new insights that might lead to fresh perspectives.

Research Process: Deliverables & Artefacts

Not every project uses every artefact but I've found that the Product Goal Statement is a brilliant base to reference back to so it is a must have, and the User Experience Discovery Statement defines what the team can expect me to be doing, which allows the project's management team to build confidence and managing expectation.

The other Deliverables represent something of a Swiss Army Knife for UX, with each one absolutely useful for some projects, and not at all used for others. Customer Interaction Mapping is often very important and successful projects will always have an idea of how their product is used.

It is difficult to get a User Interviews Highlight Reel for every project but it can be very effective.

Product Goal Statement
  • Defined A few high level sentences about what the Product is trying to achieve that sets the terms for the UX process.
  • My Note Before beginning the research process, it's important to get everyone aligned on what we believe the project will achieve. Research may challenge or even change those assumptions, but documenting them and reaching a shared understanding is always a valuable first step.
  • tl;dr A few high level sentences about what the Product is trying to achieve that sets the terms for the UX process.
  • Description The Product Goal Statement details in the broadest way who the product is being built for, what we want to build that product and what problem with believe the product will solve. It either presents evidence or defines what will constitute evidence that the built product will achieve the goals set, and it talks about how we will measure that goal.

    While the Product Goal Statement frames much of what the Discover phase and the UX process will be, and while UX contributes to it heavily, it serves to set terms for the UX process to follow.

    These goals should tie back to the Product Vision with the assumption being that if the Product Goal is achieved then we will be closer to realising the vision.
  • Best Version Three well written paragraphs which state the business aim of the Product, how those aims will be achieved, and how progress towards that achievement will be measured.
  • How To Use The Product Goal Statement one pager has two main functions

    The first function is to (re)align the team as to the purpose of the Product being worked on, affording the chance to change that purpose if it is appropriate.

    The second function is to set a context for the work which follows in Discovery, Design and Performance.
  • Created With / By Led by the Product Owner with the full Team.
  • Created Always
  • Created By Product Owner
  • Created With Team
  • Format Text (One page maximum)
  • Format Text: Team Workspace (Confluence, Jira), Word Document. One page maximum.
    • Read More
    • Less
User Experience Discovery Statement
  • Defined A statement on what UX needs to have before it starts, what methods it will use to get to an outcome, and what the output is expected to be and how long it will take.
  • My Note UX research can vary greatly in scale and duration, and when it's a large undertaking, it's important to prepare the project team for that. Clearly outlining the methods and approach the user experience team will follow helps set expectations and ensures everyone understands the process.
  • tl;dr A statement on what UX needs to have before it starts, what methods it will use to get to an outcome, and what the output is expected to be and how long it will take.
  • Description User Experience Discovery Statement is an attempt for the UX to define is terms of engagement.

    The statement should start off with some details about what UX needs before it can begin working. We might need equipment, or data, or access to resources, or any number of things without which the process will become blocked. This ties into the methodology which is going to be employed within Discovery and what we need to do it. If we are planning to do in depth interviews with five users then we need to surface the idea that those users need to be found as early as we can.

    The statement will also have a breakdown of what the output of the User Experience Discovery phase will be. This will prepare the team for what they will get from the process and allow them to challenge that if they feel the Product needs something else.

    Finally, the statement details how long everything should be expected to take. This is a rough estimate but attaching a date both helps the team plan and keeps the UX from becoming esoterically distracted.
  • Best Version A one-pager which says what is needed, what will be done, and how long that will take to produce a clearly defined output.
  • How To Use The User Experience Discovery Statement tells the rest of the team and the business what they should expect to get at the end of this process, how long it will take and what involvement they are expected to have in it.
  • Created With / By UX assisted by the Delivery Manager.
  • Created Always
  • Created By Me
  • Created With Delivery Manager
  • Format Text (Two page maximum)
  • Format Text: Team Workspace (Confluence, Jira), Word Document. Maximum two pages.
    • Read More
    • Less
Competitor Analysis
  • Defined Finding who else is creating similar products and learning from the strengths and weaknesses they have.
  • My Note Reviewing how competitors approach similar challenges helps reveal the nature of the problems users face and the different ways those problems are being solved.
  • tl;dr Finding who else is creating similar products and learning from the strengths and weaknesses they have.
  • Description Part of a Competitor Analysis is comparing our Product to the market and finding comparable experiences. Most products operate in a market with competitors who provide good comparisons, but it is also advisable to look wider. Customers spend 99% of their time using other people’s products and their experiences doing that condition them for what they expect from us.

    An example might be looking looking for a similar experience which people would find comparable.

    Another part of this analysis is to look for what can be learned from those experiences. Common standards are identified here and can be noted for reuse and solutions which have worked well or poorly are also obvious when someone else has used them. We identify easy to use experiences as well as those which presented problems.

    Finally, there is an analysis of what competitors do poorly which, should we do well, we might take a competitive advantage from.
  • Best Version A document which discovers what is good, what is bad, and where our competitors are weak and where we can take a competitive advantage by exploiting that.
  • How To Use The Analysis largely rolls onto the broader User Experience work informing the next stages of the process.

    The Competitor Analysis can be useful in the project also when suggestions about how to do something are raised and practical examples are needed to illustrate decisions made.
  • Created With / By Created by UX.
  • Created Often
  • Created By Me
  • Format Text and/or Presentation
  • Format Text: Team Workspace (Confluence, Jira), Word Document and/or Presentation: PDF, Powerpoint
    • Read More
    • Less
Content Discovery
  • Defined A document that details content on the product what is mandated, which needs to be edited, and which is to be removed.
  • My Note Understanding what content will be available - and what I can confidently expect to have - is essential when planning user journeys and determining what each persona will take away from their experience.
  • tl;dr A document that details content on the product what is mandated, which needs to be edited, and which is to be removed.
  • Description Not to be confused with the audit of content which follows Content Discovery is about discovering what content on a product needs to be kept, and what can be edited, and what could be removed.

    Content Discovery should include finding out who is responsible for creating that content.

    The outcome of this should be a kind of foreknowledge of chunks of text which have to be on a product. Health and Safety advice, legal notices, terms and conditions which are unavoidable are flagged up here as well as content which needs to be highlighted.
  • Best Version Details on the length of mandated content and where it has to appear, on content which people want to highlight, and general overview of what over content should feature.
  • How To Use The Content Discovery document becomes a part of the UX Design Process.
  • Created With / By UX with the Business Analyst, normally prompted by the Business Analyst. Product Owner and any SEO resource are often involved too.
  • Created Rarely
  • Created By Me, normally prompted by the Business Analyst.
  • Created With Product Owner, Business Analyst, SEO
  • Format Text
  • Format Text: Team Workspace (Confluence, Jira), Word Document
    • Read More
    • Less
Customer Interaction Mapping
  • Defined A visual representation of the customer interaction with the product.
  • My Note This can be a really important part of communicating to the team what else our users are doing when they are not interacting with us, and how that influences those interactions.
  • tl;dr A visual representation of the customer interaction with the product.
  • Description The Customer Journey Mapping is a visual representation of how the people, when they are using the product, are feeling. This highlights times when people are happy using the product and why they are happy, and times when people are less happy and the reasons for that. These are the touchpoints that people have with the product, and they are not all in the remit of the product.

    If we take the example of a log in system someone might be happy when they start using it, get a password wrong and become frustrated, then become anxious when they get the password wrong for a second time and are threatened with being locked out of the system, and then return to being happy after a lengthier interaction with a forgotten password system.

    The purpose of a Customer Journey Map is to help the team empathise with people using the product.

    The Customer Journey Map is based on the as is product as opposed to the proposed solution. The proposed solution is in New Customer Journey Mapping.
  • Best Version An easy to digest image of how a person’s mood is changed during interactions with the product.
  • How To Use The team will use the Customer Journey Map to design the solutions, and to prioritise the backlog.
  • Created With / By Customer Insight Manager may provide insights.
  • Created Often
  • Created By Me
  • Created With Customer Insight Manager
  • Format Text and/or Presentation
  • Format Presentation: PDF, Powerpoint
    • Read More
    • Less
User Interviews Highlight Reel
  • Defined A collection of short clips from interviews to highlight issues people have around the product.
  • My Note I value creating a highlight reel that captures the key takeaways from user interviews. User experience work becomes more meaningful when the team can empathise with the people they are creating a project for, and seeing users speak directly helps build that empathy.
  • tl;dr A collection of short clips from interviews to highlight issues people have around the product.
  • Description As a part of the interview process to gather some qualitative insight often there is an output of hours of footage of people talking about the product. That footage is insightful, and interesting and very important, but it is long and because of that length it is overlooked.

    The User Interviews Highlight Reel, as the name suggests, is a cut of those videos into affinity grouped sections which highlight insights. The clips are kept short and the insights offered are made clear.
  • Best Version Five minutes of highlights with a minute devoted to each of five insights.
  • How To Use The highlights are distributed to the team and the wider team to build empathy and to illustrate the problems which need to be solved.
  • Created With / By None
  • Created Rarely
  • Created By Me
  • Format Video (Five minutes maximum)
  • Format Video
    • Read More
    • Less
Behavioural Data Research Output
  • Defined An overview of the behaviours of people on the product drawn from data. An outline of the problems which the data shows us.
  • My Note The most valuable part of analysing data is when it either confirms or challenges insights gathered from user interviews. Solid data helps keep projects grounded and honest.
  • tl;dr An overview of the behaviours of people on the product drawn from data.
  • Description Behavioural Data Research Output presents an overview of what people are doing when they use the product. As a document it is focused on the results of people using the product - be they conversions, dropped sessions, revenue generated per interaction - rather than the reasons for those results and as such it is used in conjunction with other research.

    The Output should focus on the areas in which user behaviour is unexpected in order to drive research. It should bring up the statements of what has happened in order to drive the question as to why it has.

    An example of this might be the data insight that a number of people visit a page on the product, perhaps a product page, and then close the session and stop interacting. The factual record of these things is what is focused on rather than the motivations for that.
  • Best Version Details about where significant aberrations have been occurred.
  • How To Use Behavioural Data Research should feed into the broader User Experience research. It can be used to inform the team of the motivations behind UX decisions.
  • Created With / By Data Analyst.
  • Created Often
  • Created By Me
  • Created With Data Analyst
  • Format Text and/or Presentation
  • Format Presentation: PDF, Powerpoint and/or Text: Team Workspace (Confluence, Jira), Word Document
    • Read More
    • Less
Quantitative Research Output
  • Defined An overview of the research into users which discusses the data and the results of surveys we have conducted.
  • My Note A good Research Output Deliverable both draws conclusions from data, and presents that data to allow other team members to draw conclusions.
  • tl;dr An overview of the research into users which discusses the data and the results of surveys we have conducted.
  • Description Quantitative Survey Research covers a number of ways of getting information about a product from short intercept surveys on a product to larger usability or attitudinal questions.

    The surveys are typically done asynchronously and remotely and produce a combination of quantitative and qualitative results. The results of these surveys are analysed and presented in context. This context is important to avoid the answers to the surveys being perceived as requests rather than data to be aggregated.
  • Best Version Details about the questions asked, the results gained, and what can be understood from those results.
  • How To Use Quantitative Survey Research Output goes into the broader User Experience research. It can be used to inform the team of the motivations behind UX decisions.
  • Created With / By Customer Insight Manager
  • Created Often
  • Created By Me
  • Created With Customer Insight Manager
  • Format Text/Visual
  • Format Text: Team Workspace (Confluence, Jira), Word Document and/or Image: Figma, Miro, Adobe UX, Sketch
    • Read More
    • Less
User Experience Expert Audit
  • Defined A review of the journeys on the current product and their effectiveness.
  • My Note There is often valuable insight to be gained from the project being replaced, yet newly formed teams frequently overlook this knowledge.
  • tl;dr A review of the journeys on the current product and their effectiveness.
  • Description The UX expert audit looks at the current status quo - probably an existing website journey - and identify on that areas of concern which any solution would form itself around. An example of this might be looking at a journey and noting elements which have problems such as a Carousel, and then suggesting that might be an area of potential improvement. When the team look at this they are able to add supporting data or views generated from their exposure to the product. This work often goes hand-in-hand with the Competitor Analysis.
  • Best Version A document which looks at the journey and highlights issues which form the basis of a discussion about improvement.
  • How To Use The document is presented to the team and forms a part of the broader User Experience research.
  • Created With / By Business Analyst can provide data around page use.
  • Created Often
  • Created By Me
  • Created With Business Analyst
  • Format Visual/Text
  • Format Text: Team Workspace (Confluence, Jira), Word Document
    • Read More
    • Less
Accessibility Audit
  • Defined A review of the product and how it performs against accessibility criteria.
  • My Note Many products include decisions made for accessibility reasons, and these choices remain important, even when the project undergoes a refresh.
  • tl;dr A review of the product and how it performs against accessibility criteria.
  • Description Where there is an existing product or journey a review of that product and how it performs against both the accessibility aims of the team/business and a broader view of accessibility is conducted and the results presented either as a series of problems to be solved by the design which are added to the Dilemma or recommendations for changes to design and coding practices.

    In the former case one might add an accessibility issue as one of the problems to be solved by the user experience design. In the latter one might highlight issues with the product which can be solved with changes to the current system. An example of the latter might be changing the HTML on input fields to add a label for audio readers, an example of the former might be that people using the product with low mobility struggle with the interactions.
  • Best Version A presentation of clear challenges which the product presents set as problems to be added to the Dilemma and a report on changes which can be added to the backlog away from the UX process.
  • How To Use In some cases the Accessibility Audit forms up a part of the User Experience process, in others it feeds into the Product Owner’s backlog.
  • Created With / By
  • Created Often
  • Created By Me
  • Format Text
  • Format Text: Team Workspace (Confluence, Jira), Word Document
    • Read More
    • Less

Definition

Defining The Project takes the research and turns it into something which can be used to guide the project.

  • Create Personas. I like to create mine grounded in empathy.
  • Write a Solution Statement to communicate the next steps.

The goal is to make a well-crafted set of personas to serve as a North Star, guiding every decision throughout the project.

Definition: Deliverables & Artefacts

If user experience is about empathy, and we get that empathy by talking to people, I think that Personas are the way that we communicate that empathy. Even if a project does not want "Alan, 37" and his profile lovingly created with quotes and a photo, as a UX Designer I need to know that information.

There are always Personas, even if they are not surfaced.

With the Personas though, there is also a Solution Statement at this point about what the next steps are, and when and what the team can expect.

Personas
  • Defined An overview of the people who will use the product or, if the Personas are already in situ, an overview of how those Personas will interact with the product.
  • My Note There are many ways to create personas. While I often favour the traditional format - “Asha is a... she wants...” - the most important goal is to produce a document that clearly communicates who our users are and what they need..
  • tl;dr A profile of a person used to represent a grouping of people who have goals and behaviours which represent the needs of a larger group.
  • Description A persona is a one or two page profile of which highlight the behaviours, goals, attitudes, characteristics and background information of people who use the product. Personas can also include representative fictional details to make the persona a realistic character such as a name, age, photograph or location as well as demographic and biographical information which is drawn from the data gathered in the UX Research period.

    Personas are drawn from User Interviews with characteristics affinity grouped together to create a representative example and supported by data drawn both from the business and from a broader view of the environment the business operates in.

    Personas are, largely, a summation of all the User Experience Research process. User Experience is a process of focusing our work around the people who use our products. By summing up that research in the form of profiles of people we bake in the idea that people are the source of our solutions.

    Should the UX Research not call for a new set of personas - and often it will not - then the existing set of personas should be referenced in the context of the problems at hand and the solution being offered. Ways in which a problem impacts certain personas, and ways in which the solution would help them, would be appropriate.
  • Best Version A synecdochic view of a person or group of people which generates both understanding of the issues faced when using a product and an empathy for people solving those problems.
  • How To Use Personas should be used by all parts of the team to understand the people who are using the product.
  • Created With / By None
  • Created Always
  • Created By Me
  • Created With Product Owner
  • Format Text/Visual
  • Format Text: Team Workspace (Confluence, Jira), Word Document and/or Presentation: PDF, Powerpoint
    • Read More
    • Less
Solution Statement(s)
  • Defined A few high level sentences about what the UX Design Process will achieve.
  • My Note As with earlier steps, it's important to communicate to the team what you will be producing - and how - so everyone knows what to expect.
  • tl;dr A few high level sentences about what the UX Design Process will solve.
  • Description The Solution Statement a few sentences about what the UX Design Process will achieve and is created to address the aims of the Product Statement Goal. It is the promise which the UX makes to the rest of the team as to what they can expect both in terms of the output, and the effect of that output.

    Typically, The Dilemma Statement will say which artefacts the UX Design process will go on to create and what purpose they will serve. An example might be a collection of 10-15 wireframes in the form of a wireflows to illustrate the new checkout process to reduce the 20% abandoned rate in baskets in alignment with the goal of increasing conversions on the website.

    These statements are agreed with the Product Owner to make sure that they are in alignment with the Product Goal Statement. The Solution Statement concludes the UX Research section.
  • Best Version A statement on what problem the solution will address, an overview of the solution, and an indication as to how that solution will align with the Product Goal.
  • How To Use The Product Owner will use the Solution statement to be informed about what they are expecting to get from the UX process.
  • Created With / By Agreed with the Product Owner.
  • Created Always
  • Created By Me
  • Format Text
  • Format Text: Team Workspace (Confluence, Jira), Word Document
    • Read More
    • Less

Mapping

Mapping is where I bring the research to reconnect with the wider team.

  • I create an Information Architecture that will become a keystone for the project.
  • Collaborate with the team to discuss what the research means and turn the vision into a shared solution.
  • Map out people's journeys trough the website, which is the backbone of the Design phase.

The goal is to start the collaboration across the team.

Mapping: Deliverables & Artefacts

The aim of the mapping phase is to create an Information Architecture that will become a keystone for the project.

A set of interconnected User Journeys are also necessary when we create the wireframes, so discussing that with the Team and getting input makes that process stronger.

User Journeys
  • Defined A map of the new structure of information in user journeys normally viewed through the personas.
  • My Note Anticipating the paths that different users will take through the project, based on our research, helps shape the wireframes that follow. Mapping these journeys at this stage is not only essential for planning the wireframes, but it also produces a document that the team can review and challenge.
  • tl;dr A map of the new structure of information in user journeys normally viewed through the personas.
  • Description When a user, created in our Personas, encounters the product they navigate through that product. That navigation is recorded as one or more sets of User Journeys.

    A user journey, at the most basic level, will detail movement from page to page with more details around the elements on each page which may have satisfied, or may have frustrated, a user illustrated.

    As user journeys become more advance they will detail more about what the user wants from an interaction and how those interactions impact mood. They will talk about what content appeals to a user and how that content should be shaped as well as the functionality a user may need to facilitate their journey.

    User journeys can also be used to illustrate divergence and merge points which different users share as they navigate the product indicating interactions which are both important and have to serve multiple goals.
  • Best Version Journeys which illustrate and communicate the reasons for decisions made in the UX process as well as how the product will meet the Product Goal Statement.
  • How To Use The Product Owner will use the User Journey to ensure that the Product’s Goals are met by the UX.
  • Created With / By Created by UX.
  • Created Always
  • Created By Me
  • Format Text/Visual
  • Format Text: Team Workspace (Confluence, Jira), Word Document and/or Image: Figma, Miro, Adobe UX, Sketch
    • Read More
    • Less
User Flows
  • Defined An idea of how people can interact with the product to do tasks.
  • My Note If a user journey outlines the tasks people will perform within a project, then flows break down how they will interact with specific elements. For example, a journey might show that a person wants to buy insurance, while a flow details the specific information they expect to enter. Planning these flows at this stage facilitates conversations with the development team about what the back end needs to support.
  • tl;dr An idea of how people can interact with the product to do tasks.
  • Description As a part of the Mapping process User Flows are related to, and very similar to, User Journeys.

    A User Flow is created by the business - most often by the Business Analyst but often by the Product Owner - to illustrate an issue with the product. If a field on a form is often being filled in incorrectly it is often the Business Analyst who will present this in the form of a series of screenshots with notation and suggestions. This becomes a User Flow after the expertise of User Experience has been brought to provide an improved solution that looks at both the current structures of the product and the business and on usability principles.
  • Best Version Detail of the problem presented which has been brought into line with the holistic user experience.
  • How To Use The Business Analyst may be able to use Wire Flows directly with other members of the team or Wire Flows may feed into the Illustration Group.
  • Created With / By Created by Business Analyst and/or Product Owner with the support of the UX.
  • Created Often
  • Created By Business Analysis
  • Format Text
  • Format Text: Team Workspace (Confluence, Jira), Word Document and/or Image: Figma, Miro, Adobe UX, Sketch
    • Read More
    • Less
New Customer Journey Mapping
  • Defined A way of illustrating someone's interactions with a product in the broader context of their lives and the changes to those interactions.
  • My Note When a new customer encounters our project, they do so within the context of many other apps, sites, and experiences that have shaped their learned behaviours. Mapping some of these interactions helps us better understand our users.
  • tl;dr A visual representation of the customer interaction with the product.
  • Description The Customer Journey Mapping is a visual representation of how the people, when they are using the product, are feeling. This highlights times when people are happy using the product and why they are happy, and times when people are less happy and the reasons for that. These are the touchpoints that people have with the product, and they are not all in the remit of the product.

    If we take the example of a log in system someone might arrive happy, get a password wrong and become frustrated, then become anxious when they get the password wrong for a second time and are threatened with being locked out of the system, and then return to being happy after a lengthier interaction with a forgotten password system.

    The purpose of a Customer Journey Map is to help the team empathise with people using the product.

    The Customer Journey Map is based on the as is product as opposed to the proposed solution. The proposed solution is in New Customer Journey Mapping.
  • Best Version An easy to digest image of how a person’s mood is changed during interactions with the product.
  • How To Use The team will use the Customer Journey Map to design the solutions, and to prioritise the backlog.
  • Created With / By Customer Insight Manager may provide insights.
  • Created Often
  • Created By Me
  • Created With Product Owner
  • Format Visual
  • Format Presentation: PDF, Powerpoint
    • Read More
    • Less
Information Architecture
  • Defined Any current, and proposed, site maps laid out in a way which communicates what is new and or changing.
  • My Note When communicating with the team and stakeholders, a classic site map sits atop detailed information about where the project will source content and how navigation will flow between sections. Planning the architecture at this stage sparks a conversation that continues throughout the project.
  • tl;dr Any current, or proposed, site maps laid out in a way which communicates what is new and or changing.
  • Description The Information Architecture is an illustration of the content - the information - on our product and how it will be structured largely rendered from an organisational point of view in contrast to the user flows and journeys which present them same information from the point of view of the people interacting with the product. Most of the time it is true to say that the information is the same, but the focus is different. As such the Information Architecture is largely used to communicate around the business about the assets (including virtual assets) it has. It talks in terms of pages, and domains, mostly agnostic to the people using the page.

    While the Information Architecture is focused on the organisation, and created with the Business Analyst, it is not a process flow.
  • Best Version A clear depiction of the pages or content on a product.
  • How To Use Information Architecture is used by the team to standardise the view of the product, so everyone understands the scope of changes to that product in the broader context. It is also useful for the Product Owner to highlight areas in which the product may interact with other products.
  • Created With / By Created by UX with the Business Analyst.
  • Created Always
  • Created By Me
  • Created With Business Analysis
  • Format Text/Visual
  • Format Text: Team Workspace (Confluence, Jira), Word Document and/or Image: Figma, Miro, Adobe UX, Sketch
    • Read More
    • Less

Design & Illustration

Design & Illustration is about making the research and the mapping into something which can be seen and built.

  • Design Wireframes from the User Journeys.
  • Build a Prototype to show what is hard to describe in words.
  • Create Visual Designs.

The goal is to have an agreed upon set of visuals which we can build a product from.

Design & Illustration: Deliverables & Artefacts

So much of UX Design is about putting together Wirefames that sometimes that is seen as the job. Without the steps in the process which go before Wireframes will be a struggle, if those steps have been done well they will flow.

I am a particular fan of creating a Prototype to model an experience across devices. A stakeholder being able to hold a phone with the result of the UX work in their palm is a pivot point in the work.

As with Wireframes, Visual Design flows if the process has been honoured, and if there is a problem in executing visual design it is probably a sign that something has gone awry previously.

Wireframes/Mockups
  • Defined Basic Page layouts which are used to illustrate the structures for content within the Product.
  • My Note Wireframes can exist at many levels of fidelity, so it can feel odd to specify using one tool for low-fidelity work, like Balsamiq, and another for high-fidelity work, like Sketch. Ultimately, wireframes evolve in fidelity with each iteration. Creating these wireframes gives the team much of what they need to move forward and begin building the project.
  • tl;dr Basic Page layouts which are used to illustrate the structures for content within the Product.
  • Description Wireframes are often the backbone of the UX work. A set of wireframes will show the layout of the pages which make up the product and suggesting the content on those pages. This might take the form of a page with images rendered as grey boxes and text written as Lorem Ipsum copy. The aim is to illustrate the structures which will hold the content not the content itself.

    Wireframes should also show the structure of content across different implementations of the Product, for example, different screen sizes.

    A set of wireframes will have an indication of the links between pages, but functionality is illustrated in Wireflows or the Prototype.
  • Best Version A set of wireframes that show how content will be structured on different pages at different screen sizes.
  • How To Use The full team will use the Wireframes. The Business Analyst and Product Owner will use them against the requirements, the Solution Architect and developers will use them as a guide to building the Product.
  • Created With / By Created by UX.
  • Created Always
  • Created By Me
  • Format Visual
  • Format Image: Figma, Miro, Adobe UX, Sketch
    • Read More
    • Less
Wireflows
  • Defined A visual layout of the pages of a website which illustrates - but does not replicate - the functionality and/or content without necessarily being exhaustive in either.
  • My Note Illustrating static pages and how they fit together is an essential part of showing the project team and stakeholders the experience users will have. While a wireflow isn't always necessary, it's invaluable for visualising complex interactions - seeing them in action communicates their value far better than words alone.
  • tl;dr A visual layout of the pages of a website which illustrates - but does not replicate - the functionality and/or content without necessarily being exhaustive in either.
  • Description The aim of the Wireflows is to show the experience of using the Product without having to create a simulation of that experience. This is especially useful for showing more complex journeys which happen on the same screen where that screen changes content.

    The Wireflows describe functionality rather than replicating it, and so they are often clearer than other methods, but should the Product not be familiar to people they can often be a little abstract. For this reason Products often use Wireflows after they are established and as they evolve.

    Wireflows are closely related to the Prototype but has the advantage of being much easier, quicker and cheaper to create. They have the disadvantage of illustrating the experience less well.
  • Best Version A visual representation of a subset of pages which show important functionality in a way which the team can understand the proposed functionality, and the ramifications of that functionality.
  • How To Use Developers can use Wireflows to understand and estimate functionality. Product Owners and Business Analysts can use wireflows to understand functionality as it corresponds to requirements.
  • Created With / By Created by UX.
  • Created Often
  • Created By Me
  • Format Visual
  • Format Image: Figma, Miro, Adobe UX, Sketch
    • Read More
    • Less
Prototype
  • Defined A clickable working model of the website which illustrates the functionality and/or content without necessarily being exhaustive in either.
  • My Note Like a wireflow, a prototype - which I typically build in HTML and CSS - allows the project team and stakeholders to experience something much closer to the finished product than static pages can offer. The most practical use of prototypes is to demonstrate how a page adapts and reflows across different screen sizes and platforms.
  • tl;dr A clickable working model of the website which illustrates the functionality and/or content without necessarily being exhaustive in either.
  • Description The aim of a prototype is to simulate the experience the UX are aiming for without having to produce that experience. As such it behoves the prototype to be quickly made, and quick to edit, with just enough functionality to give an understanding to people using it without in essence building a second application or putting restrictions on the product caused by the prototyping tool.

    A prototype is a large commitment for a UX team and the use of it needs to justify that commitment. Typically, that justification is to explain complex functionality which cannot be communicated using Wireflows, or to test that functionality with users.

    As such a consideration in the prototype is that ability to surface the work beyond the team.
  • Best Version A web like experience that people can explore and click around to get a good approximation of what the finished product will look, feel, and read like without having to do all that work.
  • How To Use All members of the team will use the prototype, but it will be of special interest to the developers, and to the product owner and in their dealings with the stakeholders.
  • Created With / By Created by UX.
  • Created Often
  • Created By Me
  • Format Functional/Visual
  • Format Prototype: Figma, Sketch, Adobe UX
    • Read More
    • Less
Visual Designs
  • Defined The final visual look of the product.
  • My Note The visual side of web design - the “shiny” part - is always enjoyable and increasingly feels like assembling the Lego blocks of wireframes and style guides. However, it's important to pause during this process and bring all the smaller components together on a single page to ensure they work well visually and feel cohesive.
  • tl;dr The final visual look of the product
  • Description Included as a part of the Illustration group visual designs are a page by page rendering of the product across different sizes and platforms. They are, in basic terms, Web Designs.

    Visual designs should be created to a production quality and as such become the standard which define page components. If text is 16px on the visual design then, unless stated in the style guide, it should be 16px on the product. For this reason many visual designs include an information on how components should be rendered. Tools like Figma allow for that information to be presented alongside the visual designs.
  • Best Version Accurate production ready designs in Figma which can be handed off to developers.
  • How To Use The developers will use the visual designs to create components from, the Product Owner will use the visual design to communicate with stakeholders.
  • Created With / By Created by UX.
  • Created Often
  • Created By Me
  • Format Visual
  • Format Image: Figma, Miro, Adobe UX, Sketch
    • Read More
    • Less

Content Design

Content Design is about making sure that having mapped and designed about our best case scenarios, we put down some guardrails for people to use when generating that content in the future.

  • Define the tone of the content, be that content text, images or video, and what people using the product to communicate should be thinking about when they publish.
  • Create a style guide to help the team, and other publishers, when they are creating that content.

The goal is start a legacy for project that supports people who work on it after launch.

Content Design: Deliverables & Artefacts

Projects often skip over the Content Outline and Style Guide, but I believe both are essential to ensuring that the structure we’ve designed to hold content will ultimately receive the right content.

Content Outline
  • Defined An overview of what content will be on which page.  This is a document about defining the tone and purpose of the content rather than the content itself.
  • My Note Throughout my career, I've often noticed how frequently “good content” is assumed. Since my user journeys rely on specific content being delivered at key points across different pages, I believe it's essential to be involved in outlining that content. Creating a content outline at this stage often sparks a broader conversation about what content is needed, who will create it, and what standards or expectations it should meet.
  • tl;dr An overview of what content will be on which page.  This is a document about defining the tone and purpose of the content rather than the content itself.
  • Description The Content Outline often comes out of the UX process as a by product of looking at how the content with be structured in the Wireframes and having needs for what content is included and where. An illustration of this might be that the UX needs people to come to a website and see people like them, and so the Content Outline would detail the type of image needed to reflect that. It might detail the tone of view different parts of the user journey demand.

    As such the Content Outline sits between the wireframes and a brief for the content team.
  • Best Version Details on the essential imagery and text which is needed and why the Illustration Group needs to specify that content.
  • How To Use The Product Owner will use the Content Outline when briefing in a content team.
  • Created With / By Created by UX often with the Product Owner.
  • Created Rarely
  • Created By Me
  • Format Text
  • Format Text: Team Workspace (Confluence, Jira), Word Document
    • Read More
    • Less
Style Guide
  • Defined The visual elements which make up the visual designs abstracted into a document.
  • My Note Creating a strong style guide feels like signing off on a project you're proud of. These guides are often internal and can be integrated into tools like React Storybook, but bringing all the design elements together in a single document also feels like repaying a debt to future creators - giving them a clear foundation to build upon.
  • tl;dr The visual elements which make up the visual designs abstracted into a document.
  • Description The style guide gives details about the elements of a wireframe or a visual design to create a kind of definitive statement on how a visual element should be rendered when reused or recreated. A style guide will talk about the principles around a design in order to show a commonality which is present throughout the pages. This would typically include elements like which typefaces are used and in what way, what sizes for typefaces are deployed in, and why certainly elements are presented as they are.
  • Best Version A document that describes the structural thinking behind the design allowing other designers to build onto the Product.
  • How To Use The Style Guide is used by many team members including, but not exclusively, UX designs and team developers.
  • Created With / By Created by UX.
  • Created Rarely
  • Created By Me
  • Format Text
  • Format Text: Team Workspace (Confluence, Jira), Word Document
    • Read More
    • Less

Performance Review

Performance is about closing the feedback loop on our work and planning how the project will measure success.

  • Plan what we need from analytics to measure success.
  • Run Usability Testing to see what can be improved,
  • Plan any improvements Testing has suggested.

The goal is to learn from what we have done, and plan on how to make it better, assuming it is not already perfect, of course.

Performance Review: Deliverables & Artefacts

User experience depends on a continuous feedback loop. Having started the project with a defined set of goals, the Analytics Requirements specify how we will measure our success in achieving them.

If the project includes Usability Testing before launch, the resulting artefacts can provide valuable insights. The Usability Testing Recommendations that emerge from this process often help shape the product backlog for post-launch improvements.

Analytics Requirements
  • Defined An overview of what the key indicators of effectiveness in the design should be.
  • My Note Building on the project's original goals, the Analytics Requirements define what needs to be measured and how those measurements will be carried out. Creating a Requirements Artefact ensures that user experience leads the discussion on what information is needed to feed meaningful insights back into the UX process.
  • tl;dr An overview of what the key indicators of effectiveness in the design should be.
  • Description Produced by the Product Owner this is a baseline of what the business wants to discover during testing and how the design will have addressed that. This should take the form of key indicators that business is pursuing.

    On the whole this will overlap with the Usability Testing Statement to create details of what should be done in the testing process.
  • Best Version A one-page statement about what the business wants to discover in testing.
  • How To Use When aggregated with the Usability Testing Statement to create details of what should be done in the testing process.
  • Created With / By Created by the Product Owner in consultation with the UX and the Business Analyst.
  • Created Always
  • Created By Product Owner
  • Created With Business Analysis
  • Format Text
  • Format Text: Team Workspace (Confluence, Jira), Word Document
    • Read More
    • Less
Usability Testing Statement
  • Defined An overview of what testing should focus on.
  • My Note Testing covers a wide range of activities, but focusing it on specific areas - particularly the ones we've worked to improve - can reveal tough truths we might not want to hear. Still, that's far more valuable than receiving easy praise for the simple things.
  • tl;dr An overview of what testing should focus on.
  • Description This statement is an overview of what testing should focus on. Given that testing time is limited, and the design process will have generated concerns around specific areas, there is a need for the UX to underline which parts of the Product need the most focus from testing. For example should work be done on a page to move people who use the product down one route and not another then this statement would say that success should measured by conversions down that path rather than drop offs down another.

    The purpose of this User Testing Statement is to avoid the aims of the UX process - the problem being solved - being lost in the translation to the Testing.
  • Best Version A one-page statement about what should be tested, and what should be considered success in those tests.
  • How To Use The Product Owner and Business Analysis should refer back to the document when analysing results.
  • Created With / By Created with the Product Owner and the Business Analysis, and with the Test Engineer.
  • Created Often
  • Created By Me
  • Created With Product Owner, Business Analysis, Test Engineer.
  • Format Text
  • Format Text: Team Workspace (Confluence, Jira), Word Document
    • Read More
    • Less
Usability Testing Results
  • Defined The results of testing presented without recommendations. The findings.
  • My Note Creating a separate artefact for the results and their conclusions - distinct from the recommendations - helps start a conversation about what went well versus what could be improved. This separation allows the team to focus on the project's successes and learn from them.
  • tl;dr The results of testing presented without recommendations.
  • Description The details of the user testing with a focus on the raw data and the analysis of that data rather than recommendations on the basis of that data.
  • Best Version The results of user testing divorced from recommendations.
  • How To Use The UX will use the results of the user testing to make recommendations.
  • Created With / By Created by UX with input from Product Owner and Business Analyst.
  • Created Often
  • Created By Me
  • Created With Product Owner, Business Analyst.
  • Format Text/Visual
  • Format Text: Team Workspace (Confluence, Jira), Word Document and/or Presentation: PDF, Powerpoint and/or Image: Figma, Miro, Adobe UX, Sketch
    • Read More
    • Less
Usability Testing Recommendations
  • Defined Recommendations for changes to the product which emerge from the testing process.
  • My Note The recommendations that follow user testing mark the beginning of the next conversation about how to improve the project.
  • tl;dr Recommendations for changes to the product which emerge from the testing process.
  • Description This document outlines the recommendations which follow from the Usability Testing Results. Those recommendations are obviously dependent on the results and may suggest that another approach is tried, they may suggest that the tested approach be expanded, or they may just report a success.

    The Usability Testing Recommendations complete the loop of the UX process and are fed into the Product Goal Statement.
  • Best Version Details on how the continuous improvement UX aims for can be continued.
  • How To Use The Product Owner can use the recommendations as the basis for more work to be added to the backlog.
  • Created With / By Created by UX
  • Created Often
  • Created By Me
  • Format Text/Visual
  • Format Text: Team Workspace (Confluence, Jira), Word Document and/or Presentation: PDF, Powerpoint and/or Image: Figma, Miro, Adobe UX, Sketch
    • Read More
    • Less

Bigger

Stories