Card Variations

[SOjaHPE]

Problem As a prominent feature in the UI toolkit, cards have a wide amount of flexibility to present information and enable user actions. However, while flexibility allows interfaces to present a wide amount of information and serve a wide amount of purposes, too much flexibility/variety can lead to uncertainty and unpredictability, ultimately increasing cognitive load/friction and negatively impacting the user experience for end users.

Problem Statement

How might we define cards so that they enable products to flexibly present information and enable relevant user actions while maintaining a predictable, familiar pattern so that users may easily consume and confidently act on information?

Design Challenge Create a definition of Card which maximizes flexibility for product designers to leverage cards to solve user problems across a wide variety of use cases (from marketing to analytics to admin to navigation, etc.), with enough guidance and constraints to not compromise a user's ability to comprehend and predict a card's purpose and functionality in a quick, confident manner across HPE product experiences.

Success Criteria

• Definition of Card (Consistency) - Card usages should have a name or type associated with their application so that HPE designers and developers have a shared set of language to use when a type of card (tool) is being applied to a problem (job).
• Enable designers
  • Maximize flexibility and ability to apply Card across a wide variety of use cases.
• Demonstrate card being applied to a variety of use cases, stating its purpose (what user problem is it solving) and role (how it solves the problem).
  • Designers can state "I know which type of Card I should reach for in which circumstances"
• Test (how will we know we are successful) - End users should be able to view cards in a variety of contexts and be able to anticipate what they might find in and do with a card within each.

---

A detailed card pattern is needed to provide guidance around the different variances of cards that are being supported across the BU's and platform.

There is a need for a flexible pattern that provides support for instances & variants for the components facet containers: header, body, background and footer.

Prioritized by the following teams:

• There are new card designs proposed by Chris C. for the new CCS landing page design in an upcoming release.
• Guidance has been requested by Shawn S. and the .COM team. Need to differentiate the different types of cards that might be specific to .com or apps.

tasks

• [x] #2885

Problem Space

• [x] #2487
• [x] Card - Do some research into NNG guidance, other design systems, etc. (handled by #2487)
• [x] #2584
• [x] Card – Incorporate Feedback Received from Taxonomy Proposal
• [x] #2608

Solution Space

• [x] #2507
• [ ] #2514
• [x] #2513
• [x] #2279
• [x] #2911
• [ ] #2912
• [x] #2913
• [ ] #2915
• [ ] #2962
• [ ] Card - Review with stakeholders
• [ ] Card - Implement examples in design system
• [x] #2916