Anti-Fragile Design

I've been meaning to write the following short post for a while. It's one of those "if you could tell one thing to your younger self..." posts that I hope will help a few of you get out of your comfort zone when it comes to sharing design work.

The idea is part inspired by Antifragile, a witty book about systems that gain from disorder. An example of a "antifragile" system is almost any biological system. Systems that are "antifragile" are able to take a non-lethal amount of stress and recover stronger.


Early in my design career, the night before a deadline was always a rough one. I would stay up well into the small hours making sure that every single detail of my designs were perfect.

I was obsessed with perfectionism back then. Everything I put out had to be up to a certain standard. I was convinced that showing incomplete work – or work that I wasn't 99% happy with (100% was not possible) – was bad practice. Believe me, I was willing to work hard to avoid the embarassmant of putting out subpar work.

In those days I wasn't ready to show my work until it met my arbitrary standard of perfect. Why? The way I saw it, I was being paid to do exactly that. I was a cog in the machine that churned out great design work. This seemed like the logical way to work.

When I moved to London and started to work with startups, the reality of this fragile system I was operating on soon caught up with me. The changing force occurred because I was now a member of a team; I was a node in a web that made decisions in unity. My independant mission for perfectionism was incompatible with startup culture.

I realised that while I thought I was aiming for the right thing in doing work that I thought was impressive, I was really playing it safe. While I was hiding away in my bedroom frantically pushing pixels, I could have been testing ideas; communicating with the people that the design was intended for.

Playing it safe is the most comfortable way to work, but its where the fragility lies. Designing in private doesn't come into contact with the problem enough to be shaped by it. Any theory or idea is merely an assumption until it can be tested against reality. Until then, the idea is based on faith.

The opposite of playing it safe: designing in response to feedback, is anti-fragile. By exposing an idea or design, or piece of writing for that matter, to real-world conditions in a measured way, all of its flaws can be found and fixed in good time. Obviously, its equally as important to act in response to flaws by fixing them for the next test.

The process of validating an idea can be implemented in many ways, but the goal is to get a passable version of the design in front of (or at least scrutinised by) real users as early as possible. If the design doesn't have "users", then test it in the context it will exist in.

Iterative validation works as a selection mechanism. It discovers the bad ideas and leaves the good ideas alone. By simply exposing ideas, or theories, to the real world, making note of the negatives, and then paying attention to those areas, designs are shaped into successful products by their environment and not by whim.

Read next

Three Rules for Teaching Beginners How to Code