You Might Get a 2.5 Star Mobile App Even if You Hire Apple' Sir Jony Ive. No Tool in the Market Can Save You Today

Last year Wall Street Journal reported that Apple is planning to build an electric car, perhaps designed by Jonathan Ive's team. Imagine what would happen if the manufacturing process does not conform to the design spec! It could literally mean the difference between life and death. Apple might lose its iPhone, iPod halo effect. Hopefully Apple’s designers and testers have great tools to verify that the final version matches the spec. That said, manual testing of mobile apps is rocket science after 9 years of smart phones. The tools market is woefully in stone ages here. Testing a mobile app, verifying it conforms to design, replicating bugs and communicating it to development teams is a pain.

The Tools For Designer-Developer Workflow Don’t Do Round Trip Verification

As a Mobile App Publisher you know the drill well: You got a great UX, UI design team with the latest and greatest in design thinking. When you end up deciding to make something worthwhile you will probably look at a mobile development sprint that likes like this

Tools like Zeplin, InvisionApp address the designer to dev workflow & communication, and SDKs that you integrate like Crashlytics (now Twitter's Fabric) help pinpoint exceptions. Let’s look at some of the tools you have today:

a. Design Workflow Tools:
Invision App: Awesome collaboration tool to bring designers, product owners and developers under one banner. Helps designers communicate their prototypes. Allows developers to understand the interactions and ask the right questions. Zeplin: Reduces designer's pain of communicating a visual guideline. The visual guide is now a living document. It is easy for developers to make changes whenever there is a change.  

b. Runtime debugging tools:
Crashlytics (Twitter's Fabric), Google’s Firebase: helps you capture a crash, usage details and fix bugs

c. Beta deployment tools:
HockeyApp, Testflight help you do a limited release during your sprint to customer facing functions

d. Mobile Analytics Tools: There are at least 40 of these now. Top of the recall are Firebase, MixPanel, Amplitude and Localytics. These tools are excellent in helping you understand key measures like engagement, churn, usage and user behavior.

What about Verifying that the Developed App Conforms to Spec & Capturing Feedback for #Fail Interactions?

If you have ever developed using the familiar Agile sprint cycle you know the drill: The mobile developer starts his voyage to his dilbert cubicle and develops the app. At the end of the sprint(or possibly towards some of the later sprints in your cycle) you get a build through one of the beta deployment tools and the product owner, designer, QA and any customer facing function start playing around with the build.

Your sprint breaks down right at that point: You realize that your app is a forest of live bugs. Tiny bugs like labels misspelt, alignment issues, inconsistency in visual design conformance and then bloopers like it just does not work on my Android device (and the developer jumps on you asking for incoherent version details that read like  {ice-cream-pizza-burger name}). 

What do you do when you see a UI/functional bug?

The safest way is to capture the screen and annotate it or even better record the interaction and annotate specific frames. In the web world tools like Jira Capture or even a simple screenshot capture tool does that easily. What about the mobile world? Anyone who has tried recording a screen on a mobile knows that it requires a tutorial on Youtube (seriously there are at least 10 links that show how to capture a screen and a video in a mobile app). And then you need to communicate the errors.

For someone like me who has fingers of Shrek, drafting & emailing a long “Steps to reproduce the error” on my mobile is a pain. Logging the bug is close to impossible now. Remember the days before Jira? Tracking bugs on spreadsheets was a pain. But then someone has to log it. It is not easy to log mobile bugs on Jira. The result is that these 'bugs' get lost in the din of communication, ever pressing deadlines and priorities.
The last time I logged such a bug the steps included: capturing a video, uploading it, writing up stuff on what the error was and then finally logging it on Jira – this took 3 minutes and 8 seconds to do this. A typical sprint cycle many such bugs. If you don’t provide rich detail, you hear the familiar & very valid refrain from the developer: Remember that bug you listed on Jira? Can you list steps to replicate it, it seems to work fine on my mobile. I just downgraded the priority to trivial- can’t get it done this sprint when we don’t know how to replicate it.

How to suck more now? Try User testing in this confusion

What motivation will your user testers have to replicate a difficult to understand interaction if it takes 5 minutes to just capture a screenshot or a video of your app to reproduce the error. Apps like Appsee, Lookback are all there – they work fine when you get the basic app out of the door, perhaps even when you are out of the proverbial alpha door. Will you still be able to effectively use such tools when you are fighting a battle getting a basic version out?

My lesson from all this?
Great designs create engaging apps.
“Great designs executed with pixel perfect implementation create great apps”

We faced this pain as app developers and finally decided to take matters in our hands. Before I go into the actual solution of how we solved this problem let me leave you with one more big pain when it comes to mobile UI that no one(except for Google in this article) seems to be talking. It’s about user interface text - all that tiny bits of text that deals with labels, buttons, error message and info messages also known as “micro copy”. User interface text is the lowly cousin of user interface design. But guess what: most error messages today in your mobile app are atrocious. That’s because they are dreamt up in the last minute , they are not personalized, not funny (or 'engaging') and are boring. And that’s because customer development team members who know what goes in the mind of the user cannot make changes to text in mobile apps easily.

Part 2 is the second problem in the mobile app design verification - engaging user interface text is tough and today that’s written by your developers and managed as a last minute afterthought. Till then, so long. 

Visit if you want to know what we built


Read more posts by this author.