Design System: Ops & Component Design

Project Areas:
Product Management, Design/Dev Ops, Product Roadmap, Agile Design/Dev, Team Leadership

Then & Now

After being green lit with funding and approval to begin a design system capable of empowering the needs of enterprise projects, the team required an operating model and a definition of MVP as an initial target to shoot for. The fledgling team was made up of people across the organization serving in a wide variety of roles, and external consultants freshly onboarded to the mission.

The design system team continues to function from the core fundamentals established during the team’s formative days. The spirit of innovation, iteration, and constant improvement remains as strong today as it did with the initial MVP release.

Approach & Role

Before writing a single Post-it® note, I invested in formal Agile training alongside our recently named Scrum Master for the initiative to have a fresh take on the founding principles of product management to get the design system off to the right path. Our initial days as a team were spent getting to know each other and defining what our initial MVP would look like by leading story mapping sessions to build our backlog.

It became clear to me very early on that the first key to success meant that it was not me who should define what success should look like, but that definition should be pulled forward by the team after clearly communicating my intent as a leader. The second key was establishing a production pipeline that empowered communication between research, design, and engineering team members.

The key to success was clearly defining intent as a leader and allowing the team to self-organize and define to solutions based on that intent.

Exploration & Discovery

  • Agile Leadership
  • Resource Capabilities
  • Culture & Motivations
  • Stakeholder & User Expectations
  • Team Personalities

Identify Themes & Focus Areas

Lead Design and Execution

  • Define Intent
  • Lead Story Mapping
  • Establish Production Pipeline
  • Embed Principles as Values
  • Establish Roadmap
  • Prioritize Backlog

Output

Investments made into clear priorities and collaborative processes between diverse team members.

Image depicting the Program Increment board

Program Increment (PI) Planning Board

  • Insights and priorities from stakeholders and teammates points of view.
  • Weighed against backlogged product wishes.
  • Used to guide priorities of each sprint.
  • Image depicting the spring board

    Sprint Board

  • Used to track current committed priorities
  • Follow-on sprints staged with best guesses based off PI planning.
  • image depecting the leads for each subject matter area

    Team Component Leads

  • Pipeline process that creates near seamless transition forward and backwards between subject-matter expert leads in research, design, accessibility, development, documentation, and support (all members step up in support[including myself]).
  • “Your team continues to deliver! Every time I see the design system, it is maturing by leaps and bounds. The throughput of your team is amazing!”

    -Sheldon Barnes, Digital Development Lead

    Team Output

    Each component lead made specific contributions to drive the product forward using the collaborative framework created to manage team outputs.

    Depiction of research guidance docment

    Research & Design Direction

  • Summative research to inform designers for initial iterations of component design.
  • Description of the component and its purpose and likely use cases.
  • Compare and contrast of existing systems and solutions (when applicable).
  • Definition of accessibility requirements and guidance.
  • Links to internal and external related studies e.g., NN/g.
  • Depecition of various component examples

    Component Design Iteration

  • Summative research insights are translated to design deliverables that conform to our overarching principles and visual identity.
  • Designs are shared with all contributing team members (and sometimes stakeholders, circumstance depending) for feedback and design critique.
  • Feedback is translated to iteration and balanced against time/scope requirements.
  • Designs and specs are made openly available to the dev team for development.
  • Depecition of code for button component

    Component Development

  • Design guidance is used to begin component development.
  • “Throwing it over the wall” is discouraged – dev, UX and visual design work openly and collaboratively if conflicts or issues arise during development.
  • Developed components go through automated testing and visual regression testing to ensure we don’t introduce conflicts with other components.
  • Image of the changelog page

    Component Adoption

  • Component is added to the inventory and socialized with stakeholders.
  • Code package and design library files are updated.
  • ‘Portal’ site content is updated to provide guidance to designers and developers implementing with the the design system.
  • Release notes are updated and reiterated across Slack and other comms channels.