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.
This days basically every platform allows designers to enhance user interface with a help of animation. Make it more playful and sexy.
Remember, animation has to be meaningful like sliding screen to the left if you go forward on iPhone and should not take too much time so it constrains users from performing their tasks.
Also different groups of applications require different animation. You can go nuts when creating games but in a business context try to avoid long and fancy transitions. Use common sense.
As soon as your design is complete, it is useful to assemble a prototype and to evaluate it.
Why? It will most probably take several month for developers to implement it but you can find and fix some problems. When design is implemented in prototype, give it target users to use.
- Consider another sample so users have something to compare the prototype with;
- Define evaluation metrics to see how much the proposal is different from the reference;
- Define acceptance criteria;
- Choose participants according to personas;
- Choose user tasks from the core use-cases;
- Document discovered problems.
Design release and a start of the next step in the project (development) or if needed recommendations for improvement and one more design iteration.
While developers go on with implementation, consider several evaluation sessions along the way. Compare measured metrics. Make sure the design/product is still usable after implementation.
When you start the project, you have to talk to project members in order to get essential information to create a good design.
If you have to give results of your work to someone to proceed, make sure you brief properly: not only share screens and reports but explaining the reasoning behind your design solutions.
Do your best to stay informed on implementation progress and be present when developers decide what to scarify in order to deliver the product on time.
Also just be a nice person and a good team player. Smile, feed developers with candy. It makes communication easier.