We are involved with Product Managers globally but we’re in a Sydney startup community of a few hundred companies in one building! Its an amazing place of learning and serendipity. Some of these startups are building the future and this short series of posts dives deep on recurring challenges we hear.
This first post is a fireside chat on Product Market Fit I did with Elliot Ng – Director of Product Management, Search at Google and a veteran of 3 startups. It was a great talk and he brought a lot of wisdom to the night.
In this clip we explored challenges of getting early stage product market fit and the role of founders – too often these days there are startups with a solution looking for a problem, Elliot explains the best case:
Here, Elliot covers the scenario where true disruption, or market transition is occurring and even the founders don’t have subject matter expertize.
And here is the ideal founder situation where one member of the team has deep industry experience and this informs the startup’s mission right from the start.
In other words this is called Founder/Market Fit!
As Steve Blank would say – “Get out of the building!”
Here Elliot describes how they rapidly validated their product via pitching and correlating across multiple prospects and existing customers.
And lastly for this post, discusses how focussing on hypotheses that confirm whether you have a business or not is the priority.
In the next post, we’ll look at founders as product managers and the best ways to not get deluded about your product.
Mel from Canva posted this week about their journey to a $1B valuation. It’s a long but faniscating read that overrides any myth about being an overnight success.
One mind-bending takeaway from the post is this quote:
“In order for Canva to take off — we had to get every person who came into our product to have a great experience in a couple of minutes.”
OK, nothing mind-blowing about that on the surface, but
“…So we spent months perfecting the onboarding experience paying particular attention to users’ emotional journey.”
Clippy was Microsoft’s “Office Assistant” and became universally derided. Here are 5 reasons why people hated Clippy:
Obtrusive – power users hated Clippy because it had patronizing suggestions.
Distracting – the image at right (without the gun) is literally Clippy looking bored and wanting you to stop your job and pay attention to it. As we’ve talked about before, JTBD (jobs to be done) is how a product manager should think of a user’s flow
Always there – he(?) sat on top of Word/Excel taking up screen realestate
Killed your flow – this hilarious Quora answer lampoons how it would take 30 seconds to hijack you writing a sentence.
How to be unobtrusively useful
We’ve blogged before about how tips need to be unobtrusive. In particular if a web “desktop design” approach is shoe-horned into a mobile App, the patterns conflicts with a user’s “Jobs To Be Done” (JTBD) imperative.
The best way to deliver unobtrusive user guidance via tips is:
Contextual
Unlike Clippy, tips should show when relevant to users.
Audience: We have customers in Health and Telecoms that have older customers that prefer guidance whereas Milenialls will click/touch/swipe a thousand things until it works. I’m not being “age-ist” – its just a fact.
Trigger: Apps should only show the tip to the correct audience and stage of user journey. If a user has already user a feature, then they shouldn’t be seeing tooltips explaining what they know. If a user is about to commence a complex task for the first time, then offer to help them!
Simple & Distinct
In my recent popular article at uxdesign.cc, the idea of “Cognitive Overload” was discussed and how App Product Managers should design to reduce this overload. In this article we suggest that launchers and tips need to be perceived as a layer on top of the application but not compete for screen real-estate.
In this simple tip, Youtube taught me something new – that I can pinch the screen. It obeys two simple rules that we think are important:
Get the Job Done (JTBD)
Get out of the way
Note how simple this tip is, it can be dismissed by simply touching.
Also, these two Youtube tips are similar but also point to a clickable screen element (the bell button and the drop-down filter). Notice how “cognitively” the tip looks very different to the rest of the App. Its very easy for the user to distinguish the tip from the App content – in fact they’ve interesting used the same colour in round badges over channels as discussed in my previously mentioned post.
The lesson is that Google: one of the largest tech companies on the planet has figured out that this design pattern of: simple, distinct, coloured tips converts their users to adopt the recommended features. Google would have massive teams of analytics, data scientists to come to that conclusion and we should take notice!
Data Driven
Which is a nice segue that puts substance to our first recommendation of “Contextual”. All tooltips need to justify their existence and Product Managers need to know what uplift they get on feature usage, engagement or other success metrics. We’ve written otherposts on A/B split tests to verify that your in App education is data driven and working. Our two main points are:
Measure the success of tooltips – we’ve seen uplift range from 20-80% for new features. Pick your metric and compare against your Apps default state.
No Code – using tools like Contextual, the ability to deploy tooltips is codeless, no more Appstore releases or fighting for resources on the Product Roadmap. This is critical, you need to iterate fast!
Significant New Features
Its worth mentioning a slightly different style tooltip that Google also shows for significant feature additions. Many Apps will throw this up as a popup or carousel page when the user opens the App – but that’s lazy and google does a great job here of contextualizing this new feature mid-task.
The inclusion of title, icon and “GOT IT” button are simple but significant to catch the users attention that this is significant. In particular, the use of a button allows the Product Manager to use analytically see who dismissed by the button or clicked elsewhere (or outside) the tip. In Contextual, this gives measures of “Accept” and “Reject” to measure how positive the response was for the tooltip.
Summary
Clippy got it wrong but was a brave piece of help technology for products (Word and Excel) that had become very feature rich (bloated?) and complicated to use. Microsoft had to solve the problem of surfacing features and their approach is what you should avoid – especially in Mobile apps!
Clippy
Best Practice
Obtrusive
Distracting
Always there
Killed your flow
Job Centric (JTBD)
Simple
Contextual
Get out of the way
I received a question from a recent uxdesign.cc post on Cognitive Overload in mobile app design. (It was a variant of my last post here).
Has Material Design already answered the need for reducing cognitive overload?
Material Design is a unified system that combines theory, resources, and tools for crafting digital experiences.
This initiative from Google (and gift to the world) is widely embraced but Apple is sticking with their own Human Interface Guidelines (and the battery efficient Flat Design). I won’t go down the rabbit hole of comparison but predictability, elegance and delight in design are all great cognitive tools for reducing negative human-computer interactions. (Also it didn’t hurt that Google clobbered Apple by having wide-spread tools and libraries for both web and mobile).
Material Design’s strength was sticking with a cognitive design balanced with device performance, processing power and battery efficiency — an acknowledgement that human perception uses light to interpret the physical world.
BUT — where Material Design stops short is that it solves “the current moment”. Its really a design tool, NOT a user experience tool.
It does not consider the user journey and the contextual nature of a design for the current user’s needs.
Material Design’s Approach to Mobile Tooltips
They take a well-meaning of hiding tips (similar to desktop where its hover that delivers the tip). The advocate the long-press (press-and-hold).
The problem for long-press is that:
a) mortals don’t know that gesture, only UX nerds.
b) confused use. Historically long press) gesture on a mobile devices mimics the secondary button press on a computer mouse. Traditionally it gave you the same alternative options as the secondary mouse click on a computer. So long-press for tips is competing with another function. Frankly, allowing the user to access “less, commonly used functions” is a far better pattern. “Help” could be one of the options provided.
c) gesture dissonance: the user has to drop their uncertainty of clicking the button in order to learn what the button does — wtf?!!!
d) Perhaps the greatest challenge is that nobody knows how to communicate it (contrast with the “Like” button that was self-marketing). Swiping could be illustrated in a sketch and also mimicked existing human behavior of swiping or dismissing something no longer needed.
e) not many apps use it. I long-pressed a bunch of Google Apps and can’t get a tooltip to show. Naturally if Apps don’t use it, then user’s won’t use it.
IOW — Long-press for mobile tips are dead. Sorry material.io 🙁
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:
cognitively efficient (remember our low-IQ users)
efficient use of real-estate
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
We use cookies to ensure that we give you the best experience on our website. If you continue to use this site we will assume that you are happy with it.OkRead more
