In meetings, we often hear the same line,
"That's not a bug. Report it as an enhancement."
Sometimes the observed behavior never even makes it to the enhancement list.
But, what happens when the problem is not about functionality, but about how the users experience the GUI and its usability?
My peer Dhanasekar Subramaniam (DS) recently published a blog about a UI design that delayed him using the app. This made me curious. How could a UI that an engineering team acknowledged and used slow down a user?
I decided to test investigate the design. On testing and analyzing the UI behavior and usability, I discovered something interesting -- the GUI looks as in code, but behaved differently to the human eye.
I went through the usability and experience problem, but I was conscious about this behavior so I could identify it in quick time.
If you are a SDET or Test Engineer, this blog will help you develop new perspectives while analyzing GUI problems. If you are a manager or decision-maker, it highlights why seemingly small GUI problems should not be ignored.
When a Simple Task Creates Anxiety
Late at night 11 PM, the user opened the cab booking app Rapido, just as they had done many times before. The goal was simple -- book a cab and reach the bus stop.
But something unexpected happened.
This time, the users could not figure out how to book the cab.
Seconds started passing. The GUI looked familiar, yet the action to book the ride was not obvious. Nearly 45+ seconds went by, trying to understand what to do next.
The situation made it worse.
It was 11 PM, the bus departure time was getting closer, and the user was unaware how to proceed because of the app's GUI.
That moment -- when the user knows the app, knows the task, yet cannot complete it, creates anxiety.
So the question is,
Why did two tech-savvy users, using an iPhone and familiar with the app, spend more than 45 seconds trying to figure out how to book a cab?
45 seconds for a task that usually takes less than 5 makes the problem feel bigger instantly.
Understanding the Cause of Anxiety
- I installed the Rapido on the Android phone.
- I have no ride history with Rapido.
- I signed in for the first time.
- I see the Ride screen.
- I see the three addresses given which I had not chosen. I could save these as favorite; I did not.
- The text in the search text field.
- The color contrast of search text field.
- The color contrast of view showing the three addresses.
- The color contrast in between the 2 and 3.
- User not able to identify that is a search text field which is tappable.
What to fix?
- To rephrase the search text.
- "Enter pickup location" works as charm; refer Pic-4 in this blog post.
- To have better color contrasting for the three GUI elements.
- The GUI color and contrast to have ΔE ≥ 3 -- good and preferred
- To highlight a search text field so that I will be prompted to tap and enter or select the pick-up and drop location.
- When experimenting with AB Test configs, the GUI design to follow the suggested GUI Design & Color Engineering practices.
The First Usability Pitfall in the GUI
- I looked at the top of the screen. I see text -- "Where are you going?".
- Below the text, I see the three locations listed which I had not chosen or entered or of my current interest.
- I see a search text field.
- I see a search icon next to the text field.
- The search text field has a text -- "Where are you going?"
Why am I asked where am I going and listing the three locations that I did not enter or choose?
The Second Usability Pitfall in the GUI
- There is no prominent visual difference in the layouts of
- Search text field
- Color hex code #FFF8FAFC
- The three location displayed
- Color hex code #FFF6FAFF
- Yes my brain could not perceive the differences right away between these two layouts.
![]() |
Pic-2: The color contrast of the GUI elements. |
- This added for the confusion.
- My brain was perplexed in knowing what's happening here.
- I'm wasting time here to learn how to book a cab.
- Is this what a Rapido need as a business?
- Or, does it need a user to book a cab right away on opening the app?
- Won't this experience drive away the user to the competitors app -- Ola, Uber, Namma Yatri.
- All these three GUI components are on one main view
- To the human eye and brain, the color contrast of these three GUI components blend as one rather three distinct GUI elements.
Not being able to distinguish between these three GUI elements in a quick time is a problem. Why the app has confusing color engineering for these three GUI components? Why the GUI design did not highlight that search text field as tappable? Why the search text is confusing when combined with the GUI color?
Rapido's Competitor GUI and Usability
- The search text is straight and easy to understand.
- The readability of search text is close to the context of using the app.
- Importantly, the search text field is easily distinguishable easily.
![]() |
Pic-3: The search text field and GUI in Ola, Uber and Rapido apps. |
The Two GUIs of Ride Screen
![]() |
Pic-4: The two different Ride screens of Rapido. |
Test Investigation & Analysis - Why My Brain & Eyes Took 45+ Seconds?
This section has details of my debugging, test investigation and analysis. I have put my eyes, brain, smart phone, reasoning and the Rapido app to evaluation.
If you are a Test Engineer or SDET in a role, this should be super helpful when you are testing for GUI. Do not skip it!
Human Eyes and Cones for Blue Shades
- L-cones is for Long-wavelength cones; it is sensitive to red-ish light.
- M-cones is for Medium-wavelength cones; it is sensitive to Green-ish light.
- S-cones is for Short-wavelength cones; it is to Blue-ish light.
- #FFF8FAFC
- #FFF6FAFF
![]() |
Pic-5: #FFF8FAFC color |
![]() |
Pic-6: #FFF6FAFF color |
These two hexa color codes explain my observation.
- I struggled to distinguish the subtle color difference, especially in certain ranges.
- So the two users who were booking the cab at 11 PM. Why?
- We humans have a fewer S-cones and it is less sensitive. Hence, the small changes in blue/cyan hues are hard to see.
Display Behavior of Smart Phones
That is, the smart phones,
- Quantize colors (round up values)
- Use OLED sub-pixels
- Apply gamma corrections
Viewing Angle Makes It Even Worse
![]() |
Pic-7: Holding the smart phone to view at an 180 degree to the ground. |
- The contrast reduces
- The colors shift
- The subpixels blur
Why It Fails - Mathematical Analysis and Human Brain
- This range falls into interpretation as slightly noticeable -- borderline perception.
- For such colors the human sensitivity to differences drops significantly.
- Despite the ΔE ≈ 2, in reality the users will not notice the differences, especially on the mobile phones.
- Display Quantization
- The values of R and B are near maximum in the above said color
- The maximum color value is 255.
- In our case the RGB of the two are rgb(246, 250, 252) and (248, 250, 252).
- Rounding and Gamma correction will compress the differences from the hardware and software of a mobile device.
- OLED Screen
- The smart phones having OLED screens, with high brightness levels,
- The subpixel differences become less distinguishable
- +3 in blue channel may not produce a visible shift
- -2 in red may be completely lost
- Viewing Conditions
- On smart phones, the brightness varies, ambient light interferes and viewing angle shifts color.
- As a Result, ΔE ≈ 2 is often perceived as identical by human brain.
- That is, the human brain cannot differentiate between the colors
- These two colors used is not helpful and unreliable.
- Not suitable for distinguishing the GUI elements.
- Needs stronger contrast for interactive GUI design.
- If the ΔE ≈ 2.0 to 2.3, it is borderline and unreliable.
- The range 2.0 to 2.3 may be ok only for subtle background variations.
- In this case it failed; we all three users had difficulty and trouble to understand the GUI.
- Use the colors and contrasts with ΔE ≥ 3.
- ΔE is < 1,
- the interpretation is not visible.
- ΔE is 1 to 2,
- the interpretation is barely noticeable.
- ΔE is 2 to 3,
- the interpretation is slightly noticeable
- But it does not serve on mobile app engineering.
- ΔE > 3,
- clearly visible
![]() |
| Pic-8: The screenshot of this blog post on my mobile screen. |
What's the Fix?
- For mobile app engineering, the recommendation for GUI color and contrast is
- ΔE ≥ 3 -- good and preferred
- ΔE ≥ 5 -- safe
- Use the better text in the search text field
- This looks better and prompts to tap on it -- "Enter pickup location"
- Distinguish and highlight the search text field GUI component prominently
- When experimenting with AB Test configs, the GUI design to follow the suggested GUI Design & Color Engineering practices.







