Organising Chaos

Design Principles and Scaling Up a Design Team

A design team working together on a project is a relatively easy job. Once you start scaling up and taking designers out, assigning them to different projects and assignments, it can easily get messy. Every designer scrambles to meet deadlines, accommodate revisions and client requests, solving problems solo.

We have discussed at length about design principles in the Ingenuity Design Team ever since we had a Design Team — a set of guidelines set in stone that would make project setups a breeze, client communications fluid, every design review efficient.

Although we didn’t work in a wild, lawless, wilderness where we just designed whatever we wanted, there were also no clear rules.. We had guidelines and standards everywhere. It was a biased mental rulebook that was lenient and pliable to the whims and wills of the designer or the client. For a time, it worked.

A Golden Standard

As the team grew and as more projects came in, the designers had to work on different design problems that require different ways of thinking — different tools, different tech, different processes. Everyone had their own assumptions and biases as to what these problems needed and how these solutions need to be designed.

The designers dealt with the problems alone, realigning with the team to keep everyone updated on design decisions being made. Is it alright if we have these table headers aligned this way?

We have designed and delivered great products. Each of them have satisfied our customers. But most of the key decisions that we have made for these projects stay with them. We needed to distill what makes Ingenuity Design great — what makes it work?

We needed a standard that kept everyone in check whichever product they were designing.

We knew our rules won’t be handed down to us in stone tablets so that we could follow them and have everything laid out for us in a yellow brick road to team efficiency. We had to do it ourselves.

We tried starting off with rules on how to design things — a rigid set of rules on how to pair up typeface, how to design buttons, what color to use for secondary buttons vs CTAs, basically a gold standard for everything that we will follow to the pixel. It was becoming a faceless documentation of strictures and internal legalese that only solved part of our problem — of which we had several.

Go Big

We needed principles that would help us decide rather than decide for us. These principles should work on any project — from simple logo designs to entire enterprise systems.

The team got together and discussed what we think are the best practices and principles that we uphold as a design team, a standard that they believe embodied our ideals. We had a few rules in place for what our principles should be:

1. They have to be observable — we can’t have principles that are vague and too abstract. We should be able to pin down these principles with tangible, quantifiable, observable features and qualities.
2. They can’t be infallible — the purpose of these principles is to help us manage feedback and help us decide. An infallible principle that is always correct will be of no help (e.g. you can’t argue with products being user-friendly).
3. They have to work in any context — they have to work in a variety of settings, projects, and problems. From branding and identity projects to web and mobile app experiences, these principles should be inclusive and should stand regardless.

In just a few minutes, we had about thirty words in front of us. We deliberated through each one, letting each designer talk about each principle and how they applied in everything that we do. We cut down a few, brought together some, and finally came to four words that distilled our principles as a design team.

1. Functional — Every piece counts. Each element has to serve its intended purpose. It could be buttons, microcopy, images, or just the way we write headlines — each element should be doing its job, everything should be there for a reason.
2. Understanding — Design should empathize. Every team has their biases. We ask questions usually asked by an engineering team — tech specifications, project schedules, deliverables, etc. We need to ask questions that aim to understand our user’s problems better. Decisions should be informed by what our users and our audience need — it should be inclusive and accessible and not just because clients suddenly wanted it that way.
3. Simple — Brevity. Be concise. Words and elements in the product should be brought down to its simplest. Without compromising delight or hampering imagination, a product’s design should feel natural — as if it has evolved this way and has shed off all its unnecessary frills.
4. Emotional — Bring delight. An application could give the user either delight or frustration. We have to strive towards giving users experiences that give them joy, or confidence. Efficient interfaces, insightful messages, confident copy — let applications talk users and reassure them.

Of course these principles will not be permanent. They will be fluid and adaptive, we will add to them if need be, bolster their use if necessary. Most importantly, these principles have to be used and tested.

We run a few trials with it already, working on design process overhauls internally and testing out our ideas against the four principles we now have. It is a welcome exercise, making decision making efficient and managing feedback a lot easier.

Conclusion

There is plenty of work to be done. Additional details and guidelines will be drafted to make these principles more robust. And of course, these principles need to be relayed to devs and execs as well — keeping everyone in sync on how we do things.

Get your team together and try to get them work on your principles as well. An open dialogue that lets everyone collaborate on the core principles that guide how you do everything — from internal processes to product development, will be helpful to any organisation. It lets you understand how people work and what they believe in and it makes your team better at understanding problems, and more efficient in solving them.