This is a post from our Featured Guest Series! Ash Hathaway shares her experience as a former developer turned product manager for APIs, and how design thinking has helped her team solves difficult technical problems.
If you're interested in sharing your knowledge on our blog, check out our Featured Guest Series page for more details.
You may have heard of design thinking or even participated in a workshop using lots of sticky notes. Done correctly design thinking is an insanely fun way to generate tons of ideas with your team, create buy-in, and leapfrog ideas all centered around your user. So, what is it? And why does it matter for APIs?
Design thinking is a way to solve complex and multidimensional problems smarter together. The roots of design thinking are in human-computer interaction design which evolved into a framework to innovation. More specifically it touts methods to find overlap in business strategy, technological feasibility, and user needs. It is a “process for creative problem solving,” according to IDEO, an international design consulting firm and large proponent (some might say the OG) of design thinking in mainstream tech today.
Why design thinking makes sense for APIs
So what does this have to do with APIs? APIs are like super technical and deal with code. That has zero to do with design, doesn’t it?
Well, I might ask you first: Do APIs require multiple stakeholders buy-in? Are there conflicting needs and goals of the API? Are there questions into what features should be improved on or prioritized? If you’re wondering perhaps how to improve the overall experience of your API or are lustful over the experience of some API offerings out there then I might say you have a design problem. Unless your company is super flat or product is completely 100% open chances are there are conflicting viewpoints somewhere.
Design is more than just what color your logo is. Experience design is more than just wireframes. When we start to think about the thoughts that enter a human's mind before they ever search for a tool, when we look at their emotional state while working with a product, when we consider an overall ecosystem of users and their hopes and fears, we’re actually considering design.
Design for APIs means making that first time experience dead simple and delightful. It means delivering value to your user right away. It also means continuing the “wow” factor or at the very least a “this doesn’t cause any trouble” factor from then on out. It means having an experience that benefits a new coder as well as a principal software engineer. It means understanding the why, the how, and the meaning to the people you’re building for.
APIs as user-centric experiences
When building an API we can get wrapped up in assumptions at times. Of course we all know that 404 means “not found”. We know the difference between PUT and POST. REST APIs are obviously better than SOAP. DUH. But wait… why? To a new user these things might be very foreign concepts. To a developer working for the Government perhaps SOAP is still a thing.
Design thinking asks people to consider their user in a very specific and very purposeful way. For instance, if I’m writing documentation for a seasoned engineer I might explain things differently than to a junior dev. Just as I might make a getting started tutorial differently for a Rubyist than a Java engineer or suggest different tools to someone wanting to use R. If it’s going to be important to a developer to make the case to their management I might put more emphasis on developing marketing material like whitepapers or webinars for executives as opposed to another sandbox demo.
Divergent/Convergent Thinking
More specific benefits are what design thinking points out as divergent/convergent thinking.
Basically divergent thinking creates a bunch of ideas and convergent decides upon those ideas. What’s great about this is that if you get a bunch of people thinking about the same problem a little differently after diverging there are a ton of different ideas all considering the same problem from different vantage points. You begin to get a 360’ view of a problem.
Then, converging, means finding patterns in these vantage points. One person may have uncovered a huge pain point which suddenly shifts the focus of user needs. Perhaps it’s very clear that the majority of issues stem from one source and clearly should be worked on first.
I’ve run through this exercise a few times with various products ranging from huge SaaS offerings to an API experience. Within the span of literally 10 minutes a broad team with different motivations can see the landscape of the issue more clearly, generate a ton of solutions and ideas on how to solve it, and then agree upon direction. *Magic*.
In one instance of running this exercise with my coworkers, the most valuable part of the experience for me was finding out the different pain points or worries from the team. They saw the product in a different way than I did. We had similar viewpoints, but they saw the product through the lens of a head of engineering for instance. There were more thoughts into the actual building and what the team was working on in addition to this particular part of the product. I saw it through the lens of a product manager. There were more thoughts into the effects of the market or competitive strategy. When we got it all laid out on the table and started talking about priorities, planning got far easier.
Remember the empathy with your code
Another often underutilized tool out of the design thinking hat is the empathy map. Most of the time I’ve seen teams go “yeah yeah yeah we have personas. Check.” But, I ask, what shoes would your user wear? Where do they go on vacation? To get really prescriptive- what type of wine do they bring to a dinner party? Do they even go to dinner parties?
While this might seem in the weeds what this asks is for the API designers (and by designers I mean anyone responsible for creating or working on an API experience) to empathize with their users. To actually feel their pain points. To so clearly be able to decide what feature should be prioritized. To see where they get confused in the documentation and why people keep dropping off at a certain point in the onboarding process.
Empathy maps can again literally be accomplished in 10 minutes. It’s best to get a large group of stakeholders from various groups and if at all possible bring actual user research to the group. Firsthand accounts of usage or testimonials (good and bad!) can be invaluable. Next it’s literally taking your best guess as to what that hypothetical persona thinks/feels/says/does and what their pains & gains are in using your product.
For some, this activity might seem ridiculous. And in a way it is I suppose. However, I would argue that if at the end you’re able to better understand the people you’re building for then it will result in shipping the right thing for the right person at the right time. That’s invaluable.
I’ve done this activity remotely, in a giant session with 10 people, or in a small group of just designers. It doesn’t need to be super fancy. The key is to put yourself in someone else's shoes for a moment and then capture that feeling to reference it again and again. Pro tip: bringing in user-researchers in this step can be super helpful. They can provide fantastic research and eliminate all sorts of assumptions about your user and target audience.
Let’s do this!!
Curious to learn more about design thinking? Have no fear! There are plenty of resources available:
- IDEO has IdeoU which offers courses on design-thinking and plenty of helpful information.
- A wonderful & in-depth guide to design thinking history.
- Salesforce’s take on converge/divergent thinking.
- On running an empathy map and user journey map session.
Ash’s goal is to make APIs friendlier and more usable for all. As a former developer turned product manager for APIs and open-source software products she has seen first-hand the impact of a great developer experience. She has consulted for international and domestic corporations and startups and most recently was on the original IBM Watson Developer Cloud product team. Her process is rooted in empathy, collaboration, and getting ship done together. She is available for consulting and wants to learn how she can help.