Briefcase

# Designing your app

Image showing simplified view of lots of different app layouts

Most pages follow a common layout structure, placing controls in similar areas.

For desktop experiences you'll usually have more screen width than height, and for mobile experiences the opposite is true.

# Structure & Navigation

The structure of your app defines the relationship between pages, with the navigation helping a user to move between those pages. Apps that live within an existing structure like the Partner Portal will pickup context from that structure, and you should consider this when you start to design your app.

# Information architecture

Before you start building or designing your app, it can help to think about its information architecture (IA). This is the location of information within the product as well as the relationship of one page to another.

The information architecture helps your user to understand where they are in your app, and how they can navigate to the content they need. For simpler tools this may be a single screen, but it's important to consider what tasks a user wants to accomplish and how you'll structure the information they need.

Defining your IA can be as simple as drawing it out on paper. Keeping it as a reference will help you if you need to add additional pages later on.

# Mental models

The architecture you define contributes to a person's mental model of your app; the assumptions people carry in their minds before interacting with a website or application. Information is easier to discover when it is in a place that matches the user’s mental model of where it should be.

In some cases you may already know what information you want to include, but don't know the best way to order or describe it. Early stage research methods like Card Sorting (link to more info) or using Paper Prototypes (link to more info) can help you work with your target audience to understand their mental models, and incorporate that into your decisions.

While there's no single navigation design that works for every app, there are principles and guidelines to help you decide the right design for your app.

# Basic principles of navigation

Let's start with the basic principles of good navigation design:

  • Consistency: Meet user expectations.
  • Simplicity: Don't do more than you need to.
  • Clarity: Provide clear paths and options.

# Consistency

Navigation should be consistent with user expectations. Using standard controls that users are familiar with and following standard conventions for icons, location, and styling will make navigation predictable and intuitive for users.

# Simplicity

Fewer navigation items simplify decision making for users. Providing easy access to important destinations and hiding less important items will help users get where they want, faster.

# Clarity

Clear paths allow for logical navigation for users. Making navigation options obvious and clarifying relationships between pages should prevent users from getting lost.

# General recommendations

Now, let's take our design principles--consistency, simplicity, and clarity--and use them to come up with some general recommendations.

Think about your users. Trace out typical paths they might take through your app, and for each page, think about why the user is there and where they might want to go.

Avoid deep navigation hierarchies. If you go beyond three levels of navigation, you risk stranding your user in a deep hierarchy that they will have difficulty leaving.

Avoid "pogo-sticking." Pogo-sticking occurs when there is related content, but navigating to it requires the user to go up a level and then down again.

# App structures

# Flat/ Lateral

In a flat/lateral structure, pages exist side-by-side. You can go from one page to another in any order.

  • The pages can be viewed in any order.
  • The pages are clearly distinct from each other and don't have an obvious parent/child relationship.
  • There are less than 8 pages in the group. (When there are more pages, it might be difficult for users to understand how the pages are unique or to understand their current location within the group. If you don't think that's an issue for your app, go ahead and make the pages peers. Otherwise, consider using a hierarchical structure to break the pages into two or more smaller groups.)

# Hierarchal

In a hierarchical structure, pages are organized into a tree-like structure. Each child page has one parent, but a parent can have one or more child pages. To reach a child page, you travel through the parent.

Hierarchical structures are good for organizing complex content that spans lots of pages. The downside is some navigation overhead: the deeper the structure, the more clicks it takes to get from page to page.

We recommend a hierarchical structure when:

  • Pages should be traversed in a specific order.
  • There is a clear parent-child relationship between pages.
  • There are more than 7 pages in the group.

# Hybrid

You don't have to choose one structure or the other; many well-design apps use both. An app can use flat structures for top-level pages that can be viewed in any order, and hierarchical structures for pages that have more complex relationships.

If your navigation structure has multiple levels, we recommend that peer-to-peer navigation elements only link to the peers within their current subtree.

Once you've decided on a page structure, you need to decide how users navigate through those pages.

Whilst the following isn't a complete list of navigation patterns, it offers a starting point for most use cases.

The Skyscanner Partner Portal scaffolding automatically adds new pages into a left panel navigation, and includes some specific patterns for how your app should use this navigation.

Try to avoid using a Left Panel navigation if your app is in the Portal, as this will confuse users.

# Left-panel navigation

Image showing simplified view of the left panel navigation on large and small viewports

This displays a list of top-level pages in an indepedently scrollable side-panel.

On narrower screen widths you can hide this panel and reveal it with a menu button, which is usually contained within the header for the app.

# Use this when:
  • You have distinct sections to your app with their own navigation trees (eg. a hierarchal model)
  • You want to be able to group pages by section
  • There are a lot of pages in your app (more than 5)
  • You want to allow a user to see several navigation options on screen

# Top navigation

Image showing simplified view of the top navigation on large and small viewports

A horizontal list of top-level pages, located above your content.

On narrower screen widths you can allow users to scroll the navigation horizontally, or replace it with a left-panel navigation hidden behind a menu button.

# Use this when:
  • You want to have more screen width for your content
  • Your app has a smaller number of top-level pages (fewer than 5)
  • You want to allow a user to see all their navigation options on screen

# Horizontal tabs

Image showing simplified view of horizontal tabs on large and small viewports

This pattern is similar to a top navigation, but is used for moving between content on a page.

When a user selects a tab, the content affected should refresh whilst the rest of the app frame remains.

# Use this when:
  • You want a user to move between similar content types (for example changing the graph used to display a dataset)
  • Your new content does not include any further navigation
  • You want to display your content across the full-width of the page

# Vertical tabs

Image showing simplified view of vertical tabs on large and small viewports

This pattern is similar to a left-panel navigation, but is used for moving between content on a page.

When a user selects a tab, the content affected should refresh whilst the rest of the app frame remains.

Vertical tabs can be positioned at the top of the content area, or remain sticky as the user scrolls.

# Use this when:
  • You want a user to move between similar content types (for example selecting a page in a form)
  • You have sections of content which take up a lot of page height
  • You want a user to be able to change content type as they scroll

# Combinations

Each of these patterns can be combined, especially if you're building a larger app.

Make sure that you maintain consistency between similar pages so that your users aren't confused.

Other elements Loading People using your app will have a range of device and connection capabilities, which will affect the speed and performance of your app.

By providing loading states you'll help your users understand when the app is processing data so they don't think it's frozen or broken.

Application loading Image showing a skeleton loading state

Try to show content to the user as soon as possible. Skeleton screens are a way of displaying placeholder content whilst your content is downloaded.

New content shouldn't affect the layout of the page as it loads. Ensure that content blocks like images or graphs have explicit height and width set on them so that they don't change the layout of the page once they're loaded in.

Immediate feedback You should always provide feedback to the user after an interaction, even if the content required hasn't loaded. Ensure that interactive elements have hover and active states set, and that you disable interactive elements whilst their associated task is completing.

Loading indicators The type of loading indicator you use should be appropriate to the situation. For short periods or when you're unsure of the duration of a loading task, use an indeterminate loading element like a spinner or descriptive text.

For longer tasks, or where it's important to provide clear feedback about the duration of loading, a bar or progress screen is appropriate. This is especially important if you need the user to remain on this screen whilst the application is loading.

For file uploads or downloads make sure you have error states to inform the user if something goes wrong. Consider preparing downloads in the background and alerting the user with a toast or snackbar message when their data is ready.

Modality Modal screens creates a mode that disables the main window, but keeps it visible with the modal window as a child window in front of it. Users must interact with the modal window before they can return to the parent application.

Examples of modal elements include dialogs and popup windows. Comment mode on a document can also be considered a form of modality as the user has switched the way they are interacting with the document which limits certain features until they have switched back to the main mode.

You should use modal screens only for temporary tasks where it's important to focus a user's attention.

You can use scrims and overlays to dim or hide the background application so that they're aware they need to interact with the modal in order to proceed.

Minimise the use of modality in your application. Avoid taking the user out of their flow. Make sure the user understands what the modal view is affecting. Provide clear text information. Provide a clear way to close or exit the modal. For modals that require explicit user input use clear, unambiguous labels on buttons. Display modals over popovers or other modal content. If you must do this, for example where a modal has loaded due to input in a popover, close the popover first. New windows Your navigation links should always open in the same window so that your user doesn't lose track of where they are.

If you're opening content that takes the user away from the app, for example an external link, this should open in a new window.

Help and onboarding Through the lifecycle of your product you'll have opportunities to support your users to achieve their goals. Understanding their abilities and needs means you can offer a tailored experience from first load onwards.

Onboarding and onwards help serve two different purposes.

Onboarding Onboarding supports first-time users, or lapsed users returning after a substantial change to the app. You should keep onboarding screens as specific as possible; if your app requires user input to setup or consent then place it here.

If you're serving different user groups in your app, you can use your onboarding screens to provide a signpost about where they should begin.

Help Clear documentation provides support for users who may be unsure of how to accomplish a task.

Your help content should always be relevant and up-to-date. Avoid linking to a generic help site, especially if you provide a help link in your top navigation. Try to offer a direct link to content about the page the user is on.

Above all your product should be intuitive and easy to use. Help content is not a crutch for bad design, and exists to provide confidence to users and direct them to features they may not be aware of.

Errors Alerting

# Page layout

# App headers

Image showing a simplified page and the location of an app header

The app header is a common header that exists between all pages in your app. If you're using a top navigation, this will usually live in the app header.

Shared controls like a help menu, application settings, or a button to invoke the navigation (if hidden) should also be placed here.

Keep your app header compact so it doesn't reduce the space available to your content. Only include common actions for your whole application here. Make the app header fixed in place as the user scrolls. Place content specific to only a few pages here.

# App headers on the Partner Portal

If you're building an application for use on the Partner Portal you'll already have a app header.

Your app settings should live within the settings on the Portal, and you'll need to make sure you respect any user settings like currency, timezone, or language.

# Page headers

Image showing a simplified page and the location of a page header

The page header sits at the top of your content and should contain the name of the page or section that a user is on.

Any global page controls will go here like back buttons or pagination.

Do Don't
• Give your page a clear title so people understand where they are in your app • Use more than one page header
• Provide relevant global controls so people don't have to scroll • Place too many controls or buttons inside the page header

# Sub-section headers

Image showing different examples of a simplified page and the locations of a sub-section header

Use these to break-up different areas of content, especially if your page is quite long.

A sub-section header can be used as a title for a graph, in which case you can place any relevant controls here as well as the key for your graph.

Dd Dd

# Databars

Image showing different examples of a simplified page and an interactive and non-interactive databar

A way of presenting headline information, for example key stats from the information on page.

They come in two types: interactive, and non-interactive. Interactive databars behave like horizontal tabs and switch the content below them.

Dd Dd

# Filters

Filters allow a user to provide criteria by which a dataset can be narrowed down or sorted.

Allowing your user to manipulate and filter data is a core aspect of a data product, this is especially important if your dataset is large.

You may wish to allow a user a fine or coarse level of filtering which can affect the pattern which you'll use to display your filters.

When placing filters in your UI, you should always place them in close proximity to the content they affect.

You should always provide a clear indication to the user that they have filters applied.

# Inline filters

Image showing a simplified example of a filter panel, both inline and hidden behind a button

Inline filters can be placed beside other page elements. You can keep them hidden and expose them behind an accordion or dropdown element.

Use these when your filters only affect adjacent content Use an inline filter when you have fewer than 4 filter options Apply inline filters to unrelated content elsewhere on the page

# Filter bars

Image showing a simplified example of a filter bar with open and closed sections

For more complex filters or those that affect the entire page you should use a filter bar.

Filter bars use the entire width of the content space and contain filter blocks. The filter bar can be scrolled horizontally to reveal filter blocks that don't fit on screen.

Filter blocks are clickable buttons within the filter bar that produce a dropdown. Your filter content should be placed within that dropdown.

You can choose to apply filters automatically or use a button to update changed filters.

Use this when you have more than 4 filters Your filters apply to the whole page content Combine multiple filters behind one block

← Element Guidelines →