In a round-table at the New Relic headquarters in July 2013, four successful tech companies discussed the rising opportunities for developer-led startups under the banner “Developer is King.” At least, that was the slogan on the coffee mugs being handed out to attendees.
The discussion was led by Google developer advocate Don Dodge, GitHub co-founder and CEO Tom Preston-Werner, Mixpanel co-founder and CEO Suhail Doshi, New Relic founder and CEO Lew Cirne, and Stripe co-founder and president John Collison. It focused on the how the time of the software developer is now.
These kinds of high profile conversations have an influence on everyone looking for answers to digital product design challenges. In the politicized world of digital marketing agencies, for example, it questions the established production process of starting with business strategy and UX, sending a solution to visual design and giving it over to developers to build.
The discussion gives frustrated developers permission to rock this rather staid boat. Considering the level of intelligence, technological knowledge, and problem-solving abilities of any developer worth their salt, why would you not want them in the room from day one? Digital product design is complex and multi-disciplinary approaches are likely to have the best chance of finding a solution.
Tribal Battles Won’t Win the War
So with that in mind, does “developer-led” just continue a bygone debate about who gets to be the top dog? Is starting with developers and layering business insight and interaction design on later any better? And, if so, how does user insight feature when the technology leads? For New Relic founder Lew Cirne, this appears to mean cutting out any up-front customer intelligence. He has been quoted as saying “What worked for me, anyway, flies in the face of conventional wisdom. I don’t research markets or look at IDC reports. I try to solve a problem I have. If I have it other people do too.”
On the other side of the debate, Danny Bluestone, Managing Director at Cyber-Duck, has recently vocalized concerns about the exclusion of user research. “What we are seeing evidently in today’s age of the lean start-ups and agile development are both start-ups and corporate organizations blowing the minimal viable product (MVP) trumpet with a view to build, measure, and learn. While there is nothing wrong with MVPs and the lean concepts … some organizations may skip a human-orientated research process, which would result in an inferior user experience.”
In the instance of products being developed by developers for developers, it’s understandable why the product development process may not be stacked with upfront user research. Although its always a good idea to refer to the old adage that sometimes you need to “take the ‘you’ out of ‘user’,” the alternative is to make a reasonably educated guess, wing it, and react when the data—and, ideally qualitative insight—comes in.
[google_ad:WITHINARTICLE_1_234X60_ALL]
Fail to Prepare, Prepare to Fail (but Maybe that’s OK)
Very often user insight is used as an insurance policy, satisfying a corporate hunger for measurement. Corporate brand teams are already imagining the PR disasters and brand degradation if a new product is badly received, so they do everything they can upfront to ensure that failure never happens. But we know that risk-averse attitudes can also kill innovation. And with innovation being the ultimate aspiration for most digital products, failure is the new black.
With innovation being the ultimate aspiration for most digital products, failure is the new black
Enter popular events such as Failcon, founded in 2009. It advertises itself as “a conference for technology entrepreneurs, investors, developers, and designers to study their own and others’ failures and prepare for success.” In the same vein, open science ventures such as Research Gate work under the banner of “Make your research visible,” which means that they also encourage their members to share their failed experiments in the name of scientific discovery.
Just try something, see how users react and change it if the response is negative. Is this is the quickest, surest route to innovation? If you have a corporate culture to support near-instant change and the resources to respond rapidly, what’s the difference as long as users get what they want and the mistake is not so gargantuan that you have prevented them from ever coming back to benefit from the improvements?
The Curveball
Unfortunately, sometimes a research-free approach isn’t even going to get you out of the starting blocks. What happens when you are building for a user outside of your group or culture? Let’s assume you are building a platform for microbiologists living in China, and you are a developer living in New York? It would be foolishly arrogant to assume that simply because you find something useful and exciting, a user with a different set of problems and a different understanding of technology will find it useful too.
The UX problem still exists: you have to start with user insight to frame the problem before you can even start on the solution. And unless you are talking to someone with enough funding to take large risks, how can you expect any investor to back an idea with no business case? A solid business case is often built on insight about customers, not just the reputation of your development team or technology.
There is nothing more liberating than the idea that the people who build a product can be the ones in charge of its destiny. But in order to create a useful, exciting product you still need to empathize with the people whose problems you are planning to solve and build what is needed, not just what can be built.
Can UXers work with a developer-led project to make sure that users don’t get a raw deal, or will we be facing restrictive problems similar to a business-led solution based on aversion to risk? Will we, yet again, simply be mistaken for interaction designers trying to make flawed ideas work?
Empower Innovators, Don’t Block Them
In order to do what we do, a UXer has to have a decent understanding of every part of the design process, from strategy through to build. In addition to often being the seed that germinates the entire project, we are also supposed to deal in empathy, so the more we can understand about different ways of thinking, the better. Surely we are unlikely to begrudge any other discipline in embracing the same polymath approach? So if we can’t lead a product, or sit as an equal collaborator, lets tool up the people who are running the show. We can’t necessarily teach someone in an afternoon what years of experience has taught us, but I believe that we should do everything in our power to enable an innovation that could benefit a user.
Five Principles for Accommodating User Needs In Developer-Led Projects
Here are five UX principles that can empower developers to think like users:
- Learn to empathize with people you may not initially relate to. If you are struggling to empathize, or even if you aren’t, learn to ask questions and open your mind to the answers. It will be a constant source of inspiration.
- Kill ideas that hold special meaning for you if they don’t work for users. Designers are old hands at being able to kill their darlings. You are a clever person and are likely to have other good ideas, so don’t panic!
- People exist in the real world, so think about all the time they spend before they use your product and all the things they do after they put it down. Your product lives in the context of their day, and its success will be influenced by their experience before and after they use it.
- Data is user insight, but it is only quantitative. Alone it means we can see that people are doing something but we don’t know how or why. The “how” and the “why” are extremely important if you want to make real improvements. You need to keep the conversation going through qualitative research as you develop your product further.
- The visual experience transforms your product from functional to enjoyable and sometimes downright joyful. How it works can be intangible to the untrained eye. The uncomfortable truth is that most people think they know what looks good, but we know that not everyone does, or we would never have experienced an underdesigned or ugly product. If you aren’t from a design background, learn to trust someone with a proven track record who is.
Conclusion
Although I believe we need to be less risk-averse and support innovation where we can, I don’t believe you can ever allow technological aspirations to lead a successful product design process over user needs. If you are building something for your own community, you are building it on insight gained through multiple conversations with your community, which qualifies as informal user insight. When a developer doesn’t have the luxury of building something they would use every day, they need to do their homework and run as much qualitative, observational, and desk research as possible to inform the right idea. However, this doesn’t mean that a product design project can’t be developer-led, provided they are thinking like the user and asking for support from researchers and interaction designers when they need it.
Image of maple leaf courtesy Shutterstock
