Product

  • Encouraging actions on a mobile home page

    High information density causes decision fatigue. It is a CTR killer everywhere. But more so on app home pages. Identify key decision variables and highlight only those. Put details a step away. (For example, when listing a deal, the price is important but location or rating may not be.)

    If encouraging exploration is an objective, then there needs to be novelty on the page. Customers will stop returning if they see the same thing every time. You are teaching them “do not expect anything new”. Not all apps can do this. And that is fine.

    Provide visual breaks. Exploration fatigue kicks in if customers see similar visual elements for too long. These can simply be differences in templates, or different types of content.

    The breaks are also good entry points to handholding actions. These nudge customers to the right section of the app without putting in effort. (For example, exposing content filters after a few scrolls.)

  • Designing an app home page

    In all mobile apps, the home page is the most important property. It’s always the first and most frequent interaction point for customers. The challenge is in keeping it relevant and fresh. Users seeing the same content every time will eventually stop expecting anything new and drop-off.

    But as with everything in life, it is not all black and white. It always depends on the nature of the app. Apps that naturally encourage exploration have it easier, while apps whose primary job is to induce actions (eg. transactions) have to focus on, well, actions.

    Social and e-commerce apps have it easier with user-generated content, product recommendations, extensive curation and merchandising. (These are not trivial problems, but the path is clear.)

    Need-based apps, like payments and travel, struggle since they don’t naturally generate new content. The most critical job for the home page is to ensure the primary need(s) is (are) satisfied first and foremost. Hence, the focus on actions.

    Often there is an “internal” push to make home pages of need based apps more “engaging”. Leading them to rely on listing deals and offers or some other form of force fitting. But this kind of content does not “cause” actions. The push to make such apps engaging leads to creating content for the sake of it. Which essentially draws the focus away from more important priorities.

  • Simplifying Product Complexity

    Over the last decade, I have been involved in building hundreds of features. Sometimes to add customer value. At other times to improve internal efficiencies. And many other reasons. The challenge has always been simplifying the solution. It is to find the sweet spot between the complexity of the build vs likelihood of risk or reward.

    I started off loving the complex solutions. But have wisened up since then. Here’s how I approach this today.


    Start with the problem. Think about the ideal solution that solves the problem completely for your customers. This is likely going to be complex and convoluted to build. (Which means you’ll be slower to market and, hence, slower is validating your hypotheses behind solving the problem in the first place.)

    Now evaluate the impact of solving the problem. What’s the outcome going to be? For your customer. For you. What’s the likelihood of that outcome?

    Now take a step back and question the solution. Does it need to be as complex? How much can you remove and reduce without reducing the benefits so much that the outcome is no longer useful — for your customers and/or for you?

    This step is recursive as you keep simplifying. Where you stop is determined by when:

    1. The outcome is likely to be no longer useful for your customers.
    2. The outcome is likely to be no longer useful for you.
    3. You can’t measure (1) or (2) by simplifying any further.

    What remains is something that is probably good enough to be of value to both your customers and you. (This is a simplification of explaining simplification.)


    Few examples of simplification I have used in the past.

    • Use a static CSV or JSON instead of an interface.
    • Hardcoding works. (If you can convince your engineering team.)
    • Assume defaults — remove choices and inputs.
    • Use rules instead of fancy algorithms.
    • Discrete selections instead of open-ended inputs (aka chat-bot).
    • Human-powered processes instead of tech solutions.

    The goal is not to create fancy tech. It is to solve a problem that your customers value. Bring in the tech once the hypotheses are validated and you need to scale.

  • Building Mobile Apps

    Owning Cleartrip’s mobile apps between 2014–16 was one of the most satisfying assignments I worked on. It was the beginning of the mobile growth years in India. We had the opportunity to shape the direction of the product. The team’s effort improved most metrics. There was external recognition as well. The app was selected Editor’s Choice on both App Store and Play Store in this period and won a few product-design awards as well.


    The success of the mobile platform also gave me the opportunity to be part of public discourse on mobile growth in India. Here are some mobile app development principles I had put together for a presentation during that time. Much of it is still valid.

    • It is still difficult to tap, type, correct and read on a mobile screen. Reduce and remove friction for these actions.
    • Reduce the number of taps required to reach a goal. Provide recommended starting points, combine actions to reduce clicks, ask for as few details as possible.
    • Reduce duplication, make it easy to find again. Remember recent and past actions, repeating inputs and “what I’ve already seen”.
    • Anticipate user needs and intervene. Assisted filters, fuzzy search and real-time input validation reduce stress.
    • Make it easy to assimilate information. Solve for aggregate (result-set grouping) as well as specific information (result metadata). Progressively disclose details.
    • Gracefully handle errors — ”What did I do wrong? What are the consequences? What should I do now?” Switching context to Google for solutions is stressful.
    • Solve for the journey; not the stop. Engagement brings users back. When users come back, trust increases. An increase in trust leads to (repeated) conversion(s).
    • What does a customer lose by leaving? What does a customer gain by staying? These are the best use-cases.
    • The best use-cases decay slower than others increasing retention. Encourage and guide users to these use cases.
    • Solve for mobility. Use device capabilities, solve mobile specific use cases (eg. near me, right now, share). But respect the physical limitations of the device — display, storage, bandwidth, battery. [1]
    • Respect the platform. Use first-party patterns where available. Don’t port patterns across platforms.

    [1] This is one aspect where things have changed significantly in the last 2 years. Most of these aren’t practical limitations any more. But that is no reason to be complacent. Behaviour (eg. concern about app size) is hard to change.


    [Update: 20 April, 2021]

    A thread on this on the occasion of Cleartrip’s acquisition by Flipkart.