Design system for a responsive web application

In the spring of 2018 I was hired as the first designer at ShippingEasy. Before I joined the company, design was an outside resource with no one person on the product team ensuring a consistent visual design and user experience. 

There were tons of inconsistencies within the application’s UI. I was faced with a decision to either continue to design within the current pattern library (based on Bootstrap 2 which was several years old by that point), or start working towards a new more consistent UI. Older pages in the app were built in rails while most new features were being developed in react.

Problem

• Inconsistent UI is causing difficulties around learning how to use the application and causing confusion new and experienced users.

• Inconsistent design files are causing delays when app developers need to build one-off components as they view them in design files.

• No reusable, shared design components for designers to use in mockups increases the time it takes to create or update design files.

Questions:

• How will we update legacy UI with elements from the new design system?

• How would we share components between designers and make deployed elements available for all developers?

Design & Engineering Goals:

• Work more efficiently as a designer by utilizing shared and reusable Sketch symbols. 

• Involve engineering team to discuss new UI components and how they would work, how we could share them with the greater team, how to plan on going back to update old UI, etc.

• Work on a plan to modernize old UI to match new UI built in reusable react components

Design + engineering UI strategy

• Design new components that loosely resembled the legacy UI built with Bootstrap

• Developers would build out components as they needed them for UI they were responsible for

• Engineering would work with Design to ensure front end implementation was correct

• Engineering would publish shared components into Storybook for use by the wider team

• Legacy UI would be updated to match new UI ad-hoc

Pattern library components

Detailed specifications provided for complex components like a date picker:

Sharing resources across the product team

Collaborating with cross-discipline teammates using a common design language worked because we used systems to view and share the component libraries. New components become available with each update.

• Abstract: for product design team

• Storybook: for engineering team

Coordination across disciplines

I worked with product management team to update outdated existing UI by creating tickets and carving out time in the product roadmap. I also gave presentations to the engineering team to educate them about design, how to work with the design team, and updates to the library of components.

Lessons Learned

• Good, continuous communication to developers and QA is a must.

• Some members of the product team need help from design to learn how to see things like a designer would.

• Simple things can get really complicated: eg; how do you pad elements across pages that use UI components differently.

If I could do it all over again…

• More thought and ongoing discussions around establishing a deeper design system, and not just a component library. I would have put more thought into branding, tone, and how copy is written and how those things fit into a design system.

• Emphasized usage of consistent grids.

• More guidelines on how and when to use certain components, and how components interact with each other. I would like to proactively share this kind of information with shared resources or presentations.

• Work to get the initial build out of components onto the product road map. Working on it as time presented itself proved challenging.