I was recently asked in an interview if I felt that my previous company was "Design-centric." Without a moment's hesitation, I answered "Not at all," which wasn't a knock against the company. In fact, I'd go so far as to say that if your company is Design-centric, you're focusing on the wrong thing.

That may seem like a strange thing for a designer to say, but I genuinely believe it. This may not be the position that I've always held, it is a position that I've arrived at after spending a significant amount of time working on software in the context of a biotech company. Design just isn't the most important thing to orient a company around. Ultimately, it's not what any company's customers are buying.

This is a good time to pause and break down what "Design-centric" means. It's likely one of those terms that will elicit different definitions from different people, but in my experience, it means that a company and its priorities are configured in such a way as to allow designers to determine how they work and that there are certain accommodations to the importance of design work. Some might argue that this means doing things like user or customer research as part of the process. I certainly grant that this is an important activity to engage in, but the words are important. It's "Design" and Designers at the center that I take issue with. Designers aren't the only ones able to gather customer feedback (e.g., go talk to the sales team), so why wouldn't you want a "Market research-centric" company? That might make sense in an agency context, though I'd suggest that it would be severely limiting for any organization.

Another term that I've been hearing a lot—particularly from product folks and CEOs—is "Product-centric" or "Product-lead" company. I'll be honest and say that I wasn't quite sure what that term meant when I first heard it. It seemed like a code for a certain type of company. From what I can gather, these terms generally mean a company with software product(s) at the core of the company. In this way, the product(s) themselves drive company strategy and direction. Experiences outside the confines of this product are generally looked at as secondary or ancillary.

You don't need to be clairvoyant to see where I'm going with this: why should the Product be at the center? What happens if the Product no longer serves the people that it was created for? What if the people that the Product is created for have significant context outside the confines of the interface and don't share that same viewpoint? If just making more of the Product is the end-all, be-all, then what gets people up in the morning? In many ways, this sounds a bit like the tail wagging the dog and if we've learned anything as designers, it's that you can't lead with the solution.

Keeping people at the center

I'd put forward another model. One where the company, its products, services, and structures are oriented around the humans that you're creating for and how you're solving problems for them. I've seen this orientation as a strong driver for innovation and experimentation. I've seen this act as a built-in North Star for a company that can remain consistent despite individual product or feature failures. Markets and attitudes may change, but staying rooted in people's problems and your organization's unique value proposition to solve those problems creates a more durable approach that will weather those changes.

In this context, Design as a function and designers can deliver unique value. We are experts in understanding our customers (those humans whose problems we're solving), and modeling different possible ways to meet their needs. It also positions designers as true partners across the organization and changes the conversation. We no longer have to say things like, "We are Designers, so we need to be a part of this process so we can do Designer-y things," and instead say, "We can help you understand our customers and what they need. We can also help you figure out what we can build to better meet those needs." Lastly, it creates natural connections to other functions that have close customer interactions, such as Sales and Customer Support.

There is the potential for this approach to go sideways, and I've definitely seen it. Chief among the pitfalls are Shiny Object Syndrome, where leaders will shift priorities to new opportunities to deliver value to customers before giving other channels a reasonable chance to succeed. After all, software isn't easy and sometimes it takes time to truly deliver value in a way that resonates with customers, not to mention the contextual whiplash that may occur to teams across the organization. A human-centric structure may also lead to an organization that has competing priorities within the same channel of execution. As with many issues, the way through some of these challenges is through strong leadership and ruthless prioritization. If the teams are able to stay focused on the human impact and have access to the context of strong leadership, the benefits outweigh potential issues.

I hope that this is something that you'll consider as you're designing the structure of your team, group, or company. That you think about your organization, how it determines its focus, and whether it's driven by a function, a solution, or the people that it serves.


What do you think? Do I have it totally wrong? Did I miss something big? I'd love to hear from you, so drop me a line on Twitter or LinkedIn and let's continue the conversation.