The Insanity of Design Specs
I know — I’ve done this, and it makes me a little crazy. You can do insanely detailed design specifications in the smallest pixel unit possible, defining all that little spaces between text, buttons, boxes and whatnots, so to say, you can help the guys who develop the app better, and that the brand or app or the digital product can have a more consistent and coherent execution later on. When you move on, you’ll leave some sort of a legacy.
I have no objections to these detailed design specs. The question is, how detailed?
Should I use pixels? Pixels are rather dead, because screens are various and we need to cater for responsiveness, or whatever.
Should I define all screens, or just per component? It’s way crazy to define all screens, that’s not a systematic way to work. However, some engineers do ask for it. I don’t know why.
Should I enforce them religiously, or should I cater for some flexibility? Because, you know, you deal with people, and the product is a living product. It never for the good of God be still and set in stone forever like that.
Even if you use exact pixels, ems, percentages… people will deviate. That’s one thing for sure. There’s no use in enforcing it religiously, then. By the end of it all, in big projects, people don’t have time to go through the goddamn documentation. We’re always in a rush.
In the past, I’ve always done just enough spec, which means I try to negotiate the major components that I need to spec, maybe a little component mapping on key screens. They can go detailed in pixels or percentages, but I don’t want to be lofty and say the magic word: “deviate from this, and you’ll be stoned to death.” I try to treat my spec as a suggestion rather than rules.
Design specs must be agile and evolving. They are never set in stone. If the team cannot treat it like that, for various reasons, then the way they work is not good enough.
I’ve worked in small companies and big corporations. The small companies tend to not have design specs and do a one-time design and evolve from there. This is in one-way good. Just build the components and reuse them as they see fit. No documentation, or just little documentation. The big corporations tend to be scared. They put a lot of money into a project and they want a scalable, governing design guideline. They hire someone in-house or outsource the assignment to an agency, then after all that months of sweat and pain, they finally have a design language system and whatnots.
Totally fine for both. The thing to worry is about how we all execute them later.
The small companies are agile, thus they have the advantage of having flexibility to implement their design guideline. The “get shit done” attitude makes it all better, but the presence of a designer to be a gatekeeper is also prominently needed so the design still makes sense even after “deviations”.
The big corporations are slow & lazy. They would cherish the design spec in the first few months. Everything seems to be working well. However, by the end of it, they’re going to ditch the design language system and hire a new agency to do another one because they feel the fault is within the documentation, or the design is outdated. Or, it can be simply a problem of operating in silos: different teams work differently in their own interest of time and resources. Politics.
Enforcing agile design specs sounds like more probably done in small companies and startups, but it can be in big corporations, only if the management realizes how important being agile is, and agility should not be part of just the design team, but of the whole process and various teams.