Passport’s Design System
Full design system build out for Passport’s Client Portal, a tool for municipalities to manager their entire parking operation.
Project Details
Company
Passport Labs, Inc.
Project Length
3 months
Team
Miranda Bradshaw (Product Manager)
Taras Kril (Engineer)
Kevin Huff (Design Leader)
My Role
To start, I led building a design system from the existing product, suggesting updates along the way. There was no code-based design system existed so getting one adopted by the organization (which we did!) was also my goal.
Challenge
Uncover all the components currently in use, innovate those designs slightly without making the new design components stand out. Fill in existing gaps
Develop patterns and larger page templates with documentation.
Get the organization to agree to build a design system in the code base.
The Process
Discover and categorize what exists
Learn what design system infrastructure was currently being used and why
Talk with engineers and engineering leaders to uncover the challenges with implementing a new design system
To capture all the existing components, and all their inconsistent variations, I went through the entire site taking screenshots and inspecting elements when necessary.
To facilitate conversations with team members across the business, I created a deck that described the current and future state of the company’s design system. This educated on what a design system was and helped us reach consensus that it was worth investing in.
2. Define and build atoms, then larger components
Confirm component inventory (starting with atoms, then molecules, then organisms (like out side-bar navigation)
Define the scope of work to the business by justifying the productivity and consistency gains. Define the level of investment required.
After capturing all the different kinds of buttons, I mapped out all the variants, tested each for accessibility (color contrast) and begin defining border radius, drop shadows and icon placement. The Button, while technically and organism (has many components like the icon and type), required a full icon library to be built.
I built interaction guidelines, anatomy breakdowns, usage principles, do’s and don’ts for each atom, molecule and organism. These would eventually be ingested into Storybook for production.
3. Develop
Identify Storybook as the place to build our componentry
Collaborate with engineers to refine component designs for production
The team quickly settled on a many-page flow, or wizard, to walk clients through setting up rates.
As quickly as we could we laid out most of the settings required, ordered them based on our early research, and got back in front of internal users and stakeholders. We confirmed the approach but had to make adjustments to the order. In one instance we just were placing to much on the screen at once and it slowed down multiple users.
Variation 1 of rate calendar with the time of day on the y-axis. Engineers and users liked the sidebar displaying the rates but had concerned about instances where they would be 5 or more rates.
Variation 2 of rate calendar with vertical stacking of rates displaying when they are active. This format allows us to handle an infinite amount of rates with vertical scrollling.
Variation 3 of the rate calendars with additional styling and controls. Some of these details were relegated to later sprints for their complexity.
4. Deliver
Finalize Design System Guidelines and documentations
Setup Figma Design System analytics tracking
A 3 page educational carousel for users to get themselves acquainted with the language we’ll use throughout the experience. Here we define terms like rate and rate chain and how these objects relate to each other. It was also an opportunity to bring in some warmth and style.
Here I am formalizing interactions for our design system’s table, displaying the filters our team decided on, and directing how the page level controls change given different circumstances.
Variations of the rate calendars overlay for engineers to consider as we began tackling all of the tiny variations between client’s settings and their user’s permissions.
Rates are comprised of rate chains. This allows the rate to be very custom to the client/municipality yet it also means that our engineers really benefit from seeing out the interface changes. Here is one of the many variations of a rate chain that I built to communicate how the interface reacts to different ways the rate chains can be built by users.