Place Monuments Where Kids Make Snowmen: Wardley Mapping Design Systems
George Nurijanian
Product | Giving product managers shortcuts to work like a pro PM, make good choices & lead without fear | prodmgmt.world ??
I recently joined a talented team of designers & engineers working on a design system.
The system would align all the various products we have with a modern & accessible UI. We're reducing the cognitive load for our internal partners to build great UX fast.
While I've always loved design & research, I've never worked on design systems of this scale. I knew there would be many elements to configure. Lots of thinking about direction & strategy of the product.
Being the one-trick pony that I am, I reached for Wardley Mapping*. Better yet, I asked Ben Mosior if he'd ever mapped a design system.
That turned into a conversation & now, a few of us will map a design system live on YouTube. The session is on June 9th 6AM NZT - tune in, or watch it later!
I'll revisit this after the livestream, but so far, my thinking boils down to the following:
- Design system's core components exist in the Commodity space, and should evolve by methods that aim to reduce variance in component quality (Six Sigma).
- Design systems evolve by Town Planners providing the core commodity components to Pioneers, who build their crazy ideas on top. These ideas are then consumed by Settlers who refactor & repackage the crazy components that work. Settlers then pass those to Town Planners to master and optimise the new core components, in a virtuous cycle.
- Genesis is where you invest more, while Commodity is where you invest less. The marginal value of those investments in Commodity is much lower than in the Genesis/Custom-built space.
- Despite eons of architectural knowledge built up, complex systems evolve best without a strict top down enforcement. We see examples from urbanism like the "desire lines" in city parks & the better placement of monuments in town squares if we follow where children place their snowmen.
Design systems are hard
Making design system features is more complicated than making features for end products. You are crafting the master copy, not a throw-away.
But if you're too slow, you're always playing catch up. Some of the components take months to discover & develop. And that's when we already know their name & general shape.
Evolution in a design system can be handled by:
- developing an abstract shared vocabulary around component properties or
- by ensuring that base properties remain accessible for modification by end consumers.
These, especially the last point, got me coming back to one of Wardley Mapping's doctrines around using appropriate methods, as well as "thinking aptitude & attitude".
Agile, Lean, Six Sigma
Wardley Mapping puts components on a scale of evolution, from Genesis to Commodity.
And what methods work depends on where you sit on the the scale. What works for a new mobile app won't work when provisioning electricity supply. If a component is a commodity, we don't apply lean or agile methods to build. Instead, we focus on reducing variance, applying methods from Six Sigma.
A Design System is a platform for others to build on top. It seems to be in the commodity space.
That would mean that we'd focus less on experimentation and other tenets from the agile world. Instead, we'd work on lowering the deviation of the product. We can describe any process by how many defective products there are.
What's a "defective product" when your components ship in code? The builds are smooth? If we're more specific, do the components we build generate a lot of errors? I'm probably not the first to think of shipping software as a manufacturing process.
Pioneers, Settlers, Town Planners
Wardley Mapping suggests that progress occurs when Genesis components build on top of Commodity.
Ideally the pioneers are not just within your company, but more favourably contain outside companies building on top of your component. Hence, it's a really good idea to expose your newly industrialised form via a public API.
Electricity enabled us to build endless new things on top of it. First, they weren't very good, but over time, the kettles & Teslas have turned into useful products. Some became new commodities (e.g. The Internet).
The more pioneers there are (both inside and outside) the bigger the ecosystem around your component is. This will not only give you greater economies of scale but you can mine the ecosystem to identify future success (it operates as a future sensing engine).
One of our users shared a Github repo of the components they've built outside of our system. Some of them are 2 of our original components shaped as 1 new component. Some are brand new.
A key role of the settlers is to steal from the pioneers who are in effect acting as the settlers R&D centre. Sometimes an internal project is going nowhere and the settlers will steal it, replace with something from the outside market.
Desire Lines & Snowmen
From Nassim Taleb's writing + urbanism, we learn the importance of the natural evolution of the individual parts of the whole.
This is superior to top-down imposed evolution, which precludes that there's some central organism with perfect predictive powers.
One of my favourite Twitter accounts - @wrathofgnon i.e. "Wrath of Nature" - tweets about this:
And we know the "Debunking Bad Design" meme:
It's not bad design. It's just Nature.
Seeing what exists naturally is demand-side thinking.
In the next few months, this will either be confirmed, disconfirmed or forgotten. I'll let Nature decide.
Exciting times ahead!
---
*I don't want to do a disservice to Wardley Mapping by simplifying what it is. I also don't want to send you down a huge rabbit hole you won't go down anyway. But this 5-min summary is the most engaging:
Franchise Development Manager at Red LBP NZ Limited, bringing fresh ideas to life.
3 年Hey George where are you working?
JAM, MERN, LAMP Full Stack Developer With Entrepreneurial Mindset & Management Skills
3 年Congrats mate.
Leadership development consultant helping directors, VPs, and less-formal leaders get clear on their organizational problems and rally their teams to solve them.
3 年Thank you for writing this up! Awesome starter for our convo!