Category: Product Features

  • Contextual Native Carousels now available

    The animation below show  how easy it is to now deliver beautiful carousels in Contextual without:

    1. needing to write code, just add our SDK
    2. needing to do an Appstore Release!

    You can also A/B Test different carousels to targeted groups to test which gives the best results.

    In this video you can see it takes seconds to :

    1. craft a 2-screen carousel
    2. select an image from our library or pick your own
    3. change the text
    4. preview it on a real device

    Some other great controls are:

    • Full control over font type, color, background color
    • Beautiful swipe colour transition between screens
    • Buttons can customized for each slide (see down the bottom it changes from “Skip” to “Done”
    • No particular limit on carousel screens. But we recommend no more than 3, otherwise you’ll drive your users crazy!
    • Multiple images per screen.
  • The peculiar lure of launchers for App engagement

    Cognitive overload in mobile Apps is a real problem for designers. My general rule-of-thumb for a well-designed mobile App is to assume the user’s IQ is halved.

    This is not intended as malicious or critical of users, its a recognition that mobile apps serve people on the run, getting out of cars, crossing streets – so that splits their attention and IQ.

    So if a “desktop design” approach is shoe-horned into a mobile App, the cognitive overload conflicts with a “Jobs To Be Done” (JTBD) imperative.

    So great Apps have layer of content and a layer of guidance. This is where Launchers play a role.

    You’ve seen…


    One of the most common tool-tips is universally understood, its usually small, unobtrusive but in a moment of confusion, the user knows there is access to more information.
    Of course the other variation of this is the standard button.
    The benefit of a button is that obviously its known as a clickable element but the downside is the screen-estate and conflict with the App’s own features. Perhaps the button starts to look more like the application and that probably not what you want.

    This pattern is also now understood by everyone, even your grandmother. Specifically This is Netflix telling me, or even urging me, to find our what special gift is awaiting me when I touch the badge.

    In fact, Slack took it a step further by actually icon-ing messages as gifts 🙂

    Now in 2016/2017 has emerged “the Hotspot” what might eventually be remembered as helpful as the HTML <blink> tag! (they are usually more subtle than this).

    This new indicator is pretty compelling and is used as an alternative to throwing up a mandatory tip when you enter the page.

    The great cognitive benefit is that the pulse means:

    • I’m more important than a tooltip
    • Come back to me when you are ready
    • but you won’t miss me!

    Usually these pulses settle down to be simple dots, so our brain makes the connection that help is available without being distracted by the pulse.

    Deceptively simple

    One of my all-time favourite acts of design genius beats anything that Jony Ive came up with.

    Can you guess what it is?

    Wait for it…..

    The Facebook like is deceptively simple, but it punched directly through to human reward systems. That little icon has injected more dopamine into human blood streams than ever before!

    Simple but Powerful

    So little icons might seem lightweight or trivial, but the congnitive connection that matches “Job To Be Done” to a simple icon is both:

    1. cognitively efficient (remember our low-IQ users)
    2. efficient use of real-estate
    3. stands separate to your App’s functionality.

    The Magic of Launchers

    In summary, launchers are like a great waiter at a great restaurent….A launcher never over-services, never shouts, is available when needed and delivers the good.

    • Get the Job Done
    • Get out of the way
    • Measure the success
    • No Code

    UPDATE:

    One of our advisor’s Henry Cho* wrote me with the following insightful comments on the post:

    It’s touching on affordance and status indication.

    and

    you are saying that there will be a tension between overloading users cognitively and providing system status and call-to -action.

    and

    Be to clear and paradoxically the message can add to cognitive overload. Too subtle and the message is not conveyed to the user and engagement forfeit. 
    There is another element to add to this which I think you are well placed to support. Temporality, meaning the way that you signal can change over time, triggered by time or user interaction. 

    In these comments, Henry nails the key issues we aim solve about contextual engagement. I’m going to grill him more about what “Temporality” means to him 🙂

    ** Henry is a leader in Mobile UX and been involved in one of the most highly regarded banking applications. He’s currently Head of UX and AI at Upwire and you can follow him on at @hankatronic

  • Product Managers beware App Feature Complexity

    When it comes to adding features to your App, Mobile App Product Managers would be millionaires if they got paid each time as opinionated colleague or even the developers said:

    “how hard would it be…”

    and

    “can’t you just…”

    I was reading a post from Kris Gale, VP Engineering at Yammer, on the First Round Capital blog about “The One Cost Engineers and Product Managers Don’t Consider”. Kris was saying that Product Managers are the main culprit, but systemically the expectations are much broader, especially in small to medium size/maturity companies. I’ve been in teams of developers where the (awesome) “Product Manager” got the nickname of “Dr No” (punning on the James Bond villain) for fighting against “one more feature”.

    The problem for each new feature is the cumulative complexity of:

    1. Initial development and QA of the feature
    2. Decisions on targeting and visibility of the feature
    3. User education about the feature
    4. Measurement of uptake/engagement of the feature
    5. Fixing bugs and UI improvements for the feature
    6. Release management and announcing of bug fixes
    7. Skills transfer on staff turnover of developer and QA staff wrt this feature
    8. And if you are in an Enterprise:
      • Internal signoff and communication
      • Additional reporting, review for compliance, security
      • Lots of meetings!
      • Education and impact to customer support center
      • Probably greater staff turnover
    Ancient Product Manager grappling with the hydra of feature complexity
    Ancient Product Manager grappling with the hydra of feature complexity

    Contextual gives 3 great benefits to removing complexity:

    1. Completely REMOVE the complexity of adding user education to your App. By creating a layer of user communication without code, the Product Managers get autonomy to iterate and experiment without adding to complexity.
    2. Reduce the impact of #1, #2, #3, #4, #6 of actually implementing and managing new features.
    3. For Enterprises, radically reduce the meetings, reporting, signoff for getting user education done.

    So “Contextual” attacks the Progressive Onboarding challenge, not just for new features but deepening engagement for specific existing features that a segment of users have not engaged with.

    Here is a great quote from the FR post:

    Among the most dangerously unconsidered costs is what I’ve been calling complexity cost. Complexity cost is the debt you accrue by complicating features or technology in order to solve problems. An application that does twenty things is more difficult to refactor than an application that does one thing, so changes to its code will take longer. Sometimes complexity is a necessary cost, but only organizations that fully internalize the concept can hope to prevent runaway spending in this area.

    We believe the FR post makes important points from a development manager perspective but discusses one part of the problem: refactoring and engineering debt**. We’ve shown there are other related complexity resource drains that should be costed and solutions found.

    You can find the FR article here.

    ** there is a some UI comments that really can be summarized that Occam’s Razor should be applied go UI decisions.