There is no spoon
Reflecting on the impact of flexibility of rules and policies.
I’m finally back from my time-off and willing to rebuild some momentum to keep up the writing habit, hopefully also growing this community. During these days I got the chance to jot down on paper some improvement and side projects related to this newsletter I ought to implement during time and for which I surely want to exploit the energies I collected before they get depleted by day to day work.
I also want to welcome all the new subscribers (Ciao! 👋🏻) most of which come from a super-effective-endorsement from Letizia — who I thank a lot for her constant support — in her newsletter Alternate Takes. I hope you will find some interesting content in the following weeks and I invite you to check the links at the end of the introduction if you’d like to know a bit more about this publication.
Let’s get back to business!
Takeaways (TL:DR)
“Design the flexibility” in rulebooks and policies is quite a debatable topic. What I came to realise from my experience is that listening to people needs and focusing on the end goals is the number one priority to create policies that serve the system and not the opposite. Also, I believe that a flexible system of rules is made of antifragile items that bend and evolve to be able to accomodate new needs instead of breaking and leaving gaps that allows for shapeless “freedom”.
🍊 Welcome to the latest issue of Already, Yet – a weekly retrospective about not feeling ready, but doing things anyway.
🙋🏻♂️ If you’re a new reader, thanks for stopping by. Feel free to check out this introductory post, which explains what Already, Yet is all about.
📬 To get future issues delivered to your inbox, please subscribe with your preferred email.
Weekly retrospective
Recently, in the context of the redesign of a complex application, me and my colleague have been developing a design system.
Even though I had previous experience with developing a design system, being responsible for it is teaching me a lot about the power of such a piece of work for what concern influence and management of different people and stakeholders. I won’t be talking about the technicalities and product advantages of a design system, but rather try to look at it from the perspective of a tool for collaboration, alignment, and communication, and make an abstraction of its role to the level of just being some sort of “rulebook”.
For anybody who’s reading and is not a designer, I’m going to leave a couple links at the end in you want to know more, but knowing what a design system is shouldn’t be necessary for the comprehension of the post.
Rulebook or framework?
During my regular fanboying over Simon Sinek’s content I stumbled on this post:
Considered my past and recent experience, this comparison gave me so much to think about. A lot to think over company cultures, processes, strategy, leadership styles, and social interactions, but mostly over all those pieces of documentation that are used to guide, collect, share, sometimes enforce, sometimes discuss, the ways a group engage together into a particular context or activity.
I refer to rulebooks and frameworks, but also laws, policies, contracts, agreements, strategic documents and roadmaps and of course design systems.
Let’s consider a moment rulebooks and frameworks as entire categories for the other items, as implied from the comparison in the image. At first I was pushed into thinking to it as a negative/positive comparison, I assumed it was somewhat related to the (old but gold) boss vs leader comparison, I couldn’t help but read it like the opposition of an evil, impositive and blind behaviour against a good, inspiring and empowering manner.
But is it really like this?
Prioritise the HOW over the WHY is the real evil
My first experience with contributing to a design system was with an incredible team, that also invested a lot of time and effort in continuous improvement of processes and it was great. I learned a ton about operations, scrum and agile frameworks and experienced first hand the effort of “designing design” and tweak the way we were working together as a service design challenge to improve the efficacy of our day to day working needs.
In the end though, spending so much effort over developing foolproof processes and engagement rules ended up into being counter productive over a certain threshold. The system became too rigid. People responsible for parts of the process were more focused on blindly following and enforcing the rules and policies the team had agreed upon forgetting about which was the goal in the first place and not thinking critically about the value an exception could bring. This lead also to contrasts and debates, frustrations, and some other ugly things that happen in the rush of the last weeks of a project.
Individuals and interactions over processes and tools;
Working software over comprehensive documentation;
Customer collaboration over contract negotiation;
Responding to change over following a plan;That is, while there is value in the items on the right, we value the items on the left more.
- The agile manifesto
The agile manifesto was clear about this from the beginning of course, but it’s so easy to overlook the principles and values of agile practices and reduce them to fancy rituals and organised sprints of development.
Design the flexibility
When the project ended, during the final team retrospective, one great reminder emerged and was happily recorded from all the participants: “Design the flexibility”
At that time we learned at our expenses the drawbacks of creating a too rigid set of rules. In this little phrase were somewhat condensed all the principles of the agile manifesto (unintentionally).
At the time I remember I was thinking about this in a very mechanical way, something like “whenever you create a set of rules or processes, be sure to include rules and processes also to break or change those same policies” this was the fruit of an immature approach so aimed at controlling things that wanted to encode even exceptions into the rulebook.
After some time, I began to see it more like “whenever you create a set of rules or processes, be sure to preserve some kind of white space between them to leave room for exceptions and workarounds” this is culturally a very common approach to problem solving in Italy, is part of our mindset to work out a strategy around the gaps that are left between a rule and the other, it’s partially the reason why we are famous for inventors, and organised crime. This approach expects from you to be highly flexible, but still involves a rigid set of rules to create the “territory”.
A flexible system is made of antifragile rules
With my latest experience, I’m beginning to understand what it means to implement bendable rules and include flexibility directly into the system. It is more about seeing rules as tools and means to an end goal. Their role is to influence people, facilitate decision making, and put constrains that enforce creative solutions, not mere mechanical executions. Rules should be flexible to the degree that everybody is aware that they will never get in the way of creating value and reach goals, but they are strong enough that should stimulate critical thinking to find solution that can fit into them. Actually, what I understood, is that flexibility at a system level is achieved through antifragility at a rule level. “Antifragility” is defined in this way:
Antifragility is beyond resilience or robustness. The resilient resists shocks and stays the same; the antifragile gets better.
So my conclusion during the development of the design system is that a flexible ruleset/process, works in this way: It is a set of elastic, closed boundaries, it is subject to forces from the inside (the elements of the system and their interactions) and outside (goals and policy makers). Whenever the pressure is weak, the elasticity leaves enough space to move but forces these element to adapt by keeping its shape. When the pressure is to strong to resist, whenever there’s the need to break a rule, the rule bends to accomodate the current need instead, reorganising the system and adapting to become something better, able to set a new equilibrium.
Design systems should be more more than design tools…
… but rather a flexible compromise between a rulebook and a framework. If you look at some of the biggest companies with the most mature design system teams, you often find articles and talks that shows a continuous back and forth between product teams and the design system team.
Developing a design system is an act of service for the people who are going to use it. Instead of rule-makers we should feel more like facilitators. Exactly as for other kinds of rulebooks/framework/policy documentation, design system are first and foremost a tool of alignment and communication.
I’ll share the advantages I’m learning from this last experience, from the perspective of influencing different stakeholders relationships.
The benefits of the “rulebook” to guide others
Of course the design library allows us designers to work with “lego blocks”, reusable and standardised components that makes design work really fast. It’s the obvious advantage of a design library. By telling us what to do (use) in each situation, it removes the burden of repeated, useless decision making on details that are set once and for all and redirects energies towards more important and strategic discussions.
A design system doesn’t only spare time on building design. It makes also collaboration more efficient. It was incredible to see how fast designers from another organisation were able to jump onboard and start designing consistently from day one. It also reduces the need for alignment meetings, it is very easy with a couple of moments a week and asynchronous comments to keep going forward with the designs. This is also reinforced by the fact that design system documentation gives a shared language to anybody, and forces discussions on the structure and the way of working, forcing the team on being explicit on the way we engage each other.
Another advantage is the creative boost given by having fixed constraints. Anytime we find ourselves reinventing new stuff for a particular solution, we stop and ask questions:
Is there already a component in the library that can be used to achieve the same result?
This use of a component doesn’t follow the guidelines. Can we use something else or is this the solution for this screen?
Can I make it different?
If I leave it like this and change the component and/or its behaviour, what’s the impact on other contexts where we already used it?
and so many other questions. Most of the time this process results in the design being better, more consistent, more rational and removes any element in excess. Some other times we end up changing the design system instead, bending an antifragile rule, and since the components are shared overall the entire design, we end up refine and improve parts of the work that were considered done.
Giving the ownership of the design system to my younger, junior colleague was the best choice related to this project. He is passionate about UI, talented and very fast in the use of the tool. Being in a center position, developing parts of the design that everybody else uses, forces him to interact, discuss, and makes impossible for him to be and feel isolated. His curiosity and willingness to learn makes him also the perfect individual in the team to bring an attitude of flexibility and service instead that one of imposition and command. By going through all the elements of a UI one by one, having to rationalise them, and discuss solutions with other designers, he’s learning a ton and developing a strong overall view of of UI and interaction design pattern and best practices that he will reuse in future projects. Developing the system, component after component, is a very well paced task with frequent feedbacks, that keeps him motivated. Delegate this part of the development creates a lot of opportunities for me to mentor him and lets us both grow in the process, everybody wins.
In the collaboration with developers, the design system forces discussions on the structure of the product and components. It suggests a sustainable way of development thanks to standardisation and reuse, that is true for designers as well as for developers, and provide a common ground for discuss, iterate and make everyone needs explicit.
Last, it is a strong tool in decision making, providing an external authority during discussions. Whenever a stakeholder intervene by proposing a solution instead of providing a need, it is much more easier to disagree and delay the decision because by making it a problem of consistency with the existing system, it makes the disagreement much less personal. It removes friction, it put’s everyone on the same page and reduce waste and costs of development is an easy argument to make on which anybody agrees. Fortunately we also have to deal with stakeholders with some design maturity that value consistency.
Flexible systems are made of people
In the end, what I’m learning is that creating a set of rules and reusable resources for a particular group of people in a particular context can be successful in being flexible. And at the end of this post I feel the urge to take a step further in my interpretation of “design the flexibility”.
Individuals and interactions over processes and tools […]
The flexibility resides in the people, in listening to them and their needs with a serving attitude, never forgetting that the rules are made to facilitate discussions, decision making and all sorts of interactions between those same people. Whenever we stop listening to their needs and we put the integrity of the rules before our values and goals, the system will start to crumble.
Extra: design systems 101
For those (if any) who struggled to understand what I was referring to whenever I was talking about design systems, components, design libraries, patterns and similar here a couple of famous examples:
and a couple of resources to read as an introduction:
lastly, for the most curious ones, here’s an entire book about them:
It’s good to be back at writing, I hope to be able to use the energies collected to improve the quality of the content. As always, I’m glad to hear feedback if you have any.
If you liked this post and you think some of your friends would like it as well, please share it with whoever you like.
Thanks for reading to the finish and see you next week!
Tobia