Design system: beyond Alpha

[gumbeauuu]

The ask

As we're closing in on front-end feature parity to D8, let's take some time to work through what our design system looks like beyond alpha.austin.gov. How do we do more with less, and achieve better results than before?

Background We've heard things that indicate we need to broaden our scope about what a design system is (and isn't), who it's for, and how we're developing it. So far we've been focused on alpha.austin.gov, and we've had a few examples utilizing the solutions for the resident-facing side for other purposes (wrapping around other front-end applications such as recollect, and our Joplin authoring interface). We haven't been thinking about our design system applying to a broader audience than our team, and the resident and staff that our products serve--but we want to asap.

Contextual frames

• We're currently in an emergency response due to COVID-19, and people are standing up digital solutions very quickly--how can we better support city staff and residents in scenarios like this with timely, ready-to-go resources?
  • What is vital to our staff and residents right now, from a digital services perspective? Things like: symptom checkers, dashboards, ventilator inventory, coordinating resource delivery (food and supplies for vulnerable populations, and residents experiencing homelessness). Would our component library be able to support that? What would we need?
• Reflecting back on our own experience, what have we learned, and how have we optimized workflow for our problems? Would the solutions we've developed work for other teams? How might we package those solutions for others? In the vein of funshops, SDL activity sheets, etc.
• More mature product teams have whole teams dedicated to design systems or specific product feature-sets, and we're a really small team. How do we scale this work in a way that's sustainable, while also constantly elevating quality?
  • How we get stuff done: workflow guidance (Abstract, XD, design within Agile,
  • How we know we're making a difference, and improving outcomes: research and best practices, user testing

Who and why

• Who needs a design system within CoA? What's the range of applications that a design system would need to support?
• Why would they want to use it?

What / deliverables

• What does a city-wide design system need?
• We can give components and guidance, but what does the experience of implementing something from a dev end look like?
• What's the state of designers and developers at the city? Are there centralized communication channels and resources? Are most things contracted out?
• What are the deliverables we have on-hand? Process documentation, Abstract version control/collaboration/dev handoff, best practices, component/pattern libraries, etc.
• What are the deliverables that we need? Create a matrix of assets and deliverables (color, type, spacing, motion, etc.)

---

Potential to-dos

• [ ] Sync with Marni about what the dialogue is like at the leadership level, their goals, hopes, and fears
• [ ] Start at the end: what does the outcome look like of a fleshed out design system for the City of Austin
• [ ] Conduct research with city designers and developers outside of our team about pain-points in their workflows regarding UX/UI development and implementation, and user testing
• [ ] Talk with our developers, service designers, content strategists, research colleagues, policy lab about their digital product needs from a UX/UI standpoint. What problems are they trying to solve within their work that the UX/UI design discipline could help them with?
• [ ] Desk research on previous efforts by other teams to merge a city under a unified design system (mass.gov, gov.uk, digital.gov). What's realistic? What can and will go wrong? How to start small?
• [ ] What deliverables or guidance can we provide that puts tools and resources into the hands of others? Who are the users, what are their needs?
• [ ] What are design's goals? We can and want to help people work quickly, but how can we make sure the quality and fidelity are also high as they move fast?
• [ ] Develop goals
• [ ] Create a roadmap for design system work that aligns to those goals

---

What we've heard, and seen

From Kristen Mobile: https://kristintaylor518545.invisionapp.com/overview/Affordable-Housing-Search-Form-Mobile-ck7ly8l3d03q20150fxgym8w2/screens?v=7iwP1UA62XRFr4rSPNa8Jg%3D%3D&linkshare=urlcopied Desktop https://kristintaylor518545.invisionapp.com/overview/Affordable-Housing-Search-Form-Desktop-ck7m2uylm00kt01225u5v99uw/screens?v=7iwP1UA62XRFr4rSPNa8Jg%3D%3D&linkshare=urlcopied

For now, just handing over specs to the developer. So having screens or any type of documentation/standards that you follow will help. They have a crazy code base. But I think the most useful thing for me is the visual and interaction standards that y’all are using or have set so that I don’t have to re-create them. This product is totally a scrappy MVP and will likely be completely re-built at some point. Having us involved in the discussion when that happens will be more likely if we can help them make what they currently have better. That’s my 2 cents.

ATD's Vision Zero Dashboard Amenity asked our design team for some quick feedback on a dashboard they're developing. We provided UX/UI guidance as direct comments on their prototype, as well as UI suggestions. https://share.goabstract.com/2fa7418b-f5e3-4ae2-ac14-a7641a83efee

Recollect app redesign Applying the alpha design system to a pre-existing application by a third-party vendor. https://share.goabstract.com/0dbbc470-5eec-4d04-ac88-c9f78dd2b48a

---

Resources

• Invision's Design Maturity Model: https://www.invisionapp.com/design-better/design-maturity-model/
• Level up framework: https://df1.designerfund.com/levelup/
• US Web Design System: https://designsystem.digital.gov/
• Google's Material design: https://material.io/
• Tailwind UI component library: https://tailwindui.com/
• Microsoft's Fluent design system: https://www.microsoft.com/design/fluent/#/

[easherma]

Just offering some thoughts, especially as the concept of a 'design system' can mean many different things depending on your discipline.

I love the 'how to use section' on USWDS: https://designsystem.digital.gov/how-to-use-uswds/ Especially the maturity model they outline: https://designsystem.digital.gov/maturity-model/

I know we've mentioned this before, but on the topic of talking to other cities we could easily get in touch with the author of the Chicago Design system, I'm sure we could reach out to others as well.

And I think it presents a pretty good roadmap on how we could prioritize the development of a design system:

1. Principles
   • Alot of this is codifying our values and how they inform our approach to design
   • Getting CTM and other departments on the same page regarding these principles is the biggest blocker to greater utilization of a design system
     1. Guidance
   • This could look more consultative, where we are helping review or inform designs but not in a position to dictate the nuts and bolts of how they are implemented
   • We can provide documentation and guidance on our best practices (like the content styleguide), that people can reference for projects
   • I'm about to run into this now with some SDL projects, where I feel I have a pretty decent handle on Principles. Though they aren't documented explicitly, I feel like I've learned a ton just working with @chase-vert and hearing his approach described during our various Sprint Reviews. So I feel confident that I can start to design and build out these projects, but will probably want some additional direct guidance at some point.
2. Code
   • The code in Janis is very far from being able to be easily re-used in other projects, for a variety of reasons
   • In fact, even if we wrote and coded a dynamic design system, without the getting in lock step about Principles and Guidance, chances of people actually using the system will be low
   • We are a small team, so the ability to help facilitate adoption of the design system code wise is pretty limited
   • We are still learning what we need and what works for us and for residents, there is a potential sunk cost fallacy of us building a design system a certain way(code wise) and not being able to throw it away later if it doesn't work out (and how would we measure the success of such a system?)

[gumbeauuu]

@easherma thank you for contributing--all good points. It would be great to hash something like this out that represents all disciplines, and offers a wholistic view of how we define a "design system", and what can/should be shareable, and how.

[gumbeauuu]

Brain drain no.2, trying to add shape to these ideas

TOOLKIT ready-to-use artifacts that other colleagues can use with minimal training

• palettes: provide a few accessible combinations
• type options: typescales for desktop, tablet, and mobile
• common UI elements
• presentation assets: things like cards (for annotations), slide templates, icons, etc.
• XD style sheet that can be imported into any XD file that includes: components, type styles, and colors. we have a working MVP of it within abstract currently. it's managed via abstract, but it's still a cloud document, so any updates to that file will propagate to any documents using assets from the original stylesheet

GUIDELINES

• frame things from the perspective of someone who isn't a design expert, and wants to make her ideas visual, using pre-vetted artifacts
• what do people ask when they're asking for design help? what do they want, need?
• accessibility criteria: explain the standards, how we think about applying the standards, and why it matters

DESIGN OPS

• translating design value into business value. joplin, open-source development, ground-up content authoring platform
• process: how we get things done / designing within an agile framework. we have a working doc that captures all of this.
  • abstract: git-hub version control and collaboration for visual design. this could be essential for deploying centralized assets to designers, managing visual design workflow, and design ops
  • adobe xd
• d8 vs alpha: what is parity, where are we

THEMES attributes across experiences. this is not in a particular order

• human
• accessible
• trustworthy
• friendly
• official
• easy-to-use