Introducing a culture of design inside existing organizational cultures

How I sell design inside Enterprise orgs

I’ve spent the last 10+ years setting up design practices inside of cost centers. It’s my job to build product design teams, develop the practice of design, and integrate those teams into existing cultures within organizations where resources (headcount, money, etc.) are very limited. My experience has been inside enterprise organizations like Customer Experience (CX), R&D, and IT. I believe this background provides a very unique perspective as to how environment shapes design.

I have never been in a position where I could declare culture change is going to happen. The only person who can attempt such a change is the big boss and it ain’t easy when they try. Culture is what it is and it ain’t going away. That doesn’t mean you can’t influence and shape it though. I’d like to share some thoughts on what I’ve learned and done.

Design is still the new kid on the block

Culture is a hot topic within the design community. It has been for a while. There are countless articles, blogs, books, and workshops about developing healthy design practices and articulating the components that make up a healthy design culture. While many of these articles are relevant, smart, and helpful, they are primarily focused on the internal workings of a design team. That’s one half of the equation. The other half is selling design to colleagues and peers on other teams.

The job scenario I’ve encountered time and time again is incorporating design into existing organizational cultures. Existing, long-in-the-tooth, and sometimes Crab mentality (“if I can’t have it, neither can you”) cultures. Integrating a successful design practice would be much easier if everyone cared about design, but not everyone does. It would be much easier if design was everyone’s responsibility, but it’s usually not.

Products can be made without design teams. Products can not be made without engineering and development teams. Compared to the other functions within the software lifecycle (architecture, engineering, development, project management, etc.), design is still the new kid on the block. It’s been my responsibility to introduce a new level of design standards, develop people, and incorporate good practices into an established process. I won’t beat around the bush. This shit is hard.

What I’ve learned

With that in mind, here are a few things I’ve found helpful for the other half of the equation; fitting design in with existing organizational cultures.

1. Embrace the cultures around you

The tech industry still does not know how to incorporate design into existing product, development, QA, and UAT processes. Culture is a manifestation of process. It’s on us, as designers and design leaders, to do a better job of articulating how design should fit into organizations and greater processes. I spend a lot of my time understanding the work of my peers. I aim to understand how they work and ensure my team is providing design assets in formats that fit their workflows.

  • Understand how other people work. Do you know how QA teams work? What the UAT process is? Are your Dev teams filling design gaps by guessing what interactions should take place? Often, members of those teams are developing and testing around task-based flows because users will be encountering the same tasks.
  • Create understandable outputs. When providing design assets, the design team is providing them in a format understood by our counterparts. Here’s a storyboard format with specific screens of task-based flows.
Storyboards are great for task-based documentation
  • Show clarity of intent. QA teams are testing for bugs. If they do not know an interaction is intentional, they’ll assume it’s a bug. Providing task-based flows allow teams testing a product to validate whether or not an application state is intended. When clarity of intent is understood up front, it reduces the amount of bugs created. It also reduces the amount of re-work design teams often do.

2. Sell something else

My biggest takeaway from the last 10+ years? I sell design, but there are few colleagues buying design. Most are buying something else. I’m always adapting my approach.

I’ve spent countless minutes, hours, days, weeks, months, and years selling design. The need for it. The power of it. The risks of not haven’t it. While many colleagues, leaders, and peers have agreed with my selling points, no one has bought design for design’s sake. What they are buying are increased revenue, cost reductions, time savings, and user adoption.

Here’s an example of what I mean. Design systems are a valuable tool in providing holistic color, tone, layout, patterns, and brand across a portfolio of products. Here’s how I sell the value of having a design system:

  • Sell the merits of saving development time to Engineering and Development teams by using a design system. If it saves them time, they’ll use it.
Super awesome “Time is Pain” graphic created by friends Little Thunder Co.
  • Sell the merits of reducing costs to our Leadership by reusing existing resources (headcount, markup, designs). If it saves them money, they’ll require teams to use it.
  • Sell the merits of user adoption to Product teams. After providing time and cost savings, showcase user adoption based on research and data. If users are adopting the design, we’ll save more time and money in additional development.

Figure out how to sell increased revenue, cost reductions, time savings, and user adoption, or whatever other derivative they’re buying and include your best design practices and processes into those. Don’t know where to start? Start with the past. Investigate and understand what is and isn’t working, and know what your peers are buying.

3. Practice what you preach

I like to leverage known design practices and use them as a means to solving “other” problems. For the most part, I act as facilitator to the events, meetings, workshops, etc. and invite others to join me.

  • Offer a crash course introducing fundamentals of design. This has been SO valuable for me. A couple years ago, I began offering a crash course teaching the fundamentals of design process, problem solving, prototyping, etc. I invite EVERYONE in the office to attend, buy pizza for lunch, and limit the seats to 12 people. I’ve always had full attendance and have had to book more than one crash course due to popularity. I run this course multiple times a year.
  • Organize and run hackathons. Colleagues love making things. If I provide attendees with some structure and time, wonderful things happen. Hackathons have had quite a positive side effect as well. They introduce a format that is not too different from a Design Sprint. Many attendees have asked me how they can incorporate hackathons into their daily work. I always offer to facilitate a Design Sprint. Which gets me to…
  • Facilitate workshops. When you’re a designer, people want your feedback. All the time. Instead of providing random, water cooler feedback, I offer my services in providing a one-day workshop. If I can convince colleagues to get into a room with me, facilitate structured activities of problem solving, they’re much more likely to ask for help earlier and more often. I am fortunate I can offer such time and am supported in doing so. I also ask for that support prior to taking any job.
  • Start a speaker series. I’ve been fortunate enough to speak often and be part of the larger design community over the last few years. Being involved in the larger design community also means I see and hear a lot of amazing stuff. When someone shares amazing things, I thank them and invite them to speak (Thanks Uday!) at my office. I invite EVERYONE to attend. I’ve never had a problem filling the room.
  • Start a design critique and feedback meeting. I’ve invited all designers, regardless of what team they’re on, to attend a bi-weekly critique and feedback session. Designers spend a lot of time getting feedback like, “Why did you make it that shade of blue?” By providing a safe space for critique, designers are able to 1. practice their presentations and 2. prepare answers for questions that might come. Want to know how to run these meetings? My friend Verne Ho and his article, Fresh Eyes & Design Talks is the perfect starting point.

4. Accept things won’t change

“If only he wasn’t here, then things would be perfect.”

“Why are they doing that? They’re idiots!”

“If only they listened to me, we wouldn’t be in this situation.”

How often have you said something like this? How often do you hear something like this? There is an urge to make statements like this ALL THE TIME and it’s takes a tremendous amount of effort not to do so. Instead of fighting things out of my control, I ask myself a simple question:

If I accept that nothing will change, what will I do to be successful?

By asking this question, I am able to treat frustrations as design challenges. I am able to understand what is and isn’t a real constraint. I am able to keep my sanity when PEOPLE CONTINUE DOING THAT!!!

5. Go for a walk

No doubt, there will be moments you’re on the brink. Get up, shut up, and go for a walk. I have never been able to successfully sell design or integrate design culture in those moments. Go for a walk (it’s beautiful outside!), take a breath, and come back refreshed.

If you make good things, you’ll influence culture

If you make good things, people will come. They won’t argue with your process. They won’t think you’re trying to change them. They’ll want to make good things with you. If culture is a manifestation of process, influencing the process of making good things, through design, will influence culture.

Ray, people will come Ray. They’ll come to Iowa for reasons they can’t even fathom. They’ll turn up your driveway not knowing for sure why they’re doing it.
— Terence Mann, Field of Dreams

Design has become mainstream, or at least talking about design has. As a result, design is showing up in companies/teams/organizations where it has not traditionally played a role. As design continues to become more relevant, perhaps it’s inside these organizations where design can further establish itself as a fundamental partner to well known practices of development, engineering, quality assurance and testing. Environments where design culture can influence organizational culture. So far, it’s been working for me.