Before the start of the project ask yourself and the team members:
- Who will use the product/service?
- What similar products/services are already on the market
(try to use them, read use-cases, available documentation, everything you can find)?
- How do people use available products/services?
- What problems do they encounter with available solutions?
- What users needs needs are not supported already?
After you have an answer to the first question, go find those people (nearby or online) and ask them the same set of question.
Not only ask but also observe if you have a possibility:
- visit their working place,
- attend a master-class on using a competitors product together with them,
- read thematic blogs and forums,
- watch what they do,
- listen to questions they ask,
- talk to them.
During exploration phase leave your mind open to the others ideas. Note down those ideas. Ask questions. Explore.
- Personas (max. 2 per target group) or a verbal portrait of users of the product including their lifestyle, activities related to the product usage;
- Benchmark (for each design aspect) comparison of competitors products with a product or an idea of your customer including main features but also defined in a goal metrics;
- Core use cases (max. 5 per product) or main usage scenarios.
- Opportunity areas (max. 1–5 cases) usually derived from users complains and requested features.
Note: the numbers given here are enough to do effective UX. Surely you will find more but you have to shortlist them. Otherwise will be difficult to stay focused.
Ideation is an exploration of how we could make a good product or in other words how we can solve existing people’s problems for given use cases.
- Write a use case scenarios for at least 3 core use cases;
- Create 3 alternatives that address opportunity areas;
- Create visualization to illustrate improvement in core use cases in comparison to existing products.
3 design alternatives implemented in presentable prototypes (like flowchart, storyboard, video or interactive prototype)
If ideation is an exploration with no limits, concept evaluation should bring the limits back. The goal of concept evaluation is to understand either proposed ideas of how the product can be improved are useful and feasible and choose a single concept.
- Set evaluation criteria (defined in a project goal)
- Write evaluation scenarios
- Prepare prototypes
- Prepare evaluation inventory
- Get a budget confirmation
- Find a place where you invite people
- Schedule workshops and interviews
- Invite target audience representatives
- Invite technical experts
Note: You can mix a group of technical people with nontechnical to increase empathy within you project team.
I recommend to reuse defined in the goal UX metrics through all evaluation sessions and track the change over the time.
By this moment in your project you must already have some measures got from benchmark to compare to. If not, you can include one benchmark (competitors product) sample into your evaluation and set a baseline.
Here I call an evaluation inventory on a “One participant set” a set of documents you need to conduct a formal user experience interview with a participant:
- consent form a user study contract
- that can be combined with NDA,
- demographics form,
- description of tasks for a user to perform during study,
- closing questionnaires.
- Run a workshop or a series of user interviews with target audience representatives to review concepts for usefulness.
- Run a workshop with technical experts (engineers) to review the concept for feasibility. If it is possible, invite stakeholders to this session to save some time for explanation later.
As a result of concept evaluation you have to be able to:
- choose a single concept or get enough information to synthesize a new one,
- based on end-users feedback list core design principles for the product,
- based on technical review list limitations for your product.
Note: This days technology developers so quickly that ideas not feasible today can become feasible in a few month from now.
When the concept is defined, all limitations and design principles are listed, detail you concept in a design.
As it was mentioned before, there are several design dimensions:
There are always dependencies between design aspects but whenever possible, treat (develop and evaluate) each separately.
On design stage each design aspect is approached separately and a specific set of artifacts is created.
To ensure coherent process, reuse artifacts that were created in exploration phase:
- Core use cases,
- Informational architecture concept,
- Interaction design concept,
- Layout concept.
In some projects different stages can be handled by different departments or even external agencies. Whenever you have to take over or give your work for the future development to another person, prepare a design brief that includes not only a set of pictures but also describes why some decisions have been taken. It will save some time for communication and ease a start of new activity.
And whenever you prepare a design documents that you’ll use yourself or pass further here is a useful checklist of what to keep in mind.
The information architecture (or menu structure) forms the skeleton of a developed system.
- list categories of users = personas,
- analyze user tasks and list
- all use cases,
- map use cases to personas,
- write names for the menu items using users language,
- conduct card-sorting session with representative users,
- create menu structure proposal based on card-sorting results,
- evaluate (make prototype, ask users to find a specific item) and improve.
An information (or screens) flow structure that could be presented as hierarchical tree or a flow-chart.
Interaction principles could be compared to muscles of a system. And in order to create a system that moves smoothly they should be consistent.
If you are lucky and creating a user interface for an existing platform (like iOS, Android or Smart TV) with a defined human interaction guidelines, you can just follow those. If you are working on a totally new system, I would suggest to start with creation of such guidelines.
- define types of destinations or screens you will use (like home screen, dialogue, warning);
- define mane navigation mechanisms that allow user to switch between those screens (buttons, gestures, events).
When you have bones (information architecture) and muscles (interaction principles), you can assemble a body = your screens.
Activities (for each type of screen)
- define high-level screen elements
- like body, navigation bars, tool-bars,
- settings, place for advertising and cross-references,
- place screen elements consistently
- detail high level elements
At this stage of the project you have to be careful with proportions of used screen elements and with pixels.
Remember, the more screens you can detail, specify and deliver/communicate to a development team, the less surprises you will have, when those screens are implemented.