7.1 Features and Structure

As established above, providing straightforward navigation is invaluable for a design system. In addition to fitting content and nomenclature, position and user interaction play an important role in making navigation usable. How to employ these effectively within a system largely depends on the specific context of use. Initially, I considered using a horizontal navigation bar at the top of the page, since it would allow the actual content to utilize more space. This is a common pattern used by many websites and would have worked well with a step-by-step, multi level information architecture as suggested by the user interface map. With the revised, low hierarchy information architecture however, the greater number of top-level categories could by no means fit in one line anymore. Instead I switched to an always visible, vertical navigation on the left side of the content. This navigation pattern is used by various other styleguides and has the benefits of being a lot more flexible regarding its content. This type of navigation works reliably irrespective of the number of categories or the length of their title, making it a solid choice for a styleguide that is continually being changed and extended. The side-navigation concept I proposed on the basis of the now final information architecture was universally well received by the test participants.

Main Menu Sketch

With the general navigation layout in place, I went on to consider requirements regarding user interaction. Through my extensive research and discussions with test participants, it became apparent that user behavior for styleguides differed from most other websites in several ways:

  • Compared to other sites serving static information, users visit a styleguide often and repeatedly, even frequently accessing the same content.
  • Compared to other frequently visited sites, such as facebook or twitter, consolidating hub pages don’t offer much value for styleguides since they don’t continuously generate new content.
  • In contrast to most goal oriented sites that tend to lead users down a certain path, styleguide users frequently navigate back and forth between content from different categories.

Subsequently, navigation of a styleguide should function in a way that is supporting this special user behavior. In order to determine the most appropriate interaction pattern, I had the participants of the user test perform simple navigational tasks on two different live styleguides and subsequently rate their experience by felt efficiency and satisfaction. Similar to a within-subjects design, all five participants tested both models, switching the order for every participant. The simple test assignment was to navigate back and forth across categories to specific pages of a styleguide. Both sites tested have a simple two-level navigation on the left side of the page, similar to my proposition. The two tested variants were:

  1. Apple iOS Human Interface Guidelines: Selecting a top-level category triggers a page reload and navigates to the first subsection of the selected category.
  2. Google Material Design Guidelines: Selecting a top-level category expands the navigation and reveals the corresponding subsections. No page reload or navigation gets triggered.

Independent of which variant was presented first, four out of five participants preferred the model as implemented by Google’s Material Design. It offers much greater speed when switching between various types of content and invites for more exploration of the categories, since selecting one doesn’t instantly trigger a page reload. The presented implementation enabled the participants to explore the site more deliberately. In contrast, the interaction model as implemented by Apple was quickly seen as annoying, since it took roughly twice as long to reach a desired destination within the system.

Building on the test results I decided to go with a matching interaction model. Hence, top-level categories only act as organizing containers within the system but don’t actually carry content themselves. In order to cope for the now missing category page to offer an introduction on the category’s content, I added explanatory overview pages as the first subsection where it made sense. Taking Elements as an example, offering an illustrated gridview on the category’s content assists users in finding the UI element they need even if they can’t make sense of the names alone.

Sketch of the Elements Overview Page

Content Page Structure

For a styleguide, it is key to enable users to find the right piece of information quickly. Thus having a logically built, repeating content structure is important to simplify the system and reduce cognitive load on the user (Whitenton, 2013b). It reduces the need to reorient anew for every article and quickly becomes internalized. To figure out a structure that supports our user’s tasks and fits their pre established mental models of the inner factors that constitute the various contents of a user interface, I discussed and tested various structures and arrangements for the pages with the user test participants. Lastly, I arrived at a basic structure that can easily be adapted for the majority of page contents:

Content Page Sketches
  • Introduction: Describe the main purpose and content of the article briefly, in one to three sentences. In case of a usable element, describe its main function within the system.
  • Contents: A clickable table of contents on the article. Gives an overview on the presented information and allows for quick navigation to the segment that is relevant to the user.
  • Types: Show and describe the various types of the same basic element or content that can be used for different purposes. As an example, a button may have two types, a subtle one and one with high contrast, depending on the amount of attention it is meant to attract.
  • Variants (optional): Some elements and other guidelines offer variants to choose from according to the requirements of a situation. A button, as an example, comes in a black-and-white variant for neutral links as well as a green one used as a call to action.
  • Code: After covering all the possibilities of using an element, the code section explains how to combine tags and classes in order to produce just the type and variant that is needed. I also tested variations of the structure that included multiple smaller code sections throughout an article, every time a new type or variant gets introduced. However, this wasn’t well received by test participants as it distracted users from fully comprehending an element and its usage first. Gathering all code in a dedicated section instead has the added benefit of making it easier for front-end developers to recognize all of an element’s relationships and dependencies.
  • Specs: Lastly, the final section is mainly intended for designers and describes the exact visual and behavioral specifications that went into designing an element. Most of the time this will not be needed as designers will resort to using the UI kit found within the resources section when designing pages. It does, however, become invaluable once a designer has to create a new element as an addition to the styleguide. By knowing why specific decisions were made for a similar element, it becomes a lot easier to come up with a solution that fits the overall design language precisely.


While a navigational menu works great for users who know what content they are looking for, it becomes less helpful for those who don’t. Given you come across a problem when building a user interface and you are not well acquainted with the design system, it can be difficult to find just the section you need. In an effort to better facilitate content exploration for these users I envisioned a feature enabling what I called a conversational search experience.

Conversational Interface Sketch

The feature was intended to be positioned above all other content on top of the system’s home page, as well as be universally accessible on every page by selecting a search action in the page header. By default, it would lead with an inviting question asking “What are you looking for today?” followed by the beginning of a sentence, reading “I want to [ __ | design | program | write | get help deciding ]”. The possible actions a user might want to perform are offered in an already expanded dropdown selection, inviting the user to continue the sentence. Selecting one of the options will then reveal more of the sentence, followed by another dropdown selection for further refinement of what the user intents to do. The options that are offered next always depend on the user’s previous selection, allowing for a great number of possibilities. Repeating this process should eventually create a sentence precisely outlining the user’s problem. Narrowing a problem down to a complete sentence would then reveal only few highly relevant pages. Simultaneously during input, a direct search is triggered using the already available information, instantly showing matching articles in a window below.

However, testing out the concept with users revealed substantial problems about it. The way I envisioned people to describe their intentions actually was not well understood by the participants. In fact, upon discussion it appeared each of the participants had a fundamentally different way of voicing their problem in one sentence. In addition to the usability problems, though, it would have been rather complicated to index all articles correctly and create a complete system covering every individual case. So the idea turned out not to be feasible for our design system.

Since the original UI map as an individual tool was seen as comprehensible and highly insightful by the participants, I decided to utilize it as a means of content exploration instead. This revamped method of exploration was well received by the test users and considered a valuable addition to the system. In the final concept, a visually refreshed version of the UI map is now embedded as part of the styleguide’s home page. For one, it can simply be used to learn about the modular way pages are built, as well as the functional relationship between elements. Above that, however, users can interact with the map in order to find content that is relevant to them. Selecting an item will bring up a dialog offering direct links to the most visited pages regarding the selected topic along with a short description of each. If these don’t yet match the user’s requirements, there is an additional link to reveal all related articles.

Human Experience Language — Home Page

Like what you read? Give Pascal Heynol (Becker) a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.