My initial views
For long I have viewed the job of UI/UX designers as one that ensures a clean looking product with the best experience as possible. This is still true, but I have never thought about the depth of work required to get the best results.
A case in point
I found myself working on the API of a booking feature for an app, Most of my work was influenced by the mockups of the app, Unlike most bookings were you have pre-created slots for users to choose from, this was the kind where there are opening and closing times, which meant a user was allowed to pick any starting to closing time between the opening and closing times. This was represented on the mock-up as a simple time picker. For me, I just went ahead to create an endpoint to accept bookings, cross-checking to prevent overlaps then persist. From the frontend standpoint, things were not exactly ok. You see if the user is allowed to select their preferred times they might end up receiving error messages each time there are overlaps till they finally picked a free time range, which is not the best experience. The next best solution was to populate the time picker with available time slots, the challenge here is we might just end up with a lot of time slots to scroll through.
The Ah Ah moment
This got me thinking, why is this not falling in place nicely, I mean as a developer the only time you seem to have to jump hoops is when you try to mock some natural world scenario, you know like calculating menstrual cycles, timezones etc. There was something wrong. It took a while but it hit me, This is not about implementation its design, This is not a problem for a time picker, this is one that is best solved with something like a display calendar. All booked times are spread and displayed on the calendar, this naturally reveals unbooked slots then the user can pick empty slots. Simple and clean.
Final thoughts and my new view
The one thing I kept thinking about after was if I were a UI/UX designer how would I get this right before it gets to the implementation stage? How do I learn these things? Sure for something like the above case, I would spend time learning about available inputs and when best to use them. But what about other aspects of UI/UX? The only way to know the best option to go with sometimes depends on thinking not only through the colour scheme, the user flow but also aspects like data flow and timeliness. The commonest form of data flow thought of are empty states and overflow of data(when to paginate), what about that long list of available time slots, how long will it take a user to find the perfect time to pick or how long till the server returns the entire time list on picking a date and how can entire process of returning a list be avoided ? Populating a design or mock with data reveals a lot of things that might be overlooked and caught only during implementation because well that's usually the only time you have test data going through the product. Imagine forgetting to add country codes to phone numbers at the design stage and only realising you need to add this when you get to the point of implementing SMS.
As I keep thinking about it, It becomes clear to me a better UI/UX is one that considers the entire life of the app from development to growth. With considerations like happy, sad, failed, successful paths along the way. Thinking through the colours and product flow alone is not enough. The work of the UI/UX designer is one that brings the product to life through imaginations prior to implementation. Again this is something I have never given deep thoughts, maybe many already know this but me, I never thought of it.
Here is another article for you 😊 "NGINX for Laravel projects"