Traditional developer first process
Before we begin I'd like you to ask yourself some specific questions around your application development (web, mobile or api) strategy:
- Do you consider your experience or customer experience first?
- Do you consider which tool you want to try or use first? Like the new feature released in a new framework you are so eager to try out.
If you answered yes to most of the questions just like myself, then yes, you are the right audience I want to read this article.
As developers we are sometimes too focused on trying out and using new tooling that we sometimes dig a hole for ourselves by depending too much on the tooling. We sometimes forget the most important aspect or reason for the application that exists, the end users, the customers and the api consumers.
Let's take a notes taking app as an example, for an api consumer, they would just want to access the api, maybe create a note, delete a note and update the note. For an end user, they would want to do the same but maybe with an accessible UI that they can easily browse and click to perform the same actions.
If we are to develop the application with developer first or driven approach, we first start to think:
ok, what fancy animation library can I use, ah, I remember, I just saw that remix has optimistic UIs, that looks really fancy, hmmm, how about using Mongo DB to store some data around UI preferences, or I could even use local storage to add some fancy dark and light mode. Ok and I could also use Laravel too with livewire or inertia, I think I prefer inertia over livewire as I can easily build my UI with react because of it's tight integration to react. Ok or, maybe, I could use Lambda functions with AWS API gateway, I have seen a lot of developers using it and yes for authentication I could use aws amplify. And the conversation goes, on and on and on...
I tend to have such conversations and before I realize I have used all or most of the stack above and I end up in a technical hole, having to learn to not only use these tools but make them work even if they pose issues later, I mean, I selected them so they should work right?
I think we can avoid most of these issues and in fact, they should be avoided. It leads us towards a path where we end up with a lot of tooling either not used well or it leads us towards a path that we have to apply patches here and there just to make it work or achieve the end user goal. Because we only thought of our tooling, we end up later realising, ah, this will not maybe allow me to do what the user actually wants and so we turn into hunters for answers on stack overflow on how to undo or patch our over engineered sites.
End user first or driven approach
The end user's first approach dictates that we first try to enable the users of our product. In the initial phase or design of our product, we can focus on the end user and how we can help them achieve their goal. It dictates that we first access what our end users need, before we look for tools to efficiently achieve them.
View Website
View Website
View Website
Using the same scenario, we would instead look at an api design that helps the developer derive what they need. If they want to select only certain fields from the note, can we make that possible in the design instead of them having to filter on the UI, we can easily make this possible with a query. In the case of an end user, what's most important to the user, a fancy UI or accessibility, can we consider giving them a PWA that they can save to their devices and access the notes with just a click of an app. A delete all my notes button could also be useful for the user instead of having to delete notes one after the other.
We can put all these together in the design phase before we go ahead to think about the development. In this way, we have an experience (both the api and web/mobile app user) that we want to achieve and not tooling that we want to use. We can then think about tools that helps us to achieve that precise experience they want. If we think like this, some answers might be very clear, like a floating ball in the page is not useful to end user but a PWA might be reasonable for them before you add plans if at all necessary to developer a mobile application later on.
With an end user approach, we can accomplish the following:
- Reduce delays to launch by presenting a well thought out design to stackholders on how they would interact with the product to avoid having to later iterate our backends to accomplish what they want.
- Avoid having to patch and iterate our backends or UIs to meet consumer needs after realising, hey, what we are doing dosen't actually work or scale.
During the design phase of our products, we can focus on some of these decisions, follow the end user approach and develop an application that both our end user and ourselves will love and be proud of.
Comments (0)