Visual hierarchy guidance in design systems

Question

While exploring various design systems, I get a little bit confused as to what design systems are meant to be and how they are actually being implemented. Design systems, by the very presence of the word "system", should contain logic and guidance how their UI components should be applied to a web page, let's say. However, as far as I can see, that is basically left to the designer to decide on their own.

I am mostly interested in the use of UI components under visual hierarchy. Let's say I am creating a web page with up to four levels of visual hierarchy, I want to have a list named "Visual hierarchy level 1" with components designed with highest visual weight, then a a list named "Visual hierarchy level 2" with components designed with less visual weight, and so on.

Have you stumbled upon a design system structured in such or similar way?

And how do you resolve the visual hierarchy issue when guidance is absent?

Answer 1

It's quite complex to set the environment that you're trying to solve here. It's more difficult when you set it on your mind and trying to explain to someone like if you're asking to read your mind. You can also can add some gray boxes to help you. However I had quite the same problem trying to solve a visual hierarchy with a dashboard, because for the Product Owner all the information was important to have it at first sight (first lie). Reach your stakeholders and ask them questions about the task that you're completing at that specific moment. That's how I solve my issue with the dashboard. For example you could use sizing to set the visual hierarchy and for that you could use the 60-30-10 making the main component use the 60% of the screen. Another approach could be transparency, or selection. Maybe that's why there is no rules in your DSL to set the hierarchy, because it will depend on the context of the task.

Answer 2

I tend to think of design systems in the same way that Lego is a system. If you are the designer, then it's up to you to decide how to put together the parts of the system to achieve your goals. If you are not the designer, then you just view the design instructions that someone else has created to achieve the final product. That is usually the role of the front-end developer.

Depending on the design system you have chosen, you may be able to find examples of how designers have applied the system. These are often referred to as stylescapes.

Very briefly:

1. Larger and more highly contrasted elements are often viewed first by the user
2. Elements that share a distinct look (shape, colour, typeface, etc...) can often be considered to be related
3. Elements that are placed near to eachother can often be considered related
4. Visual hierarchy is not strictly limited to a "top-to-bottom" layout

Ultimately it is up to you as the designer to translate your sketches, wireframes, etc.. into a final design using the design system that makes sense based on your objectives. After user-testing you can evaluate if your design was successful or not, and make changes if required.

TLDR;
Most important elements are big and bold, least important items are small and subtle

Answer 3

If I understand correctly, you want to have a DS (design system) that specifies exactly which components are used for building each part of the page according to its visual hierarchy level. In your case, you mentioned 4 levels, so 4 sets of components.

Indeed, I haven't seen that either.

I can see a few reasons why it might not work in practice:

• It's quite hard to decide the visual hierarchy for a product feature, so most designers prefer to keep everything flat, to avoid mistakes.

• Most design systems offer components with various sizes, to accommodate multiple situations, so from a DS team point of view, that solution is better than enforcing a hierarchy.

• For many apps, there is no clear visual hierarchy. It all depends on the current task of the user. A page can contain multiple product features that become the most important when the user needs them, so there is no hierarchy.

• Product requirements change all the time, while creating a clear hierarchy takes significant effort. Many teams don't have the expertise or the capacity to adapt the visual hierarchy with every feature request. And since the DS must offer practical solutions, visual hierarchy is left for product team to decide.

• Due to human diversity vs design limitations, it can be very hard to create a clear hierarchy between elements. Some people might notice the bigger elements first, others might notice the colorful ones first, others might start focusing directly on middle of the page. So at best, the visual hierarchy can be intended, but not enforced.

Dunno, maybe you can have a design system with clear visual hierarchy guidelines, but it might only work for some specific products, and it might also be harder to maintain.

Answer 4

In my eyes, a Design System contains four crucial layers:

• Design building blocks (components, styles, variables, etc.)
• Code building blocks,
• Documentation
• Governance (including version management).

Now, when organizing a DS, approaches will differ depending on the tools used. Figma, for example, doesn't support hierarchical styling, so this part needs to be pushed towards documentation.

The following three methods help me a lot when setting the "gravity" of some elements; maybe you will find them helpful, too. Note that I use the atomic design approach, which is great for organizing hierarchical design elements, even though the border between these elements is often blurry.

At the atomic level: For action-related components, I create primary/secondary/tertiary/subtle variants of them. The subtle ones are all those that don't need to propagate their clickability because if someone wants to use them, they will actively search for them and will only need confirmation in the cursor change and a hover color that such an element of the interface is clickable. An example would be the "Share, Edit, Follow, Flag" items for this very interface of StackExchange.

At the subatomic level: I define the base, subdued, and prominent versions of styles and fills. This lets me use, for example, a glyphs-base color for all the normal texts and icons and glyphs-subdued along with a less prominent text style for the secondary information. Whenever some portion of text needs some special exaggeration, I use glyphs-prominent for that, on rare occasions, though.

At the organism level: I use a special library containing all the reusable organisms that can be used as templates for any instances they need to be used within. This allows me to build an initial, semi-carved-in-stone structure and alter it only when necessary.

These three help me create a good balance between coherency and flexibility while not using overrides too much.