This document gathers UX deliverables I find useful and meaningful to keep investing on while working on different projects. The foundation for the UX work is on the concept called Contextual Use Scenarios. The document is structured as a guide to manage UX project of any size, development phase or team setup. It is also a description of my personal "process".
User Stories:
Use Cases:
Contextual Use Scenarios:
Summary:
The thinking foes: for comprehensive understanding, use contextual use scenarios to grasp user needs and context, and use cases like descriptions to understand how the system should behave to meet those needs.
The key to make personas useful is to keep them simple. Don't overthink the purpose. The main reason is to capture the essential actors that the solution affects.
For each person, add:
Contextual use scenarios are effective way to define
in relation to the system, users and the surrounding context.
IDENTIFY the VALUE that can be generated by interacting with the system.
Simply put, they aim to answer:
There are no strict rules how to divide scenarios. Scenarios might overlap. For instance, in imaginary system, if a user updates certain information she might also delete other. This sequence could be a part of some higher order workflow. One good way to capture relevant scenarios is to analyze potential or actual activities top-down and stop as soon as the boundaries of an activity starts to emerge. Too big is hard to discuss and process. Too small and activities seems fragmented and big picture is lost.
Aim for 5-20 use scenarios.
For each scenario, add:
Use Contextual Use Scenarios to identify key entities that are the building blocks of this system.
Typical examples: user, customer, product, order, invoice, etc. Remember, this is not technical object-oriented modeling that reflects what is stored in the database. An entity could be something like “warehouse” that is a user-driven abstraction without any permanent storage on technical side. Aligning user-models to database-models is useful, but they are not always to the same. Don't try to force it if it doesn't fit.
After the main entities and functionalities are laid out group them as separate sub-section by higher-level entity. Describe how the functionality works, add screenshots of visual designs and all other relevant material. Aim for minimum viable solution description.
In order to gather all relevant design deliverables together, consider to add or link to the following:
Once the functionalities are split they should be shaped into workable chunks for further clarification and eventually development. Grouping content on each state by the structure initiated by the Contextual Use Scenarios the whole project remains coherent and logical to follow. This chunking also helps to make time-related estimates and budgeting.
Usually it makes sense to map these blocks to development activities. For example, if Contextual Use Scenario is split into functionalities or features, these features typically becomes tickets or other work-tracking-related entities.
Finally, in order to tie all design and development activities together it makes sense to focus on testing.
Let's borrow the "Given-When-Then" format from BDD to help to describe the behavior of the system in a structured way:
Given: Describes the initial context or state before the behavior occurs. When: Describes the event or action that triggers the behavior. Then: Describes the expected outcome or result of the behavior.
Consider the following test writte in in Gherkin syntax:
Feature: User login
# This scenario covers a successful login
Scenario: Successful login
Given the user is on the login page
When the user enters valid credentials
Then the user is redirected to the dashboard
The format ensures clarity and facilitates collaboration among designers, developers, testers, and business stakeholders.
Tests can be described together with the solution, or they can be co-located elsewhere together with other development tasks, whatever the current work tracking convention is. Notice how effortlessly Contextual Use Scenarios tie the solution together from end-to-end. To goal is to ensure that everybody on the team stays aware of what are we doing, for who and why it matters for them.
By using Contextual Use Scenarios as a basis for structuring design it is possible to align and glue development activities together to support common goal, which is (or should be) to build usable solutions to real problems. Contextual Use Scenarios is not a development paradigm, rather it is a modelling technique and deliverable format.
The approach can be adapted in almost any kind of development setting. The only thing really needed is to generate Contextual Use Scenarios, Personas and model the main entities. The best part is that generating the definitions is always worth it for the designer, even if rest of the development pipeline is following other methodologies and conventions.
The approach aims to focus on the essential aspects of development by producing only relevant artefacts. By minimising unncessary work the final deliverables are made cost-effectively. The results are very likely to be intuitive and financial risks of the project are kept in control. Even in unfortunate cases where the project misses the mark it is unlikely to produce deliverable waste. This is because the idea is to generate only content that is useful in the context.
Question: how can I define the functionalities?
Answer: Functionalities are derived from contextual use scenarios. E.g. pick a scenario and start by transforming the contents to actual needs. For example, if a scenario states “Walter checks the last night work progress”, it could be that the workflow would start by understanding what is the current status of items that has been produced during the night. This could be handled via functionality called “show warehouse inventory”. Notice there are no mentions of anything related to UI yet. No assumptions nor any premature design statements have been made. This is intentional. Things should be described easy enough to work on purely abstract level. From UI design perspective the wire-framing can start with confidence of knowing who does what and why. Once the UI deliverables emerge (preferably low fidelity) they can be attached next to the functionality description.
Question: what about functionalities that don’t depend on user? E.g. system to system interactions? Answer: add them as functionalities of the entity.
Question: when is the right time to make some UI drafts? Answer: there is no exact right time to do it, but once you understand the scenario, or few of them, and you have a hypothesis of how it could be solved, then it's more natural to move towards UI drafts.