The secret to building better products

We hosted a DesignTalk with Oliver Dore of Work & Co on the secret to building better products. Below is the full recording and an excerpt of the talk, edited for length and clarity. Enjoy!

Oliver: For the past 4 years, I’ve been with Work & Co, most recently as a technology director. We’re a digital design and development company, and our mission is a simple one. In fact, I’d be surprised if it’s not your mission, too, in some ways. We just want to make products that people use every day — products that add value to their lives in some small way. That’s it.

Today, I want to talk about a way of working that I’ve aspired towards for many years, but only recently had the opportunity to put into practice. A way of working that I believe leads to better products and happier, more motivated teams.

To begin, I’d like to tell you a story. It may be familiar to some of you. It’s based on how many of the projects that I’ve been involved in ran in the recent past. And I should warn you: it doesn’t have a happy ending.

So it’s day one, and a new project kicks off with a stakeholder meeting. In attendance, we have a VP, a creative director, a technology director, and an account director. The purpose of this meeting is to define the strategic goals or the KPIs of the project. These business goals have been relayed to the design team. And adly, when that task is done, most of the people in this room are never seen again.

In another room, the design team kicks off. Some wireframes are produced before going into detailed design. They’re building a responsive website. The vision is strong, the typography is sharp, the grid system is on point. Each page is bespoke and individually crafted to be the best version it can be. And when they’re done, they take their Photoshop files and they put them into a folder on the server. And this team, too, is never seen again.

Next up, the engineering team comes in, and after a 10-minute PowerPoint presentation to brief them on the project, they’re sent a link to the wireframes and the Photoshop files. Development begins, and so do the questions.

• Why are there 12 shades of gray? It seems like we can probably get away with 4, but I see 12 here.
• What’s a layer comp? A developer opens the Photoshop file, looked in a folder, and found the equivalent of a week or 2 weeks’ worth of work.
• No hover states? Is this final.psd the final PSD?

Or worse — not questions, but statements. The engineers are missing this valuable background information. They don’t know why decisions are made, and they don’t have anyone to ask to fill in the blanks. So to compensate for these gaps and assumptions, they attempt to make the code base more efficient and maintainable by streamlining styles and functionalities across each view.

Finally, the QA team comes in, and their job is to ensure that the features look and work as expected. But wait! The designs and development don’t match anymore. There’s no single source of truth. Who’s to say it’s working as expected? The end result of all this is a product that reflects a dysfunction of the process. No one is to blame, but everyone is pointing fingers at each other.

That story represents many of the projects that I’ve worked on in the past, and it’s certainly not meant as a criticism of anyone I’ve worked with. Absolutely to the contrary. Everyone I’ve worked with wants their project to succeed. They want happy clients. They want to be proud of their work. They want to share it with their friends. But despite their best intention, they’re let down by the process.

If you haven’t guessed by now, this process — this model that we call waterfall — is broken. And I mean really broken. It completely negates the thousands of decisions that go into making a great product, and it creates an environment that encourages risk aversion.

How do we expect anything innovative or unique to emerge from an environment of risk aversion?

Is there a better way?

Now that I’ve ruined your day, I have a question to ask you: is there a better way? I want to challenge you to think about this question. Many of us are lucky enough to work on really interesting problems, with really smart people, but we subject ourselves to a model that basically eliminates any opportunity for you to do your best work. We owe it ourselves and those around us to solve this problem.

Now, I don’t pretend to have the answer, but I do have some ideas I’d like to share. It all starts with one team, creating one product. Sometimes it’s easy to think that your team is maybe just yourself on an island in the middle of nowhere. Or maybe it’s your immediate team, your own discipline.

But your real team is far more than that. It’s the designers. It’s your QA team. Your product managers. Strategy. It’s the folks who turn on the lights in the morning. It’s your other vendors. And most importantly, your team includes your clients.

Collaboration means a single team with a shared objective. It’s not just about individual KPIs, design goals, or engineering goals. The success of any product relies on developing a well-defined set of goals that everyone involved can get behind.

Collaboration means being hands-on. For us, it doesn’t matter if you’re junior designer, a developer, or a partner within the company. You have your hands involved in creating a product on a daily basis.

Collaboration means having dedicated teams. The teams at the start of the project are the same people who end that project. It means that the relationship with the client isn’t owned by a single person, it’s owned by the entire team.

Finally, collaboration involves hybrid roles. Your title is irrelevant. It’s whatever you can do to contribute to the product. At Work & Co, we focus on three 3 disciplines, and even within those disciplines, we have unlimited remit of the things that we focus on. What we focus on, though, we want to do to the best of our ability.

Embrace your stakeholder

A lot of companies — on purpose or by accident — keep their clients at arm’s length. We just never found that to be a good idea. It can only benefit the work if they’re involved in the decision-making process on a daily basis.

In our experience, stakeholders don’t need to be wrapped up in cotton wool. They’re not Faberge eggs. They want to roll up their sleeves and be involved. They want to help the team make decisions. And when you work in this way, all that time you used to spend preparing elaborate PowerPoint presentations you can now dedicate to incorporating real-time feedback, to concepting, prototyping, user testing, development. All the stuff that actually matters and none of the stuff that doesn’t.

The first team that I was with at Work & Co worked with the US airline Virgin America. We had a room that we had dedicated for the project. It didn’t have windows. Sometimes it didn’t smell so good. But it was what collaboration looks like — project managers and designers and developers working side by side. And the beauty of this was that our clients could come in every day, look at our work, look over our shoulders, and provide feedback. They could sit next to us. When we can, we travel to be as close to our stakeholders as possible, and we spent a lot of time here. Nothing beats face-to-face communication.

We don’t sit by discipline, we sit by project. Having conversations, asking questions, and inviting feedback every day creates this really strong team dynamic and breaks down the traditional walls between disciplines. It also teaches you to be less precious with your ideas and more open-minded to the ideas of others.

So what do dedicated teams and close communication mean in practical terms? Let me give you an example. If you look at airline sites in the US, you may notice something: They all look pretty much the same.

There are several reasons for this, but one is that they’re built on top of technology that wasn’t created to support a modern, immersive web experience. Not a lot of people know, but most airlines run their booking technology on a platform that was originally built in the 1960s. I just imagine this computer in a dusty corner somewhere made of pipes. That alone doesn’t promote innovation. It promotes the status quo.

So when we designed and developed the Virgin America website, having technology represented from the very beginning of the project allowed the design team to think about the flow in an entirely different way. We researched and prototyped and eventually executed this API-driven approach that would allow the front end of the site to be decoupled from these legacy technologies.

The result of which was launching the first responsive, single-page application for a US airline. And more importantly for Virgin’s customers, the ability to launch a faster, cleaner, and more enjoyable experience.

Likewise, when we launched the Virgin America apps, we took a similar approach. Many airlines use an off-the-shelf tool or a web view, but having technology represented at the beginning means we could extend the API work that we did and bring that same lovely experience to the iOS and Android apps. It really speaks to the brand and the values of an airline like Virgin America.

The big secret

So, if there is one secret to take from today, it should be this: there should be no secrets. Collaboration means transparency. It means bringing down the walls, sitting together, talking, disagreeing, coming to a consensus, and moving forward every single day. One team with a shared objective, knowing that success isn’t achieved by one person or one discipline getting their own way, but that the team is greater than the sum of its parts.

We spend so many hours with these people. Working this way has allowed me to enjoy coming to work every day, to create the work that I’m most proud of in my career, and truly appreciate the people that I work alongside. I want to challenge you to go and find whatever it is that makes your work and your life better. I hope these takeaways in some small way help you to do that.

Psst! This excerpt is only about ⅓ of the goodness from this DesignTalk. To learn more about how Oliver recommends collaborating remotely, advice on how to set up your teams, and the value of prototyping — watch the full recording of the DesignTalk in the video above!