Not much has been written about the user experience (UX) of working with open data. This is troublesome for those of use who work with open data everyday; we either provide a sub-optimal experience for our data customers or we suffer ourselves when pulling in data from less mature external sources. Nevertheless, this is an opportunity for UX-ers who are looking for green fields where they can share their knowledge (and get paid).
This is part 1 in a series of articles that covers steps you can take, as a UX professional or a product owner for open data, to improve the UX that an organization provides its data customers.
To keep a manageable scope around the term “open data” let’s consider only the data sets that organizations publish via APIs. Depending on their mission and goals, organizations open their data for various reasons:
- They may charge for access to the data
- They may be looking to expand the reach of their brand by giving it away
- Their business model may rely on paying developers to push their content to their own customers.
Whatever the purpose, software engineers and developers use these APIs for their websites, mobile apps, or their own internal systems. There’s lots of room for improving the engineers’ experience so let’s look at the two primary opportunities: the APIs themselves and the documentation that supports the APIs.
Two Opportunities to Improve the UX with Open Data
First, even though software will eventually be “talking” exclusively with the APIs (machine2machine) engineers must first work directly with the data coming from the APIs and build the connections. We want to improve that experience so the engineers continue to work with the APIs. If it’s too difficult they will drop off and go somewhere else.
Second, API documentation is housed on web pages. As such, common sense UX applies. Nevertheless, there are developer-specific use cases to consider. Keep in mind too that developers, not UX-perts, typically write the documentation so there’s room for improvement.
In order to really appreciate the vantage point of the developer, let’s walk through the process I’m going through to build out an awesome app idea I have. I can’t make you sign an NDA so I ask that you don’t steal this. Really. It’s my kid’s college fund at stake. Ready?
Kittinder! An app for setting up play dates for your cat! Dogs are easy – a few sniffs, a woof, and they’re good. Cats are much finickier so it’s much harder to find a good match. Opportunity knocking!
There are three sources of data that I want to access to drive my app:
Like US Cesus that has information about your household, your education, and employment, PetCensus captures cat statistics across the country. This way I can easily find what actual cats are nearby so I know what my play-dating pool is.
The ASPCE (American Society for Promoting Cat Emotions)
Has information about the nature of each breed of cat. Siamese are sneaky, calicoes are coy. What other dimensions might they have? How do they interact? We’ll see.
Once I get the various dimensions of each breed, half-breed and alley cat, I need to figure out how to match them. Tinder publishes its matching algorithm as an API. I send them the weighted dimensions and they send me back a score.
In Part Two of this series we’ll explore each of these APIs, look at their documentation and end points (where we pick up the data), and call out where there’s opportunity for improving my user experience.
Gripe and Punishment
Gripe: People who talk to themselves loudly in an effort to get attention.
Punishment: Strike up a conversation with them then talk in an incredibly low and mumbled voice.
Just to be clear: We don’t need to hear your criteria about which Cheerios to buy. We all got stuff on our minds so don’t assume you can interrupt my thought process with yours.