Five ways to tell if a company is really Design-driven

TL;DR — Design representation in leadership, consideration as a stakeholder in projects, team processes, and design team feedback.

A quick gut-check for companies, and potential employees.

Over the past dozen years, or so tech companies started touting in interviews and jobs postings about how “design-driven” they are, and how they deeply value design. It’s a compelling thought for designers — getting to work at a place where design is at or near the top of the totem pole — and makes for very effective recruiting for the creative people who are idealistic, or who have experienced teams that don’t especially value their work. The problem is that it rarely ends up being true, and there are a few simple questions you can ask yourself as a barometer for how much an organization values design.

Is design represented in leadership?

Most tech companies talk the design-first talk, but in reality, aren’t concerned with walking the walk. Sometimes it’s by necessity, but often it’s a leadership and cultural issue. Especially when you look at start-up companies with founders and leadership teams that are comprised solely of former engineers, and business people. If Design isn’t in the room when important decisions are made, it’s unlikely that user experience and ascetic concerns will be fully represented in the product roadmap. Look at Apple as an example — Jony Ive is Chief Design Officer — a C-level employee that is either involved in critical decisions directly or privy to the decisions being made for one of the worlds wealthiest companies.

Creative people are sometimes passed over for leadership opportunities, as the methods, processes, and personality quirks of being creative read to many as unfit for leadership. Artists and designers can, however, showcase a very different style of management, especially in regards to process and organization of their teams. Look at the leaders in the organization and count how many come from a design or creative background.

For leaders, take a moment to think really hard, and stack rank the parts of your organization based on which teams are driving culture and the product roadmap, and see how far down design ends up on the list. I’m not advocating that design demands to be at the top of the list, but if you find design buried under marketing, sales, engineering, operations, customer support, and others, can you really consider your company design driven?

More importantly, there are designers who are excited to help any number of those teams, but without transparency in the hiring process, you may find you’ve oversold the importance of design within your organization, and find yourself with a design team that feels undervalued and overwhelmed as they try to meet the needs of everything but design.

Is design considered a critical stakeholder in projects?

I’ve had the amazing luck to work for some of my favorite companies on some of my favorite products over the past decade, and each of the companies I’ve been at is different in their own way, save for one thing — how they weighed Design’s objectives and opinions throughout projects.

Even though the team at Apple is big — their employees measure in the tens of thousands — design was venerated. You could feel the flow of projects bounce between art, technology, and business. Each of them representing their respective goals to collaborate and deliver products and features on some of the worlds most used and influential apps and operating systems.

At Squarespace, under the leadership of Anthony Casalena and David Lee, design always had a seat at the table. The company was completely unafraid to spend time considering the difference between 95% black and 98% black. We treated the brand as one of the marquee products of the company and experimented with aesthetics that were never going to see the light of day, in order to come to the conclusions that make the company and products so elegant. Anthony was an engineer by trade but demonstrates over and over his commitment to quality design, and his trust in the process.

While I worked for those companies, Design was involved from inception to delivery of the projects that were being worked on, and next to nothing went out the door without the sign off from the designers.

Ask what projects teams have worked on that spawned from the design team, and how valued the design team is as a stakeholder in ongoing projects.

Is the design team treated like an engineering team?

Depending on the scope of projects being worked on, there is probably more than one engineer for every designer in a company, designers are almost always outnumbered by engineers, so it makes sense that a lot of places often have their design teams structure and document themselves like an engineering team. The truth is that designers can sprint plan, but Design doesn’t happen in sprints. Designers can estimate, but Design is unpredictable. Designers can pull Kanban tasks, but Design isn’t a linear process. Designers can ship, but Design is never finished.

It might be convenient for organizational or political reasons, but asking a team of designers to adapt their work to a foreign process usually results in compromises. From the engineering perspective, design can look messy. Projects can start and restart, entire solutions explored and thrown away, inspiration coming in waves rather than steady streams.

Almost all of the places I’ve been that were inflexible in terms of processes have comprised design output in one way or another. They ask designers to make something great, but make sure it fits neatly within a development sprint. It’s a joke. Asking designers to Fibonacci point estimate tasks is a dream. Other disciplines use tools for controlling and documenting predictable, quantifiable work. Most teams I’ve been of declare themselves Kanban or Agile in name alone. Within the team, it’s tacitly acknowledged that the process is mostly meaningless and an artifact to display progress to leadership that doesn’t understand or value the creative process. If interviewing for a team, ask about process, and why it was chosen. If you’re a leader, ask your team what’s working and what’s not about the process you’re using.

Design inspiration comes in fits and starts. It comes from talking with your customers and colleagues, exploring solutions, and collaboration. A dinner at a new restaurant, or traveling to a new country doesn’t need a point estimate but both of them can inspire the final product. Have leadership and product managers communicate business requirements and deadlines, and give creative teams room to do their job.

How great are the products?

No matter the size of an organization, you can judge it by the tools it builds and the tools it uses. Show the product to other designers, and ask them for their feedback. If you’re in an interview, ask for someone to show you or describe an internal tool they use. Design-driven companies often expect the tools that they use to be at least as beautiful and functional as the products that they create (I’ll carve out a notable exception to HR software in general, I consider most HR software a design hellscape.).

If you find something you consider sub-par, ask the team to assess it. It can be a good indication of the companies standards or the team’s standards. It’s also a good way to sort out where design sits in the organization. Was the team unable to accomplish the goal technically? Was the project delivered on a tight deadline? Are there plans to return to it and make improvements?

Internally developed tools are a good signal to employees how much a company cares about their experience, and can serve as a reflection of the nascent abilities of a team unburdened by customer expectations. If an organization lacks a taste for quality internal tools or doesn’t demonstrate quality in it’s shipped products, it’s unlikely that a single designer will be able to change that, there may be more fundamental cultural or political issues at play.

Ask the designers

It can be hard as a leader to get open and honest answers from people you manage who want you to be happy with their work. If you build relationships, harbor a culture of honesty, and demonstrate a willingness to listen to critique and discuss solutions, then the most important thing to do is simply talk with the designers about if they feel the company is design driven. It can be just as hard to get an honest and critical assessment from a team who’s looking to recruit you to join it. So candidates should listen to tone and sentiment in teams responses to questions in an interview.

Leaders, invite the designers to a discussion as a team, ask them how often they feel empowered to make decisions or explore alternatives. Ask them if they feel valued, and pay attention to the work that the team does. If you don’t typically interact with your design team, and you’re multiple levels separated from them, sitting down and having a conversation itself helps demonstrate that you care and are paying attention. If the room feels cold, make sure that the managers you trust to manage the team are asking and delivering that feedback in the most unfiltered way possible.

Even if you feel like your team needs to make progress in quality, or lacks that one rockstar designer, if you foster a good creative environment, and empower your design team to do their best work, accepting all that comes with working with creative people is a must. Word will spread and talent will come, and your with the right team in place, everyone’s work will build upon each other and create beautiful products that were previously out of reach.

Hopefully, this was a helpful way to reflect upon how your organization, or an organization you’re considering working for values design. Candidates considering investing years of your life in a company, it’s worth it to ask hard questions so you go into a situation with realistic expectations. Leaders, who are already invested, it’s worth it to support your design team through culture and influence.

Compromise and Constraint Can Still Create Something Amazing.

I often find myself lamenting at some point in a project the gap between what the original concept or vision for a thing, and the compromises and tradeoffs that that resulted in the edited down version of that said concept.

Recently, I stumbled upon something that made me examine this feeling a little closer, and it's no surprise that it came from a video game. The traditional model of game development is a waterfall process that often involves the team having to make decisions to cut features and compromise based on deadlines, technologies, and resources.

The example was  something many of you may recognize, it's the title theme to The Legend of Zelda for the original Nintendo (Famicom in Japan):

Note: careful of the volume here, the 8-bit stuff is a little loud.

Music: Title Theme Composer: Koji Kondo Playlist: Platform: NES

I had known this theme for a number of years, even if the first time I encountered it was as a child playing Super Nintendo. When I found it and gave it a listen, it sounded right in line with my expectations knowing the series history and the general limitations of the Nintendo hardware. Aside from the unique composition itself, the "bleeps" and "boops" sounded like most games from that era.

What hadn't known about was a Japan-only peripheral sold for the Famicom that played floppy disks called the "Family Computer Disk System". It essentially could play more advanced copies of games as it had more storage and ram than the original system, not entirely unlike the power difference between an Xbox One, and an Xbox One X, with the added bonus of a giant chunk of hardware in between.

In 1984, during development The Legend of Zelda had originally been intended to release for this special edition of the console, and was built with the expanded technology in mind, and since the expensive Family Computer Disk System was a relative failure in the market, Zelda had to be edited down, and rebuilt for the original Nintendo over the course of roughly two years. The game that started one of the most recognizable and successful video game franchises was a compromised version of what the developers had originally set out to do.

There's no easy way to tell the difference between the game that was designed, and the game that was released, but you can dig around the internet for different glimpses into the original Legend of Zelda. This is where I came across the theme music for original Disk System version of the game:

While similar in many ways, it's a more complex and subtle execution of the piece, and shares more similarities with the Super Nintendo and future iterations of the track than the canonical 8-bit track does. This track is what was designed, the other is what was released.

The real thing that strikes me here, is that while I prefer the original track over the one that ended up on the Nintendo and Famicom, it was the released track that is indelibly inked into the minds of a generation, it's value, however, compromised, is real and lasting, and more importantly still reads as a beautiful work 30 years on from it's original release.

I don't know if I've ever worked on something that will be great in 30 years from now, or if that's even possible given the nature of modern software/web design, only the future could do that, but this example gives me hope that even the products that feel in the moment like a package of compromises to the original vision can end up being something that people love and remember for ages.