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:
- articles whose content is completely entered, reviewed and ready to go
- 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: