Michela Frecchiami
@mic_design
Michela Frecchiami
Availability doesn’t mean being ready
The first design management role you have might be because you’re handed the opportunity: there is a need, the manager left/got fired, or something else. Availability does not wait for you to be ready. It asks you to give a direct answer if you will say yes to the call of duty². When I took on the responsibility
... See moreWhen someone offers you a challenge, don’t think of all the reasons why you can’t do it. Instead, say, ‘Yes!’ Then figure out how you’ll get it done.” This is the foundational principle for leading with a yes. — Tom Greever
Ethics for Designers — The toolkit
A concept is strategy, visualized
Great designers are able to distill the essence of a strategy and transmute it (through a mockup, a storyboard, a sentence, a quote, a metaphor, or a story) into a form that stakeholders can grasp and embrace.
https://www.doc.cc/articles/concept?utm_source=substack&utm_medium=email
Articulating Design Decisions
People on the outside will criticize things they have a limited view of. But if you give people the chance to be part of the solution, they will either take you up on it or they will see how their suggestion impacts everyone else.
Taking a chance on a person is making a bet not on what they are now, but the potential of what they can become.
David Hoang
The thing when designing - especially B2B tools in particular - is that there are so many guardrails and constraints to consider. This is where true creativity shines! Rather than thinking of designing within constraints as a boundary, I think we should embrace it.
Design matters because it helps us solve problems, think creatively, understand the world around us, develop empathy, and be critical. Just as you would hire an architect when building a house, design plays an important role in creating functional, beautiful, and meaningful solutions in all aspects of life.
Ben Shih
The most general misconception I often see at scale is that, once a design system is established, every product must then use it. “100% adoption” is the goal, meaning design system work isn’t done until every product at the organization has been migrated to use the design system.
This is nonsense.
A design system prioritization matrix
Reading time: around 3 minutes
Design systems have massive impact at scale, especially with organizations that manage dozens, hundreds, or thousands of digital products. But that scale brings its own set of problems.
The most general misconception I often see at scale is that, once a design system is established, every product must then use it. “100% adoption” is the goal, meaning design system work isn’t done until every product at the organization has been migrated to use the design system.
This is nonsense.
For starters, migrating just the codebase of hundreds or thousands of digital products would take years.
The solution is a more pragmatic point of view: only some of an organization’s products should use the design system.
Which begs the question: which products should use the design system and which ones shouldn’t?
This is a question I’ve spent time on with every single organization I’ve consulted with.
A design system prioritization matrix
Luckily, I found a handy guide a few years ago that I use every time:
This is a super useful matrix by design system consultant Nathan Curtis entitled “Must/Should/Could a Product Adopt a System?” The two axes are “Product Stage” and “Upcoming Investment,” a smart combination that juxtaposes two of the most important factors of valuable design system work.
The green “Must” and red “Avoid“ areas make obvious what many teams struggle with without a matrix like this to help them:
New products with more upcoming investment compared to the prior period must use the design system. Launching a new flagship website or app that’s gonna get a lot of executive and/or marketing attention? Use the design system for sure.
Legacy products with no upcoming investment compared to the prior period should avoid using the design system. That old Lotus Notes-based application approaching end-of-life in 2 years? Don’t bother migrating that over.
The “Should“ and “Could” areas get trickier, so spend more time here. An emerging product with less upcoming investment? Hmm. It should probably use the design system, but it’s worth a few conversations to make sure. An established product with the same investment as last quarter? It could use the design system, but it’s worth considering if there are higher priority places to spend your time.
