UX design could be a complex set of activities in several dimensions:
In different projects you can work on one or several of those dimensions simultaneously. And while performing those activities you have to consider how the created design influences users’ emotions, feeling, cognition… the product aims to invoke.
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.
In an ideal world developers would write software without bags and users will never press buttons by mistake.
Unfortunately we do not live in ideal world and therefore we have to consider a possibility for the end-users to foresee and easily recover from mistakes.
In order to provide useful support go through screens and think what what information users need and what they have to do in order to successfully complete a task.
Task analysis is especially important for rainy days scenarios for features that are used only once (like installation and setup).
- do classical task analysis enrolling down from high level steps to tinier ones,
- mark problematic points and points that require users to create or select some content,
- think where information that is needed to accomplish task can be found, is it obvious or users need to put some effort to get it,
- think of consequences if entered information is incorrect or operation fails,
- prepare tool-tips,
- consider validation,
- evaluate scenarios with technical experts either validation is possible,
- evaluate scenarios with end-users either tool-tips and validation make sense.
Especially when you work with a company that has some history, remember there is always a brand behind. Products and services that belong to a specific brand have to recognizable.
Before starting working on look and feel, explore the existing brand:
- ask your customer how strictly should you follow existing brand strategy,
- study brand books and style guides if there are,
- take a look at existing products,
- check brand history though years,
- maybe even consider the company interior.
Such exploration will help you to understand your customer and his brand policy and save some time when you start working on look and feel.
If you see that existing brand language seams to be too outdated, make two proposals: one following existing brand and a refreshed one.
In case there was no defined style guide and you’ve created one from scratch, please bother to document your creation. Here are some thoughts on creating a styleguide for a website by Anna Debenham.
When you have a functional body, you can put a skin on and probably add some make-up.
Look and feel is an important part of UX. It creates a mood for each screen. Well thought look and feel shows up the dedication of the company that created the product.
It has to be consistent in terms of style unless there is a special intention (that could happen in a game) and have enough contrast so users can see elements they should see.
As soon as you have first page with look and feel applied, show it to end users. Aesthetics could be subjective, but make sure the purpose of the basic user interface elements stays clear.