Yay! Halleluja! Huzzah! Yippee Skippee! The day I have longed for has arrived. I am no longer the only one talking about the need for design philosophy in the API space. At this time last year, Alan Cooper (the godfather of user centered design) and I were seemingly the only ones who recognized that this space is in need of designers. Although Alan empathized and heartily agreed with me I still felt alone given that nobody else was writing or speaking about the topic. Fast forward one year and there was an actual panel at SXSW and a room full of people committing to be in a workshop for more than 2 and a half hours to talk and learn about the "UX of APIs".
The Preamble - UX 101
The panel was made up of Jeremiah Lee formally of awe.sm, Brian Smith of Dropbox, Neil Mansilla of Mashery and R. Kevin Nelson of rdio. Jeremiah kicked off the panel discussion with a definition of the User Experience discipline. UX he said, was "empathy as an applied science". He proceeded to give the roomful of geeks an introductory course in user experience and covered a good amount of ground from Jared Spool, to Aaron Walter.
Jeremiah's precept was that "supporting 3rd party developers takes more than code". From here he explained a good amount of foundational UX subject matter. He explained Jared Spool's 5 design styles (unintended, self, genius, activity focused and experience focused) and then spoke in detail about user research methods and how they differed from market research (user research informs design, market research validates a market).
Jeremiah had to cede the floor to the rest of the panel at this point, and the panel gave deep first hand experience with creating APIs, SDKs and how they have worked with communities of developers in developing engaged communities. I found all of the materials presented and conversations valuable and waited patiently to contribute what I knew would be a hand grenade. I walked up to the mic, gave some apologies for what I was about to say, dropped the bomb and then let the fun commence.
The Bomb - UX 201
Helping API developers understand that they have an actual audience is a great start. Teaching them some basic fundamentals of how to think about and apply UX tactics is also great. The bomb that I threw out there was that even though these are necessary to make progress, neither of these tactics are sufficient to solve the underlying misunderstanding of how design thinking can advance the power of strategic API usage and adoption in the marketplace.
Having a holistic perspective of this space requires an understanding of a couple of fairly complex truths:
- UX is not primarily about design - UX is a mix of design, business strategy and empathy. Finding design patterns that align business goals with user desires along with technology affordances is the actual task at hand. Just aligning one or two of these lenses is not sufficient as they will not fundamentally meet the ultimate goal of engendering the behaviors of the necessary players in the mix.
- Teaching developers about UX is good. Putting developers in the driver's seat of design is bad. Unless the developer in question has the rare ability to transcend the conflict interest regarding ease of development, putting developers in the primary seat for design tradeoffs is inherently a sub-optimal choice because they will 99 or more times out of 100 choose either the easier to implement, or more technically elegant development pattern. Reducing the priority of lower-effort and self actualizing implementation plans requires many years of experience because the muscle memory involved is an unconscious reflex for almost all developers and technical architects.
- Neither classically trained UX professionals nor business strategists have the right aesthetic eye for what will appeal to a consuming developer of an API . In the same way that visual and graphic designers have trained their eyes to see composition and balance, developers have refined palettes when it comes to API and SDK design. Teaching a UX designer about why certain choices on things like variable scoping, parameter naming, order of operation and callback patterns are more beautiful than others is like trying to get a developer to see why a 4 pixel gutter around an area with an 1 pixel stroke is beautiful. They may eventually understand it, but they will never be predisposed to seeing it naturally. Even if you were able to retrain their minds to think and see the other way, you run the risk of losing what made them good at the other way of seeing.
The Prescription - Multidisciplinary Design 101
The long and short of it is this: In the same way that having a print designer design your web experience is probably a bad idea, and having a e-commerce web designer design for a content engagement experience is probably a bad idea, having either an experience designer or a developer design an API in isolation is also probably a bad idea.
To really maximize the likelihood of meeting the overall business goals, user goals and keep things technically viable you must bring in business strategists, user experience researchers and development professionals. The only other way I can think of, is to find and hire a great multidisciplinary professional well-steeped in all three disciplines (i.e., Alan Cooper). I don't think the LinkedIn search API can easily support searching for multidisciplinary professionals. Note to Allen Blue, Adam Trachtenberg and Deep Nishar (@allenb, @atrachtenberg and @deepnishar) over at LinkedIn: There's a great idea for the LinkedIn API team! Gimme some props!
Editor's Note: Catch all Stephen's coverage from SXSW, it was an interesting event.