Back in February, 2020, when life seemed normal and Covid-19 hadn’t sunk its teeth into the world deep enough, I found myself scouting the streets of Paris for a hidden gem.
No, not jewelry, but an Indian restaurant with rave reviews from just about everyone who lent a recommendation. I almost always prefer to soak up the local cuisine rather than dip into familiar territory, but, they made it seem difficult to pass up.
This unassuming little restaurant was tucked away in one of the least traversed bylanes of the city, in my opinion. Yet inside, it felt like the whole city had converged upon this one spot.
The Less Leads To More
What struck me, besides the long waiting list, crowed quarters and beautiful traditional décor, was the use of touchscreens to browse and place orders. This freed up service staff’s time to attend to more pressing matters, made checkout far simpler and splashed a bit of modern across the room.
However, there was one big problem and I walked right into it. Upon selecting and/or customizing a preferred dish, there were no visual cues to view the final or submit one. My colleague seemed equally confused. “Perhaps cultural constraints were at play”, we thought. But, this had to be the most peculiar case we had come across.
The wireframe below illustrates what we were presented with. The two ‘X’ marks indicate where we expected some sort of actionable clickthrough to submit an order. I’d imagine many others would to, but, I’d leave that to the research team.
We did manage to secure help from the hostess who nonchalantly clicked the “Order” title at the top as if it was the obvious choice. Fortunately, we weren’t alone. We noticed the same predicament at every other table in the room. It was quite obviously an error leading to poor user-experience.
The illustration below shows where the hostess clicked to submit our order. The title didn’t appear to be clickable in any conceivable way.
In addition, mysteriously absent was an order tab to verify the collective order at the table. I’ve highlighted an ‘X’ in the menu bar where I would most likely expect to find such a feature. It could have displayed a highlight to denote the number of items in the cart. Perhaps, to let me know my order was being accounted for. Something to avoid errors, even embarrassment.
Submitting an order is one of the primary reasons for such a technology to exist. Surely, someone walked the user’s path at some point before delivering the final project. If this was an off-the-shelf product, imagine the extent of this oversight.
Did the designer forget to add the appropriate signifiers? Did the development team not construct the right storyboard? Did the product manager forget to add the user story or build a use case? Did they neglect usability testing altogether? Where was the system feedback, guides or demos? Was it a very tight budget or a short turnaround time?
From any angle, there is no excuse for overlooking research and testing. A quick guide/demo always helps even when tasks appear simple and conventional. One must always account for accessibility and other constraints when building a product. It’s important to construct for inclusion wherever possible, no matter what scale you are working on.
It’s clear that an appropriate signifier was missing, a natural expectation in this case. Also, most customers view/verify the order and bill amount before proceeding with their order. This makes even more sense when there are additional members at the table. Again, an obvious use case.
In this particular instance, the idea and intention behind this technology-induced service were good, Sadly, execution failed to deliver on the promise.
Over the years, my interests in software products, mobile applications and user-experience have grown exponentially and I find myself drawn to projects of these sorts.
I continue to apply the principles and learnings of good user-experience from traditional products or processes to those of a digital nature. In doing so, I’m tickled when I identify gaps, some evident, some not. I try to provide creative, yet grounded, alternatives to what I’ve encountered.
What surprises me is that most product managers fail to nail the obvious. They focus on less important additions. One shouldn’t focus on nice-to-haves before firmly covering the must-haves of any product. It simply defeats the purpose.
The Trouble With Hiring Talent.
For some reason, tech companies today continue to place high weightage on the technical skills of the product manager and less on human or business understanding. I’m sure there are instances where this is a hardwired requirement and by all means they must follow through. But, in instances where it isn’t hardwired, why not try something else (but do so legitimately)?
I believe it is their opinion that non-technical skills can be easily learned with time. But, how much time are you willing to wait? And will they ever get there?
What’s equally intriguing is that the technical product manager may never write a single line of code or exercise his/her primary skills. Instead, they focus on non-technical elements of the development mix. Yet, the industry is almost closed to the thought of product managers from across the wall. Why?