Back to Homepage
Back to Homepage

Design Enablement in Design Teams

Overview

The field of design is changing. It is becoming less and less common for designers to have formal backgrounds in design. Not only this, but with more demand for design in organization than ever before, designers are doing more with less (and sadly less support.) I report to a manager who manages 14 designers.

In all this, to enable designers, they must have job satisfaction, clear paths for contributing, direct impact on product direction, and more.

We can enable design by:

  1. Onboarding Designers to Organization's Approach (Design System, StoryBook, etc.)
  2. Encouraging Cross-Collaboration between design teams
  3. Increase Velocity through more reusable assets (Annotations, Presentation Templates, Miro Templates, Survey Templates, Figma Templates, and more)
  4. Creating frameworks and safety nets for using tools and learning designs

Onboarding Designers

Onboarding designers is particularly difficult because the depth of product knowledge our field requires. In order to enable design teams, new teammates must be onboarded well.

  • Onboarding Roadmap: First 7 days, 30 days, 90 days
  • They know their teammates: org chart or product team has their own page that demarcates who is on the team and doing what.
  • They know the technology philosophy: agile vs waterfall, scrum vs. kanban,
  • Building Rapport is emphasized: for example, when hired doing 1/1s with all future teammates
  • Channels are open for questions: clear and obvious channels for connecting with teammates about questions
  • Design Reviews are frequent and focused

Encouraging Collaboration

Collaboration improves the products we make. With more collaboration, there is visibility across initiatives, future work, and ultimately opportunities for working together smarter. Collaboration can be encouraged these ways and more:

  • Cross functional recurring goal oriented meetings
  • Communication channels for asking questions, brainstorming, and iterating (Are design patterns being used across products?)
  • Does the design team communicate with the marketing/ branding team and front end-engineering teams?
  • Drive adoption of shared assets: design system components, templates, and frameworks.

Increasing Velocity through Reusable Assets

The collective goal of a design team should be to do more "upstream," work: drive strategy, inform decisions, generative research, test designs, etc. "Downstream," work: pixel pushing, endless mockups, make it shiny, are much less valuable than upstream work. There is a place for both, but reusable assets and patterns makes it easier to have more time for upstream work.

For instance, a major growth area for WellSky is introducing organisms and templates into the design system. Currently, designers individually place molecules into designs. To go further, templates don't exist, so that Designers individually design common workflows and have less time for exploring solutions to workflows that are exceptions.

3 different examples from 3 different products designed by different designers.

A input field organism set as rows

An input field organism set as columns

At times rows or columns are appropriate to use in designs.

There are many places to introduce reusable assets, but the example above is a widely used scenario that will save a lot of time for our designers.

Creating Frameworks and Safety Nets

It should be easy to branch changes into a team's design system. WellSky's current approach makes it difficult to introduce changes, but I have found success by taking initiative through branching the design system, making changes/ additions, selectively showcasing the functionality to others, and finally introducing to the entire team. This work has led to these questions:

  • How are changes to the Design System being branched and merged?
  • Are the components setup to align with color tokens, sizing, and auto-layout?
  • Who are the decision makers or how is design by committee navigated (blind dot voting?)

The below two examples showcase the way documentation can exist in a design system to define the behavior and interaction of a component.

Documentation explaining the use of the input field organism

An image of the WellSky Design System Addition Template

There are pros/cons to using frameworks like this. Here are a few: since we all own the design system the work is often in addition to our current work, we often design by committee which sometimes leads nowhere, no one person is making design system enhancements alongside Figma updates. The biggest challenge we have faced is simply helping designers learn Figma (who else didn't know about the absolute positioning button or the way to chat with the backslash??)

It is of enormous importance to get people up to speed with how to use Figma before their designs are everywhere and hard to maintain and reuse.