Here’s a behind-the-scenes look at how we tackle UI & UX design problems in Discovr. One issue that’s been especially tricky to solve is how to explain different gestures and actions in the app.
We’ve tried using several different ways of displaying ‘help’ information to solve this problem. Here are our experiments:
1. Static Help
This was a static help screen that slid down over the main map screen. The screen was triggered automatically after you did your first search in the app and showed the various gestures and functions. It looked like this:
Result: This approach gave a good overview of the main help functions, but it felt really interruptive when it slid down over the screen. Instead of a smooth experience, you were confronted with help that bullied it’s way onto the screen.
To fix this, we tried modifying the timing of the launch trigger, as well as modifying the trigger itself (only show the help screen after a certain action etc). None of these approaches worked – it always felt jarring because the help screen would take over the app just when you were least expecting it.
2. Overlay Help
This showed the gestures and actions as a handwritten overlay. It looked like this:
Result: This approach meant the help was separate from the interface, but it didn’t work well over the map screen (if you expanded a node on the map then the help overlay was immediately out of whack). It also meant I had to draw new overlay screens for every combination of devices and resolutions every time we changed something in the app.
3. Callout Help
Our third attempt was to use ‘callouts’ to display help information. We named each callout with the name of its source screen to help orientate you with the different screens, and the callout itself was filled with contextual information. It looked like this:
Result: The callouts worked well, and it’s something that we’ll continue to use. It’s particularly useful because we can display information that is relevant only for a particular screen. The callout approach also travels well when we add more screens or functions (the text can be changed directly in Xcode or on server side, rather than needing to design new graphics every time).
4. Baked In Help
In Discovr Music v2.0 we developed a whole new style of help that is baked into the interface itself: the map itself shows you which gestures you should try next. The first time you search for an artist you’ll see something like this:
You’ll see a bright red node with “Tap Me” overlaid on it, prompting you to try that gesture. If you do tap that red node, you’ll see the result of that gesture (which is to expand that artist node and show similar artists around it).
After that, the next gesture will appear and you’ll see a red “Double Tap” node. If you double tap that node you’ll see the result, which is to go to that Artist’s page.
Lastly, you’ll see a “Tap & Hold” node in red. If you Tap & Hold on the red node, you’ll see new functions like adding songs to your music queue, or playing similar artists.
Result: This baked-in help approach works really well. The red nodes are distinct from the normal interface, but they’re also a part of the app itself, making the relationship between gestures and functions clear. The other benefit is that we end up with a basic design language that a user can recognise and understand (if they see red in the UI they know it’s related to help).
The baked-in help style is used in Discovr Music v2.0 to highlight new gestures and functions. Try it out on Mac or iOS and let us know what you think!
PS: None of us are designers, so if you’re a killer designer and you’d love to be involved in Discovr, we’re hiring.
- Dave is Founder & CEO of Filter Squad. Follow him on Twitter: @davidkmckinney
none of you are designers? could have fooled me!
+1 to fools
Design is about solving problems! You guys seems really good at it!
Besides I really miss one thing from your app (I was asked to leave a feedback on some service support from twitter but damn i forgot).
I really miss the possibility to hear a random preview on an artist directly from the node view…
going down deep into the details to listen to something and then back again… to me (and I’m a damn lazy guy) ..it’s kinda of annoying…
well
anyway good job I can’t wait to see try your in app tutorial!
Have you checked out version 2 mentioned above? You can tap and hold (iOS) or right click (mac) on a node and automatically preview the artist, or it’s similars.
Looking for designers? What kind? Post it up on the hiring page, I’m interested in the position’s details!
Ahh thanks for this x 1000! I’ve been on a UX kick lately and It’s great to get a non-designer perspective. If you don’t mind, I’ve shared this story with my newsletter today (Posthuman) http://eepurl.com/hBZdA because I think it’s really important that my readers start learning and understanding UX (many of them don’t get too much exposure to it).
Dan
Email me.
OK. I generally like baked in help, but the implementation above is still a bit confusing for me (the user) who has never seen this app before.
1. The Tap Me circle, it makes me think “OK, should I tap on the orange circle? or the one that this circle is pointing to? (the artist circle connected to it by a line).
2. The next thing I wondered (as a user) was, “well, if they meant for me to tap the orange circle, then which artist will it display? I assume the one that is connected to this orange circle. But what if I want to see the information contained in one of the other circles? Why aren’t there orange circles attached to those? Perhaps only allowed circles can be tapped (hence orange circles for those)?”
That was my quick reaction from looking at the screen shots.
Other ideas:
1. Your overlay can be less annoying if the app started up with the overlay, and it included a toggle for “Don’t show this help on startup again”. A single tap to the overlay would dismiss it. After a couple of startups the user will likely tap the “Don’t show again”.
2. Don’t EVERY show help or overlay until your app has determined that the user hasn’t figured out how to use it. For example, if after a X number of uses (or X minutes of use) the user hasn’t Single tapped a circle, then you should inform them pretty quickly (honestly the default interface is very intuitive in that I should “tap” on those pretty circles, so only the most neophyte user may need to see that particular help instruction. Likewise you would build in some internal timers to detect whether a user has failed to try the double-tap or tap-and-hold options, and only after those thresholds are exceeded would you gently tell them about that option. Perhaps on next startup or after a brief period of idle time after the threshold has been exceeded. Perhaps a phased in smaller overlay with just a single tip: “Did you know: If you tap and hold then yada yada yada”.
3. Another option is to show the help if the user is tapping on the UI anywhere outside of the circles, perhaps after 3rd or 4th tap to avoid false positives, i.e. user is “hunting” for how to use the app but isn’t sure how. Kind of gentle help once they’ve stumbled
for just a bit.
Just a few quick thoughts.
Gorgeous. I wish I could come across articles like this more often. This coincides with my upcoming piece about affordance in touch interfaces and this is definitely the perfect example I was looking for. This also backs up my idea that contextual, actionable and progressive help is the only way to go in order to make touch interfaces more usable.
Great job guys!
I’ve struggled with this issue on my projects, and I also favor the baked-in approach. As a consumer, though, I’ve found that having clearly marked “undo” functionality is most helpful in my exploration of new apps. As touch screen gestures are becoming more ubiquitous, even my older relatives are skipping reading static and overlay help on their devices in favor of exploratory learning.
A variation of option 2 is the ‘example animation’. Users lose the direct interactive learning of option 4, but are still provided an audio-visual learning mechanism.
I agree! None of you are designers is crazy talk! You guys are definitely designers. Perhaps those you are comparing yourself to who call themselves designers are not designers, because this is definitely design going on here.
Great post. Hands-on approaches are bold and remarkable, and I very much like what I can see of your product.
I was wondering how do you know which method worked well? Did you test it with real users or relied on analytics? Any other method?
(PS: I’m a UX/Visual Designer with 12 years of experience, let me know if I can be of any help).