In my daily job I develop a desktop application. I work on the full stack of this application: from back-end services (network, sqlite,…) to front-end (buttons, transparencies, etc.) and everything that I need in the middle.
Different teams help us. One of them is UX: User eXperience: they think about the whole user experience: what should happen when the user imports a document, when something or something else should happen… and how should it look.
Sometimes the UX team have user testing sessions: they invite users at work (or do it remotely) and then the users use the product and the UX team watch what they do, how they do it, etc. Everything is done to improve the experience of the user using our product.
This topic (user testing) is very well documented and explained in many books, blogs, conferences, etc.
The key idea to remember here is that the the user interface, flows, etc. is how the user interacts with the software.
At the moment part of my job is working on migrating to a new API that it doesn’t exist yet. I’m also helping to design the API: given my user cases, what we should implement, when, etc.
The user interface is how the user interacts with the software, and the API is how other users (programmers) interact with the software too. Obviously it’s a different type of interaction and different type of user but the basics are the same: if there is “user testing” (for the user interface) there should also be “programmer testing” (for the API): invite a few programmers and ask them to do some tasks and see how they perform. Are they surprised by the API? Do they find it easy to use? What they did expect? Do they like it?
And then, obviously, design an API which is easy to use for the programmers – if you want the programmers to use the API indeed.
Leave a Reply