Challenge
Design an accessible visual and interaction language that communicates Child Welfare Digital Services experience principles so that social workers can have a consistent experience throughout the system. Also, it needs to work well on older monitors found in most government offices. 
Our Users
Our users are social workers at Child Protective Services and their number one priority is to make sure children are safe when allegations of abuse are present. Some of their responsibilities include: taking reports of abuse, investigating the allegations of abuse, working with families to provide support and services, and finding potential foster families that children might need. 
Getting Started w/ Principles
Our design director had worked with designers and stakeholders early on to define our project's experience principles which was a good jumping off point for us. Here is a sneak peak: 

1. Keep the child at the center, not the system
2. Use data to make informed decisions.
3. Allow work where and when it needs to be done.
4. Connect policy and practice. Support good social work
5. Cultivate professionalism, trust, and connectedness

California social workers are currently using a system that is 20 years old and centered around cases or units of work rather than the actual people they serve. It gives users a lot of information at the wrong times and does not help them make decisions. If anything it forces them to expend a lot of unnecessary mental energy on data entry. All this to say, an important influencer in our visual and interaction design direction was to eliminate clutter, focus on the people, especially the children, and make the system exude trustworthiness.

Laying the Foundation
Colors, Typography, Spacing 
Creating a color palette took longer than we expected, but mainly because accessibility was our top priority. Colors that added a more friendly and trustworthy touch were often not meeting contrast standards for our visually impaired users. We eventually landed on the palette below which my coworker cleverly named after different types of trees and fish. 

We decided to use rems for all of our typography and spacing units for consistent and easy scaling across device types. Responsive design was a consideration in all of our work as our users go into the field daily.  
Defining Page Templates
Our team had defined a set of page templates that all product teams would benefit from: a login page, a landing page and a task page. The task page was already under development by one team so we focused our energy there first.  
Building Components  
We needed to move fast since we had developers waiting on us to start building out the component library. So, we referenced material design as a starting point. 
We started applying our foundational design decisions to page templates and prioritized our efforts designing components that would be needed first like: cards, basic form field inputs, people avatars and search. 
As I mentioned previously, a big focus was making sure that children stood out from other elements on the screen - reinforcing the person or child centric system.  One way we achieved this was by differentiating the person card component from the standard card component. The person card contains a photo, emphasizes demographic data about that person and also references their role in a situation (perpetrator, victim, etc). We did a usability test session recently and a user said, "I like the photos. It humanizes our clients." That was probably the best validation we could have gotten! 
Documentation
For each component, we wrote usage and accessibility guidelines for designers and developers to reference. This was just as important as the designs themselves as it's what guides when and how the components will be used later on. 
Defining the Tools
The tools we commit to using (at least initially) are important because we want to make sure everyone is empowered to follow and contribute back to the library. Three tools were suggested as a starting point for building out our component library: Zeplin, Sketch and Storybook.
Zeplin 
Zeplin was new to me. A coworker introduced it as a tool we could use to share our design system across product teams and use to provide specs to developers in HTML and CSS.  Here is a screenshot of our color palette and CSS specs to the right. 
Sketch 
A common tool on most design teams now, Sketch. One of my favorite tools for rapidly mocking up interfaces. I have found it very useful to keep a copy of a component library in a shared space, like dropbox so that everyone can add and update it. Below is a screenshot of our sketch file organized with pages, canvases and groups. 
Storybook
Our component library is currently leveraging the Storybook environment. Updates are ongoing as we will continue to build out this shared library but you can check out the current state here: In-progress react component library
Lessons Learned
1. Start sooner
With one team on the ground already building product without a component library in place, we knew that there was already going to be some design and development debt for starting this initiative too late in the game. Better late than never, though. 
2. Fight for a dedicated team!
We were challenged with working in a unique environment at the state office which had four different vendors (meaning four different design teams) on the ground working on different parts of the same system. Different being the key word. That also meant we were all solving the same problems in, you guessed it, different ways. Designers had to fight for part-time allocation on cross-team initiatives which was easier said than done. A centralized time with full-time allocation is definitely ideal. 
Back to Top