UX/UI design guidelines

What are these guidelines?

These user experience/user interface (UX/UI) guidelines establish a set of best practices and rules to design an web application for UNICEF.

These guidelines are rooted in general usability and user interface fundalmentals, however they are primarily thought to be applied in productivity and enterprise web applications, that is, those that typically display large amount of information and are full of complex forms.

Also, consider these guidelines as a live document. Although, principles rarely change, context, technology and tools do. To keep these guidelines useful, they need to evolve.

Who is expected to use these guidelines?

Anyone who has to define the user interface of a digital web application within or for UNICEF, typically a user experience designer a business product owners, but depending on the project it may also be the business analyst or the developer.

Principles

Our design principles are the roots, the core, the foundation. All our design decisions are based on the following principles.

  1. Lean design, for slow Internet connections. Because UNICEF staff is working on many countries with slow Internet connections, every design has to be fast and nimble.

  2. Design for all, no matter your tech savviness. Explicit and obvious design for all, because no matter how tech savvy you are, our apps shall be easy to use and understand. For example, we always display icons with labels, use the minimum amount of words that convey one single complete meaning, in case of doubt we prefer more words.

  3. Accessible for all, regardless of disability. Because in UNICEF every single person is important, design shall be accessible for all.

  4. Design is as little design as possible. Less, but better – because it concentrates on the essential aspects, and the apps are not burdened with non-essentials.

  5. Consistent designs. In visual style, labeling, layouts and processes. Because we don’t reinvent the wheel in every project and users don’t need to learn new conventions for every tool. But we understand we use a very diverse set of technologies. A best effort shall be approached.

  6. Made by UNICEF. Because we love UNICEF, designs present UNICEF brand core values and principles, in a subtle and humble way.

Implementing these guidelines in your design

Within UNICEF there is a wide variety of projects, some are completely new, some depend on legacy systems, some just need a few tweaks, some are just platforms with an out of the box customization, etc. With this diversity, designers will not always be able to fully comply with this specification.

Download Visual Specification

We have created a Sketch document that contains the visual specification of each component. You can use this file as library for your designs.

Download Visual Specification (.Sketch)

Download Visual Specification (.PDF)

Brand colors

In UNICEF brand book defines the following colors:

$unicef-blue
$unicef-dark-blue
$unicef-purple
$unicef-red
$unicef-dark-red
$unicef-orange
$unicef-green
$unicef-dark-green

We use $unicef-blue mainly on header.

Typically we use the $unicef-dark-blue on elements with actions.

Traffic light colors

We use the traffic light colors metaphor for indicating status or result.

  1. Success

    Green color means success: Some task was finished successfully. For example, display a notification after the user successfully saved the contents of a form.

  2. Warning

    Orange and yellow mean warning: This color warns the user that there is something that he may need to pay attention. Something exceptional, something that is important for him to know, but does not stop him to continue advancing in the flow.

  3. Danger

    Red means error or danger: This color says the user that there is something that is preventing him to continue with the regular flow. For example, user forgot to fill a mandatory field.

    Red also may indicate danger, because the user is going to perform a destructive action

    In general, because of the negative implications of the red color, we should try to avoid using it in excess.

Use of color and accessibility

Note that we never use color as the unique cue in the interface to indicate the status/result, as there may be colorblind users. We use the color to reinforce the message, but the message itself should have complete meaning without any color.

The minimum contrast ratio between the foreground and background shall be compliant with WCAG 2 level AA. It requires a contrast ratio of at least:

Large text is defined as 14 point (typically 18.66px) and bold or larger, or 18 point (typically 24px) or larger.

You can use the following tools get the contrast ratio:

Typography

For keeping the weight of the HTML low, we haven’t defined a default typography other than the default font of the operating system the user is running. For example, in Windows 10 is Segoe.

References

Headings

Headings h1 to h6.

  1. Follow a hierarchy. For example, under h4, there cannot be a h3.
  2. Although, it is typical to use the brand color on headers, we use a black color because UNICEF blue may be confused with a link. We are using UNICEF blue for links.
  3. Do not jump hierarchies. After h1 there should be h2, but not h3 or h4. This is important for text readers, as users can navigate through headings.
  4. Only one h1 per page. It shall be the title of the page.
  5. Make your heading content: short, specific and clear.

Text and labeling

Labels are the texts that appear on the interface next to form fields or within buttons.

Define a good labeling is one of the most difficult tasks when designing a good user interface and it should be conscientiously thought.

The following rules are recommended.

  1. Labels shall be univocal, that is, they must convey one single meaning to all users.

  2. Labels shall be short, the sorter, the better. For example, between the labels “Do you need help?”, or a simply “Help”, we would chose the latter. It conveys exactly the same meaning but in less words. The same with the following examples:

    Worse Better
    Go to next step Continue
    Where to find more information More information
    Join our team Jobs

  3. Labels shall be as precise as possible. For example, the submit button in a form to request a vacation, instead of generic “Submit”, a “Request vacation” would be preferred. Although, a bit longer, it helps the user to understand better what is the action he is performing.

  4. Labels shall be consistent across the whole interface. For example, if “Delete” is used in one page, it should be used in all pages, avoiding the use of “Remove” or “Eliminate”.

  5. Labels should have sentence case. For example, use “Request vacation” and do not use “Request ~~V~~acation” (capital V in vacation).

  6. We do not use two dots after labels. Example:

  7. In general, we prefer avoid acronyms in labels. Use an application is generally harder for people that are new, if we add the of acronyms, we worsen the situation. If an acronym is widely used, add the expanded version in parenthesis. For example:

    Don't

    Do

  8. Buttons perform actions, therefore, labels contained in buttons should include a verb. For example a button with the label Edit is ok, but Edition is wrong.

    These are the standard labels any interface should use:

    Label Action Do not use
    Add Create a new item Create, Build, New
    Cancel Abandon current action Dismiss, Abandon
    Continue Go to next step Next, Following
    Delete Delete an existing item Remove, Eliminate, Suprime
    Edit Modify an existing item Modify, Change
    Save Save into a system an item Submit, Commit
    Upload Load a file from local computer or other system Import
    Download Save to a local computer Export
    Print Print current page or section Export
Sustainability guideline:, in order to minimize paper usage, whenever possible define a download action instead of a print action.

Documentation and contents

When creating contents for the web follow these rules to improve the readability:

  1. Use short paragraphs (no more than 3 to 5 lines) and start with the conclusion or most important piece of information.

  2. Use bullet or numbered lists whenever possible. Instead of a listing items in a coma separated list use bullet points.

  3. Never use the text click here for a link. Instead, the text should inform the user what is behind the link. Example:

    Don't

    In order to remove this folder click here</p>

    To read more about how to write for the web. Follow this link link

    Do

    Remove folder

    Read more about how to write for the web

    </div>

  4. Highlight in bold key words or phrases of paragraphs.

  5. Do not use underline. In the web underline is reserved to links.

  6. Use headlines and titles to structure the content.

The main reason to apply these rules is because people don’t read on the web, they scan.

You can use these guidelines in any content produced to be consumed on a screen:

References

Alerts

  1. Sometimes you need to recall user attention. Use alerts for that.

  2. Alerts shall be used ONLY to display information that is extremely important for the user to to be aware of.

  3. Alerts are designed to stand out in the interface, don’t overuse them. If everything stands out, nothing stands out.

  4. Regular information text shall not be displayed within an alert.

  5. We have the following classes of alerts. They follow the Traffic light principle.

Alerts can be dismissible. Use them when user needs to interact with the current page, and once read, they no longer have relevance. For example, after successfully updating an item.

Icons

In general, icons shall always be accompanied with a label. Exceptionally, a tooltip is allowed.

A recommended icon set is FontAwesome 5.x free.

In order to keep consistency on the meaning of most common actions, the icon shall be

Icon Action Icon description
Edit A pencil
Close An X
Delete An trash can
Print A printer
Upload An arrow exiting from a hard disk
Download An arrow going to a hard disk.
Search A magnifier

The following icons are not recommended to be used

Save A floppy disks are something from the past

Date format

In UNICEF Style Guidelines (internal document) the recommended format is 3 February 2019. We also recommend this format if space is necessary dd-MMM-YYYY. For instance: 01-Feb-2018 or 10-Mar-2020.

Never use the format dd/mm/yyyy or mm/dd/yyyy as it is confusing. For instance, 02/01/2020, depending on the country it can be interpreted either as 01-Feb-2020 or 02-Jan-2020`.

This recommendation may seem not important, but imagine that 03/08/2019 is the due date of a contract or the date a payment must be done. It can be catastrophic! We are in a heterogeneous organization that works with people from many nationalities. You should use this format in your emails, documents, spread sheets, presentations and, of course, user interfaces.

Time formats

Time shall be displayed in current user timezone and in 12-hour format. Example: Add the title attribute with the 24-hour time.

10:30 PM

We selected this format because most English-speaking countries use the 12-hour clock as the dominant written and spoken system of time. Other countries use the 12-hour clock in spoken time and 24-hour clock in written notation. But most people in 24-hour countries are so used to both systems that they have no problem switching between the two.

Relative timestamps

Alternatively you can display a date with a relative reference of current time. For example, 5 minutes ago.

Full text Example Full Shortened text Example Short
in N years in 3 years in Ny in 3y
in N months in 2 months in Nmo in 1mo
in N days in 2 days in Nd in 3d
in N hour in 2 hours in Nh in 1h
in N minutes in 3 minutes in Nm in 3m
in N seconds in 3 seconds in Ns in 2s
N seconds ago 1 seconds ago Ns ago 3s ago
N minutes ago 3 minutes ago Nm ago 3m ago
N hours ago 5 hours ago Nh ago 3h ago
N days ago 6 days ago Nd ago 3d ago
N months ago 7 months ago Nmo ago 3mo ago
N years ago 8 years ago Ny ago 3y ago

Whenever you use this date format, add the title attribute with the full date. Example:

3 years ago

Numbers and currencies format

By default, we stick to English numbers. Separate thousands, millions, etc. with , and decimals with .. Example: 3.14159, 1,200,000. For currencies prepend the currency symbol to the number and use always two decimals. Example: $123,456,789.00, €1,200.00.

You can skip decimals if they are not relevant ($1,200), but if you include them, always use two ($1,200.3).

Note: Applications with internationalization support may override this recommendation.

For example, in Spanish/Spain is more common to write one million euros as 1.000.000,00€ (using dot separator for miles and comma for decimals).

References

Images

Images should weight the least amount possible. We work on environments on which the Internet is still not reliable. So, minimizing the use and size of images is a must.

  1. Use the format that weights for the size and quality you require. Typically, it is recommended to use JPG format for pictures and SVG for graphics and icons.

  2. Use size optimizers such as svgo or jpeg optim.

  3. It is necessary to set the alt description on all images. Keep this description brief, describe what you see and do not interpret the contents of the image. For decorative images, use an empty string alt attribute (alt="").

Forms

Forms shall be designed the following way:

  1. Fields shall be ordered from more important to less important, leaving optional fields at the end.

  2. Related fields must be close to each other. For example, when residential address, zip code and country are requested, these must be close to each other as they are related.

  3. Form fields shall be ordered in a logic way and/or following most common conventions. For example, in a login page, the username is requested before the password.

  4. The size of the fields should reflect the expected size of its contents.

    Don't

    Do

  5. Form elements always have a label.

    Don't

    Do

    There may be a few exceptions in which a form element does not need a label. For example, a search box:

  6. Numerical input fields shall be aligned to the right (to ease reading)

  7. Currency fields:
    1. Shall not allow the user to introduce more than 2 decimals.
    2. Shall not allow the user to introduce any character not permitted.
  8. Read only fields are those that just displays information user can never change (html attribute readonly). A field that the user cannot modify because of the current status of the form are disabled. Example:

You need admin permissions to edit the birthday. Please, request access to the admin.

In the example above, the birthday field is disabled because user does not have permissions. However, Older than 18? field is read only, because it only displays information.

Forms Layout

There are two ways of arranging fields in a form. The first one is in a linear way, with one field per line, that is, by displaying one field above the next one. The second way to arrange a form is the productivity tool form. In these kinds of forms the layout groups elements to maximize the number of fields visible in the screen.

Linear forms vs productivity forms

Linear forms are recommended for tasks sporadically done, tasks generally performed by users new to the system or while creating a new item. This layout it helps the user to sequentially fill the form.

However, for repetitive tasks expected to be done by users recurrently in productivity tools, it is recommended to follow the second approach, that is, try to display more elements in the screen. It allows users to analyze and edit more information without scrolling. These layouts are particularly useful for applications in which changes of value in interactive elements change values in results areas.

Horizontal forms are not recommended. These forms place the labels are on the left of the field. Because of the distance between the label and the field are harder to fill for the user, also, these may have more problems with responsive design..

Don't

References

Form validations

Client side validation of form fields shall be done at field level:

  1. After losing focus if the field does not have an error when the field gets the focus. We avoid displaying the error before the user has finished and believes it is correct. Imaging filling you email account into a field that once you type the first letter tells you that it is not correct, you may think: Hey man! Let me finish first!

  2. On every change (ie: key up) if the field has an error when the field gets the focus. This approach informs the user the value is valid as soon as the error is solved.

Error messages are displayed contextualized under the field that is causing that error. These messages shall include:

  1. What went wrong and possibly why.
  2. What is the next step the user should take to fix the error.

And they should avoid using technical jargon and be as short and concise as possible. In case, we don’t have space, we should try to focus on how to fix the error.

Buttons

We have the following types of buttons:

Primary buttons allow the user to continue with the regular flow, typically has the save, continue, send actions. It is the most visually prominent on the interface.

Default buttons are those that allow the user to perform secondary actions such as cancel go to previous step.

Danger buttons are exclusively reserved for destructive actions (such as delete an item). They require to display an undo notification (preferred) or to display a confirmation popup before performing the action.

In a form buttons are aligned to the left. Except in popups that are aligned to the right.

The order of the buttons should be from left tor right: from least important action to primary/main action.

Avoid disabled buttons

In general, avoid using disabled buttons. In particular, never use them inform to indicate that there are some fields missing.

Don't

If in a particular situation you need to display a disabled button, always add a short explanation text next to it.

References

In general, the use of popups shall be rationalized as they are not friendly on mobile and tablet devices.

In case of using them, these shall not include flows within them. Popups shall be used either to display some additional information or to fill a short subform.

Popups shall not be used to notify users about errors while filling a form or system errors. Use notifications, alerts and field errors for this purpose.

Tables

Tables fields should be organized following this pattern from left to right:

  1. Id (only displayed if necessary).
  2. Most important information in the row.
  3. Least important information in the row.
  4. Action links.
  5. Alignment
  6. In general, columns are aligned to the left except last column that should be aligned to the right.
  7. Numberical columns and dates shall be always aligned to the right (to ease reading).

In case selection of individual rows is provided, it should be displayed at the left side.

Loading - Asynchronous communication

Whenever the system is performing an action in background the user interface shall provide visual feedback to indicate the user this status.

In general, a message indicating the action being performed shall be provided

Loading user profile...

If the action is performed after using a button, the feedback can should be contextualized within the button.

Progress bars

Progress bars to visually indicate the current status of a process.

Budget

Allocated funds: $87,500 (75%)

$0.00 $125,000.00

Values under the bar can be skipped if user only needs to have a rough understanding of the status.

Completed tasks