Help and Support

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.


Look and Feel

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.

Transitions and Animation

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.

Design Evaluation

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.

Expected result
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.