Successful card design in 3 steps: UX, UI, and Framework

Introduction

I’ve worked on various ed-tech products over a few years in my current position as a product user experience designer. We’ve updated the designs to existing codebases, and we’ve architected new interfaces from the ground up. In user experience design solutions should revolve around your user's needs, stakeholder’s priorities, and production realities. Despite all of those aspects being different for each product team I was on, one specific feature continued to be a piece of the larger design languages that we created. Cards.

Was it because they fit our need for displaying heavy metadata in a digestible fashion? Or was it because I was subconsciously pushing them as a solution because I realized their value? Maybe. Whatever the reason, the contextual metadata displayed in these bite-sized chunks successfully displayed the right information, in the right context, for various types of platforms.

Cards resemble physical cards and are a classic example of a usability heuristic — matching the system to the real world.

They provide organization to an interface, creating a mini and sometimes super complex design language within a larger system. I’m going to walk through how we successfully designed cards in three steps: information architecture (or UX, or wireframing), visual design (or UI) and framework (or environment). I’ve also listed out some questions to consider in each phase, because the more intuitive and curious you are about the problem you’re trying to solve, typically the more successful the design will be.

1. Information Architecture/UX Phase

As they say, it’s all in the cards. Cards are typically used to surface content and actions for a single piece of information. Think about the grid of items on Amazon, cards. Or the upcoming shows to watch on Hulu, those are cards too! It’s about giving relevant data and removing all of the noise. Of course, there are tons of other conditionals that could affect the information displayed on cards, and your part as a designer is to figure out what to display.

They’re skimmable sometimes actionable but in order to be successful, need to have a thoughtful hierarchy.

Small cards, large cards, cards with avatars, cards with thumbnails, cards that flip, cards that link to a product detail page, cards with status, cards with wrap-up metrics, cards with badges. They all serve a distinct purpose for what the user needs to know in each individual context of an interface.

Questions to ask when starting to design cards:

• What information matters to the user the most? This will help with the hierarchy of elements on the cards. What are you trying to surface to the user? What is important to the person viewing the interface?
• How much information do you actually need? Remember, the point of cards is to display a digestible amount of information to the user. Think about cards as the elevator speech to something bigger in the interface.
• Is there value in displaying status through the cards? This goes back to a usability heuristic — visibility of system status. Think progress indicators. Not started, in-progress, completed, think something you viewed on Amazon but didn’t put in your cart. Percentage based completion, think how much time you have left to watch on your favorite show on Netflix. Progress indicators can go a long way if there’s value.
• How can you use interaction? Do you want the user to select the card to go to a larger detail page? Can you intentionally use the hover state to display more information or give emphasis to something? Do you want the card to flip to reveal more information? Answering these questions earlier instead of later help to sell the value of the interactivity by creating a purposeful marriage of intention and behavior.
• Are they going to live in a responsive environment? If so, be very deliberate with the width and heights of the cards. Do the cards have a variable width to a certain breakpoint? Is there one size for desktop and one size for mobile? Are certain pieces of information on the cards reductive once you scale down to a smaller screen? (This will also come up again in the swimlane section)
• Should you cater to various device behaviors? Is there enough room to select a button without accidentally selecting something else? This is extremely important for purchase decisions or any type of CTA.

2. Visual/UI Phase

Now that you have the framework of each card hashed out, you can start to add that layer of visual design that really emphasizes the details of the complex visual language that you’ve created. Thinking about the type of metadata and status information in the UX phase of design will create a more powerful visual design.

This goes back to the Gestalt theory that the whole is greater than the sum of its parts.

Visual design is not just picking colors that you like or icons that look cool. Being intentional in a complex architecture with visual elements is extremely important in having a successful experience. Visual design should elevate the hierarchy structure of the card, appropriately represent the brand of the interface, as well as follow basic color theory principles.

Questions to ask when working on the visual design of cards:

• How do these cards look individually? This is what designers always think about: alignment, spacing, text size, all caps, orientation. Does the most important information stand out? What do you want the user’s eye to be drawn to first? Are certain elements competing too much?
• How do these cards look displayed beside each other? We went through many revisions of individual card designs, only to place them beside each other or in multiple stacked swimlanes to see that the visual design wasn’t hitting the mark in the environment they were living in.
• Are the color choices accessible? Baking in accessibility, at a very basic level of color, should be required for anything you’re designing on the web. Your text needs to have enough contrast from the background color to be able to pass a 4.5:1 ratio. Use this color checker to double-check.
• If you’re displaying status, are your color choices intentional? Green intrinsically means success, while red denotes failure in most western cultures. If you’re using something that deviates from this, be consistent throughout the entire experience.
• How many lines of text are you going to allow before truncating? Working with user-generated content could open your designs up to less than ideal naming conventions. You could have an unlimited character limit for some pieces of data. Think about how you’re going to design for this and where you’re going to provide limitations.

3. Framework for Implementing Cards

Now that you’ve moved through the information architecture and visual design portion of the cards, you’re ready to utilize them in the larger layout of the interface. Cards should have already been part of the wireframes of the framework and are ready to be placed into the designs.

Swimlanes are a great way to filter cards, which automatically categorizes them in to intentional lanes.

Some interfaces you may recognize that do this are shopping sites (Related to Items You’ve Viewed, Inspired by Your Wish List), and streaming sites (Recently Played, Netflix Originals, Because You Watched). While working through the wireframes for these ed-tech interfaces, there didn’t seem to be a one size fit all solution for swimlanes either, so let’s dive in.

Stacked swimlanes in an instructor dashboard interface.

Questions to ask when utilizing cards in swimlanes:

• How should the cards be organized? Should recently opened cards display first? If there’s status, do the completed cards go to the front? Or the back? It all depends on the type of user experience that you want to create.
• How many cards do we display in a lane? This is where the intentional height and width of the cards come in to play. Or maybe it’s necessary for the user to see all of the information on the cards at the same time, and putting some cards in a swimlane behind a click doesn’t make sense.
• How many clicks should we allow to the user browsing through the cards? Do you cap it off at a specific number of cards? Do you add a ghost card at the end that will display all of the cards in that swimlane if it’s selected?
• What happens when you search? We always landed on that the search should be searching all swimlanes, and the search results should be outside of the swimlanes. But maybe they shouldn’t always do that, and retaining the categorical swimlanes has value.
• What happens when you select the title of the swimlane? Similar to search, we typically landed on that selecting the title displays all cards in the swimlane in a grid. There’s also value in showing the number of cards within the swimlane in the title.

Final thoughts

I have asked a lot of questions through this article, but haven’t answered a lot… and that’s intentional. This is because your users are different than my users, your stakeholders and business goals are different than mine. Cards are not a one size fits all design solution, nor should they always be a part of the experience. Every card you design is a complex visual language, as a piece of a larger experience. When utilized correctly, they’re a powerful way to express bite-sized content. Hopefully, my experience with designing cards can help direct your journey in card design.

Check out my portfolio if you’re interested in any of my work. Shout out to Scott DuBois, or my design partner in crime. He is responsible for all of the insanely thought out UI design that accompanies my UX design (in this article and at my day job), plus he’s a real cool dude.