Designing Nava’s DEI Report
Timeline: Oct 2021 | Visit link
Description: Nava is a company that builds websites for the government. Part of their marketing strategy is to write up internal content and share their journey, and that content primarily lives on their website. With Nava, I collected and visualized employee demographic data securely and accurately, crafting a comprehensive and insightful DEI report, along with a case study.
Technical summary:
Did research on site experience and content inventory
Designed a new reading experience
Documented the component library
Conducted research on site experience and content inventory
In order to successfully design this page, I had to start with research, and so I studied the existing reading experience.
To start, Molly and I received feedback on current feelings of the experience, both visually and experientially. There were two main audiences for our content: prospective new employees looking to read about the company before possibly joining, and prospective clients looking to hire Nava. Both audiences felt that it was a bit confusing to figure out what Nava was, but the overall reading experience was fine.
We had something to latch on with that feedback, and focused our efforts on designing ourselves in a way that promoted our values. More specifically, :
we want to show Nava is innovative and has industry-standard skills
we want to show that Nava has had successes in the past
we want to promote the mission of civic technology
With that in mind, and with the help of our content editor Sara Distin, we were able to consolidate our learnings into a mission statement, and that meant reworking our content strategy. Through that content strategy work, we cut down on some of the redundant web elements and designed our content pages atomically. This was the beginning of our design system.
Designed a new reading experience
Nava is essentially a creative agency for government websites, and marketing our work is essential for getting clients. Our design mission was meant to show that Nava had quality technical skills, a proven track record, and a lot of knowledge to share. Our strategy was to document the components into high-level, abstract categories, and consolidate where we could. The visual designing would be easy after that.
Visually, Molly and I stuck with the current brand, and just made it bolder. This meant making the type bigger and louder, and providing more of a brand presence by including more colors.
From a UX perspective, I didn’t change the experience more than I added to it. I included some metadata at the top, like the author name, or the client the piece was about. There was a side-navbar element that I included on desktop sizes that allowed for skimming content. This helped boil down our learnings to the essential points.
I also included a ‘Related Content’ section at the bottom of each page. This was done to promote even more content at Nava, and required a bird’s eye view of our existing content inventory.
Documented the component library
I despise repeated work, and I knew that a lot of the questions I had when first starting out would likely to be asked again. I made it a point to leave my team with a living document before I left, full with standards on how the code architecture worked, how the CMS worked, and what components were included where.
The goal was to not make a master Bible. The goal was to make a process where a living document like this could be helpful for future team members, and this includes making it sustainable to update.
Some issues I focused on specifically for the documentation:
naming your components is important for a shared understanding
provide different contexts for your components; how is this relative to developers? to designers? content folks?
what is the update process? Is it sustainable?