7 min read
·
By Linda Christin Halvorsen
·
December 11, 2019
This December 1st, Helen kicked off our Christmas calendar with a bit of a rant, concerning titles.
"“It’s natural for us to want to keep to our own camp and focus on problems that can be solved with our own discipline. But this tunnel vision can severely limit our creative thinking and force us to fall back on obvious solutions.”"
I couldn’t agree more.
And this year, I came across a challenge that really put this in perspective for me:
The APIs we were delivering, weren’t doing their job.
Well, that’s not exactly true. We were making APIs that worked – others could use them to build their own digital solutions. But it was difficult for them to figure out just how they could make use of them, and develop stuff with them.
And it occurred to me then, as I started looking into that problem, that APIs are as much of a service as running an airport express train and needs just as much design attention if they’re to be great services. And it’s not just about touchpoint-design – like the documentation website – but the design of the APIs in themselves, the communication channels surrounding them, the onboarding process of new developers, security and access levels.
I hadn’t really given APIs much thought as a designer before, I must confess.
I am an interaction design, with 12 years of experience. And my UX playground has certainly grown over the years; from doing strictly user interface interaction specifications and information structures way back in 2007, I now deal with the attractiveness of our digital products, with how our cross-functional teams deliver and collaborate, the viability of our ideas, the organizational intricacies of setting clear goals for digital services and how we work to reach them, the completeness of the customer journey our products are part of and underpin – along with the usability and desirability and doability of it all.
And yet – paying attention to our APIs as a designer and product developer hadn’t really occurred to me as part of responsibility.
I thought of APIs – like most of the organization around me did – as the developers’ responsibility. Alone. It was their delivery – not mine. I don’t handle code. I’m a designer.
Big mistake!
Because fairly soon, we experienced exactly what you would expect when you don’t pay attention to the user experience of your product or service: our users found our APIs difficult to use. And delightfulness? Forget about it. We were – as I believe many are – focused on delivering functional APIs. As long as they worked, we’d met the requirements. I mean – delightful APIs? Come on.
But it is a thing, as I came to learn. Once I started interviewing developers – as good old fashioned user insight – I found different sets of needs, of motivational factors, barriers – and examples and stories of how APIs can delight them, frustrate them, confuse them, and make them want to build more with them.
And it opened up a whole new way of thinking – both for me as a designer, but also for our organization.
And seeing that it is already December 11th, and Christmas is almost around the corner, and that we all have a lot of stuff to do, I’d like to end this article with a few concrete examples of how our new mindset manifested itself. I hope what I have written so far, in a small way, might inspire you a bit, to broaden your perspective as a designer – and that the few points that follow might help you improve your organization’s APIs if that is part of your company’s offering.
The key take-away for me, from the user interviews, was how important a user centric view was even when developing APIs. We had developed APIs based on functional specs – API this shall make that possible. And when it was possible – we were done. But when we interviewed the developers using our APIs it became clear that what would have been helpful for them, would have been developing our APIs based on what they would most likely want to build on top of them. Separating the different APIs after feature areas relevant for our prioritized users, designing objects in a way that most likely would answer to their specific need.
In the end, designing the actual API and develop them falls on the developers: I am simply too far removed from API as a material to efficiently and effectively design for it. But what I was able to do, once I had taken off my tunnel vision goggles, and look outside my regular design box, was to make that part of our delivery, which up until now had not been recognized as a service or product, and put it in a user centric perspective – and thereby adding value to that delivery as well.
(I have, however, included a few links to articles on designing APIs that I found very useful in understanding what good UX for APIs is or can be all about. If you're curious and fancy broaden your designer horizon a bit, check them out)
To quote Helen again:
"“What if the whole team, no matter their background, was more curious about each other's work?”"
And for us, that would have meant that we probably would have caught on a lot faster on the importance of designing APIs as a real service. If I had been more curious about that part of the developers’ job, and they had been more curious about my bringings to the table – I think we could have saved us and our users a whole lot of trouble and delivered a more powerful service sooner.
UX is everywhere – and you can live long and prosper a lot more if you take a look around and not let titles and old assumptions bog you down.
Loading…
Loading…
Loading…