Designing a Better Way to Work

Working in tech, Justin Rosenstein had seen smart, driven, creative people come together—and proceed to get in each other’s way. “I would watch people spend over half their day not doing engineering or design or marketing, not doing the thing they were great at or passionate about, but instead doing work about work,” sitting in meetings and sifting through emails, he says. Justin saw an opportunity for good design to add value to the world, and sketched out a new program. Now, Asana gives people a better way to coordinate their work, so they can devote more time and energy to actually doing their work. Below are a few of the insights Justin shared during his Bridge talk.

Know When to Turn Things Upside Down

Enterprise software is traditionally sold to top brass. The CIOs and IT managers who select the software, however, rarely use it, while the actual users often have little say in what they get. Justin and the folks at Asana turned the traditional model on its head: They made their product free for small teams, which allowed for easy adoption and organic growth from the bottom up. “Because [the product] was chosen by the people who were using it, they value the user experience,” Justin says. “Taking the attention to detail and love for the user experience and putting the user first, which a lot of us take for granted in the consumer world, is very novel” when it comes to enterprise software.

Foster a Product-Driven Culture

When users try out a new product, they rarely know what went into making it; they just know what it’s like to use. The company’s culture should match that user experience, Justin says: It should be driven by making the best product you can, rather than doing the best design or the best engineering. That’s not to say your designers and engineers (and everybody else) won’t be exercising their strengths. They’ll just be applying them towards a shared, company-wide goal—an amazing product—rather than in support of one particular team. “If you are on the design team, it doesn’t mean that you should fight tooth and nail to make sure the design is pixel-perfect if getting this particular thing right means we are going to delay shipping it for six months,” Justin says, since a well-designed product that exists is better for users than an ideally designed one that doesn’t.

Have a Roadmap—But Be Open to Detours

“We’ve remained remarkably faithful to our roadmap,” says Justin, “but a lot of details have changed over time, and if we had optimized too much we would have ended up optimizing for the wrong thing.” Having a roadmap is essential to knowing core goals of your software and understanding how present-day feature development might affect future decisions. Make sure to keep a balance between sticking to your goals and having the flexibility to respond to feedback and meet unanticipated product needs. And no matter what roadmap you’re navigating by, remember to put yourself in your users’ shoes (or at their keyboards). “Always go back to actual empathy,” Justin says. Ask yourselves: “Would we enjoy the experience?” If the answer is no, something has to change.