May 1, 2014
Designing a Beautiful REST+JSON API
Designing a clean and intuitive REST + JSON API is no small feat. You have to worry about resources, pagination, query parameters, reference...
I recently attended a great workshop at DesignMap called “Maximize the Value of Design in Your Organization.” Rather than present some fancy new design thinking methodology, it focused on culture and how the relationship between business leaders and designers can hold designers back from being successful.
Most developer tools companies recognize the importance of good product design, but many struggle with the question of when to bring on a designer and how to make them successful.
From my experience as a founder and roles as engineer and PM at companies led by engineers, I think there are a a few key actions that can make a huge difference in the value a company gets out of adding product design to the team.
Since the word ‘design’ is thrown around so much in so many ways, I want to clarify that I am referring to product design. This is, as Paul Adams puts it, “solving problems for people within the constraints of a specific business,” rather than “practicing digital art” for fans on Dribbble.
If you can do these five things, you will be laying down fertile soil for design innovation to flourish.
As Google clearly demonstrated through Project Aristotle, psychological safety, the degree to which team members feel safe to fail, is a key element of any successful team. This is especially critical in product design, because successful design innovation requires constant public failure. If your environment is not a safe place to fail, then it is not a safe place to experiment.
The safer your designer feels to expose their process, prototypes, and unfinished work, the faster they will learn and the better the outcome will be.
Engineering cultures can be particularly unwelcoming to a designer’s public experimentation for two reasons. First, much of the engineering process can be done solo and exposed to code linters, unit tests, load test and integration tests before being exposed to the team, so there is not nearly as much need for public failure. Designers need to expose their work to humans, which means more public exposure to failure. Second, a designer is more likely to feel their credibility is at risk, since the prevailing model of credibility in an engineering culture is technical prowess. If a designer’s skill-set is not respected by the team in a public way, they will be less willing to put their credibility on the line by exposing themselves to failure.
On the other hand, we can look to engineering culture for practices that emphasize the positive outcome of learning from failure. The blameless postmortems that have become a foundation of the Site Reliability Engineering practice pioneered by Google have transformed even failures with real business costs into learning experiences that avoid shaming anyone. If you adopt approaches like this one more widely, publicly recognize your designer(s) for their unique skills and contribution, and as Tim Brown, CEO of IDEO, advises in Change By Design (CBD), “allow time, space and budget to make mistakes”, you will be on your way to creating the safety required to support design innovation.
Most engineering education and work is focused on convergent and analytical thinking, while design requires periods of divergent thinking and synthesis to discover patterns in a sea of information. As Tim Brown (CBD) warns, “it can be messy” and “people from more methodical backgrounds may fear that the risks are too high.”
As engineers we are used to planning out our work clearly in advance. Even if you’re working in an agile-like way, the specific work to be done is specified at the start of the sprint. As a startup leader, you probably already feel that there is more than enough uncertainty to go around. For these reasons, it’s understandable to have discomfort with the divergent, chaotic nature of a typical design process. You may find yourself asking: “What if this is just a waste of time?” or “How can I tell sales/marketing/customers when they will get the feature they are asking for?”
The point to remember is that methodical, predictable work leads to merely incremental gains, and as a startup you’re shooting for much more than that. So do as the sage Tim Brown (CBD) advises: put on your integrative thinking cap and hold these opposing forces in tension. Remember that management requires stability, efficiency and predictability, and design requires spontaneity, serendipity and experimentation. Both sets of needs are legitimate.
If a little dose of empathy will help you do this, take a moment to think about how your investors feel when they look at you. They have placed a bet on you, taken theirs or someone else’s money and written you a big check. Even at the best of times you and your company probably seem pretty chaotic to them. But they mostly trust that you’ve got the right objectives in mind and they accept the chaos. Do your best to give your designer(s) the same leeway your investors give you.
Steve Blank has been exhorting startup teams to “get out of the building” for over a decade, but sadly there are still too few that do it enough or do it the right way. It’s not really that surprising, because it’s hard — mostly for psychological reasons. I have good news for you: a good designer is specially trained for this very thing. The important thing to remember here is to not let them be a lonely reality tourist.
There is something magical that happens when someone from your team, particularly an engineer, gets to observe a user in the wild.
They get inspired; they get the vision; they get fired up to build. Despite the value, it can be hard for a designer to fight all the institutional inertia to make the practice a regular part of the work and to pull the rest of the team in to participate. Engineers have deadlines and their managers want to protect their time. Sales and Customer Success want to protect their relationships. Marketing already does research. Product Management already has a bunch of great ideas they came up with on a whiteboard in a room by themselves.
You have the opportunity to pave the way for real user interaction to become a regular part of your team’s activities. Publicly encourage it and publicly recognize the results. Show video clips. Sit in on these sessions yourself and come back sharing the insights. A designer knows how to make these interactions bear fruit; you just have to get the rest of the team fired up to participate. Once they get a first taste, they’ll have an appetite for it.
We’ve all been there. The Product team finally released the founder/CEO’s pet project into production and the users don’t like it. No one wants to tell her. No one wanted to tell her when she first proposed it. No one wanted to tell her when there was a lukewarm response from a few user tests. The only thing that was protected here was the CEO’s ego, and that damage was just pushed off until now, when it will be even more serious.
This is what happens in teams that do not genuinely value authenticity. It’s the kind of situation that makes it nearly impossible for a designer to be effective. Designers are, ultimately, in search of reality. The reality of the user’s needs, the reality of the painful onboarding process, the reality of the emotional experience the visual design delivers.
When real reality gets trumped by official reality, you have a real problem.
Take the example of the Amazon Fire Phone, a case where “because the CEO wants it” became the reason behind a slew of unfortunate features. Countless people knew Dynamic Perspective 3-D was a bad idea, but apparently no one felt their authentic criticism would be valued. Jeff Bezos didn’t effectively encourage and reward authenticity in this case, and the result was embarrassing. Reality struck in the end, but it was far too late in the process to avoid the huge cost.
Before you start listing all the reasons why “this could never happen at my company”, take a moment and read this next sentence carefully. As your company’s founder, you are like Jeff Bezos to your team. You founded the company; you hired them; you make the final calls on what goes into the product and who gets a promotion.
You have a lot of power in the little universe of your startup. Don’t wield it in defense of your ego; be authentic and wield it in search of reality.
It’s hard in this business. As a leader of a startup there are a ton of places where you can’t afford to be completely authentic because everyone is playing the game: doing the rounds with VCs, selling to that important customer, talking to that reporter from Techcrunch. You need to stay aware and find a way to take off that mask when it comes to product design. If you don’t, reality will come back to bite you.
So, if all that has you a bit anxious here is your chance to take back control. The most important thing you can do to help a designer be successful AND the best way to handle the chaotic bumps reality will send your way, is to develop and articulate a clear mission and vision for your company, with objectives for each project as they come up. This is your chance to guide and more importantly, your chance to inspire.
Remember what we heard from Paul Adams at the beginning — design is about constraints. Tim Brown (CBD) describes the project brief as providing the team with “a framework from which to begin, benchmarks by which they can measure progress, and a set of objectives to be realized.” It gives the team a set of navigational beacons to guide the design process and “will allow for serendipity, unpredictability, and the capricious whims of fate, for that is the creative realm from which breakthrough ideas emerge.”
A good design team would never start a project without a brief, and you shouldn’t expect a designer to come in and do good work without a clear mission and vision.
If you don’t have a clear, concrete mission and vision, stop everything and work on that. If you have them, then be sure that everyone on the team hears it at least once a week and can write it down if prompted. It will bring the team together, creating more safety. It will give you all a north star to guide you through the chaos. It will encourage the team to get out of the building by connecting everything they do to the outcome for your customers. It will foster authenticity by giving everyone a goal that is separate from any one person’s opinion or ego.
Do you have valuable insights and experiences in the developer tool space that you’d like to share with our community? We want to hear from you, join our contributor program today.