Challenge

• We needed a PropertyList component to cater to different name and value pairings across HPE services

Understanding Product Requirements

The HPE Design System empowers designers and developers within HPE to create accessible enterprise app experiences. It has become the foundation on which HPE is transforming the UX of its service platforms.

As part of the requests to the HPE Design System team, there was a need to design and develop a PropertyList or DefinitionList component showing different kinds of name and description/value pairing, including: Short names, multi line description, multi line names, short description, read-only, and interactive.

This was my first big project as part of the Design System team. I began conducting research and understanding the product needs further. I focused on the following first steps:

• Understanding the DescriptionList element in HTML, its basic structure and common uses

• Collecting use cases across the HPE service apps to see how PropertyLists were being utilized and presented.

• Exploring how other design systems are defining and handling such a component.

Defining Component Needs

As a designer, the term “PropertyList” felt a bit dev-centric to me. Knowing the importance of language when it comes to design systems, I wanted to make sure that the name of the final component was intuitive for both designers and developers. So, I advocated for the term “Name-Value List” instead, and the team embraced it.

I paired up with the lead developer to define the component further. At this point, I defined a Name-Value Pair as:

A name-value pair is a set of two related elements: a name, which identifies a data item, and a value, which is the data that is identified.

Based on my research, I began to categorize the typical kinds of “value” content being presented by different apps. This would help me account for and test against a diverse set of use cases during my design process.

This exercise helped me determine the anatomy of a name-value pair. At its most basic level, a name-value pair would contain a name and a value field, along with an optional icon for either/ both. In terms of layout, there would be a choice between two options: horizontal and stacked/ vertical.

The real challenge I quickly realized was to make the component flexible from a Grommet standpoint (which is the open source dev engine for the HPE Design System), but also prescriptive enough for the HPE theme users.

Having defined the Name-Value Pair, the purpose of the Name-Value List component became to:

• To visually associate item names with their definition or value

• To present data items in a clear, scannable and consistent way

• To help decrease time taken to review and report on data

Once we had the definition and anatomy in place, I turned my attention to other details that needed to be carefully considered:

• What would be an ideal character/content limit for both name and value?

• Best practices for longer value content: truncation vs. reveal by default?

• Hierarchy: which should be more prominent–name or value?

• Providing styling options for type and spacing

• Toggling between the form input to the static version (guidance around presentation and edit mode)

• When there is no value input - what to show in the value field by default?

Establishing Guidelines for Visual Hierarchy

Designing a successful component would mean giving UX designers and UI developers enough flexibility for presentation, while still maintaining brand consistency and visual hierarchy. The Name-Value List component in particular would always need to be scannable and easy to grasp. To facilitate this need, I created guidelines for visual hierarchy which were focused on 5 aspects: order, headings, scale, font-weight and color.

Determining Component Variants

Based on product needs, we identified 3 main types of Name-Value lists: Horizontal, Vertical and Grid.

• Horizontal was defined as the default version of the Name-Value List component.

• In each variant, name would always come before value.

• By default, all content within Name-Value Lists would always be left-aligned.

Designing for Responsiveness & Interaction

The NameValue List component in the HPE Design System is built for responsiveness where it would change to a single column on any viewport smaller than 768.

Instead of using custom sizing, we aligned the widths of the name and value column with existing T-shirt sizing in Grommet and the HPE Design System. As a result, we were able to provide the following options:

• Name

  • XSmall: 96

  • Small: 192

• Value

  • Medium: 384

  • Large: 768

Publishing & Distribution

After several rounds of internal reviews from stakeholders and a final code review, the Name-Value List component was finally published on the HPE Design System site as well as in the Figma library.

As teams use the component in their work, we continue to get feedback and any new requirements or improvements are noted as part of our backlog.