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:
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.
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:
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.
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.
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:
The below two examples showcase the way documentation can exist in a design system to define the behavior and interaction of a component.
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.