Creating a Great Design and Research Culture

I led a conversation recently at Web 2.0 Expo about creating a great design and research culture at your startup. To be clear, I didn’t offer to run it because I’m an expert, but it’s a topic I’m extremely interested in. I wanted to find out from other people what their problems have been and see if we could help each other solve those problems.

The most interesting thing to me was how similar many of the problems were, which leads me to hypothesize that too many companies are making the same mistakes over and over when trying to integrate design and research into their organizations.

Here are a few of the common complaints I heard and some of the solutions that were proposed.

Keeping Design in a Silo

The most common problem was bad communication between the design team and other teams within the company. One participant said that, in her company, the visual designers were on another floor from the UX designers, and the designs didn’t always translate correctly.

Another participant talked about a company where the engineers, designers, and strategy people were all in different countries. The cultural differences between the different teams led to even more communication problems.

Solution: Our proposed solution to this problem was to blend teams whenever possible. A participant told us that, when they embedded designers with the engineers all sorts of good things happened. Not only did communication improve because they were all sitting together, but they actually became friends, which made them all more willing to listen to different points of view.

Doing Research but Not Acting on Results

Another common complaint was that companies would claim to be “user focused” because they did a lot of user research, but they wouldn’t actually act on the research.

In a couple of cases, participants talked about an overall company culture that was resistant to actually making changes based on the research. The upper management was simply going to build whatever they wanted to build regardless of what the users were experiencing.

In another instance, the problem was that, by hearing the same problems over and over each week, people at the company actually became accustomed to those user problems. The problems seemed less urgent because they’d been hearing about them for so long.

Solution: There were a couple of proposed solutions to this problem. To get the team to truly understand the urgency of the customer problems and to get buy in from upper management, people suggested sharing videos of actual users failing to use the product. Nothing motivates change like seeing somebody struggle with something you think is easy!

Also, to prevent problems from becoming accepted parts of the product, I often suggest running small tests for specific problems with the idea that the team will immediately attempt to fix the problem and then test again to make sure that it was improved. This test->fix->test cycle can then be repeated until the problem goes away and a new one is discovered.

Getting Key Stakeholder Feedback Too Late

One participant shared a common problem that the legal team would come in at the very end of the process and jam a bunch of fine print into the design. In my experience, this can be a problem with any high level, external stake holder who doesn’t come into the process until after the design is almost finished.

Solution: One participant said he’d had good luck hiring a different legal team that was more specialized to his particular product and industry. However, this won’t work as well if it’s the CEO who is diving in at the end of the process and making changes.

The group generally agreed that it was important to get key stakeholders involved much earlier in the process. Janice Fraser, of LUXr, had an excellent suggestion to show stakeholders very early sketches and ask questions like, “What about this looks like it might be scary?”

The Magical Designer

There was one participant with what I hope is an unusual problem. He claimed that his designer thought that he could do no wrong. Despite being at a startup, he would throw fits and hold up production over single pixel changes.

Solution: Look, I know that at least one person is going to tell me that that sort of thing matters deeply and that at Apple things have to be pixel perfect and the designer rules everything and blah blah blah.

Startups can’t work that way. A one pixel difference is not what causes your startup to succeed or fail, so it shouldn’t be what’s determining shipping your product. My recommendation was to fire the designer and hire somebody who understands the concept of ROI.

The Perfect Culture

Ok, will solving all these problems give you an awesome design and research culture at your company. Probably not. But hopefully this can help you avoid some of the most common problems.

Like the post? Follow me on Twitter!