The Need for Multi-state Cards in UX Design

According to a definition by,

Cards contain content and actions about a single subject.

They should be easily scannable by the user, as they are typically clumped together in groups.

Think of playing cards: each card holds a unique set of information. For example, the 6 of diamonds holds specific data that separates it from, say, the 3 of clubs. Depending on the game being played, the player interprets each card as how it can be actioned, in order to achieve a goal.

Cards in a public-facing website or application, much like playing cards, are often limited to a single state. What they represent is often non-varying and not very dynamic. You click on the card, and you are linked to a single page.

But sometimes there’s a need for a card to change state, or to have multi-states. This is often the case in Admin applications, where the need to dynamically sort information is more crucial. Just like in many card games, certain cards can hold multiple values.

In Black Jack an Ace can either count as 1 or 11.

As an example, let’s take a look at the custom CMS we built for our internal operations on Acorn Interactive’s site. For starters, we divided our backend into 4 sections:

  • Blog
  • Case Studies (Portfolio)
  • Jobs
  • Users

We then gathered our Admin User Stories that answered the following questions:

  • How a new/existing blog article should be generated/managed in the backend
  • How a new/existing case study should be generated/managed in the backend
  • How a new/existing job post should be generated/managed in the backend
  • How a new/existing user should be generated/managed in the backend

The generating of content is pretty straight forward, but depending on your internal operations, the managing of that content might need to be more nuanced.

Consider one of our Admin User Stories:

As an Admin, I want to be able to toggle a blog article between live and hidden so that I can manage both types of content.

Right away we see there’s the need for a post (represented as a card on a listing page) to have at least 2 states: Live and Hidden.

Now let's consider another one of our Admin User Stories:

As an Admin, I want to differentiate between 2 types of hidden blog articles:

  1. articles whose content is completely entered, reviewed and ready to go
  2. articles that are not ready to go live (whether incomplete or otherwise)

…so that I know which articles need to be finished and reviewed.

As you can see, 3 states are now needed to manage the cards based on the Admin User Stories provided: Live, Inactive and Draft. Another benefit of having this Inactive state is that it can act as an archive of posts that can be pushed or pulled from the live site at any time.

The use of cards to organize all 4 of our backend sections seemed appropriate, as the admin user can easily scan and manage them, all in one dashboard view. For reasons outlined in our To Repurpose a Component or Not post, we decided to create a new card component for our custom backend, that would address different needs than the cards on our public-facing website. But what’s more, by creating this new card component we were able to address the needs of our 4 backend sections in a more precise way.

We knew that we’d be generating immediate and ongoing content for the Blog and Case Studies sections. As for the Jobs and Users sections, these would be more defined in the future, but we were confident their requirements would fit into the same card component as the others.

So in the end we decided to incorporate a 3 state toggle component that would live on each card:

Draft: a post that is not ready to go live (either not complete, not reviewed, etc…)
Live: a post that is currently live on the public-facing site.
Inactive: a post that is complete, reviewed and can be pushed live anytime.
A dashboard view of a multi-state card in action. The radio buttons in the right margin of the page allows the user to sort the listing cards based on the 3 states.