-
Notifications
You must be signed in to change notification settings - Fork 4
Design system blog posts
https://mattfelten.medium.com/horizontal-vertical-thinking-in-design-systems-7486409311c8
Horizontal thinking is looking at the big picture of the problem, creating consistency across an entire project.
Vertical thinking is looking a the details of the problem, diving in to see what the unique circumstances are, and figuring out the best way to solve that specific problem.
Too much vertical thinking will get too in the weeds with considerations and the design system will become fragmented with exceptions. Too much horizontal thinking will lead to a very consistent but rigid system that doesn’t serve business goals. A balance of both is necessary.
https://dbanks.design/blog/multi-platform/
Here are the public multi-platform design systems that I have found:
There is no single right way to support multiple platforms with your design systems.
Different products and organizations have different needs.
To have multi-platform design systems does not mean everything needs to look and function the same across all platforms.
"We design and build in parallel so any discussions on details that come up during implementation (and there are usually many) get addressed and considered together."
Systems should support how creators work.
Lowest fidelity to express intent
This doesn’t mean we never use design tools, but our focus is to reduce the collective time to go from idea to launch. We encourage people to use the lowest fidelity to express their intent to…
Get to code quicker
Getting to code quicker allows you to see the experience that customers see rather than an approximation of the experience.
https://bigmedium.com/ideas/design-system-pace-layers-slow-fast.html
Design systems should prioritize quality over speed
Successful design systems move more slowly than the products they support. That’s a feature, not a bug.
Quality can’t be rushed. This infrastructure layer should move more deliberately than the faster product layer, where products often have to emphasize speed over quality. Shipping a product feature on time, even if just a rough MVP, often has enormous business implications. And so short-term hacks, design debt, and technical debt are often necessary to meet business goals. Sometimes you just have to take shortcuts to get the thing out the door. That’s a fact of life for the product world.
While that’s true for product, it’s not true for the design system or other infrastructure projects, where design and technical debt are far more expensive. Understanding the design system as critical infrastructure—not mere production support—provides the logic and permission to move deliberately in pervasive, high-stakes aspects of your product development (infrastructure) while still moving very quickly in others (product).
What do you do when a product team needs a UI component, pattern, or feature that the design system team cannot provide in time, or is not part of their scope?
The answer is not to add a rushed or ill-considered solution to the design system library to meet the product team’s urgent need. But it also doesn’t mean that the product team should slow down and wait. The pace layers should move at their pace and in their own lane, without hurrying or slowing the others.