What was the latest app or web service that you launched for the very first time? Was the experience memorable, engaging and compelling, or did you feel frustrated by being forced to learn yet another app with its quirks? Whether you continued using the app or not, that first launch was your first-time user experience (FTUE).
A good first-time user experience feels like listening to a refined elevator pitch: the immersion is so well built that you instantly, almost intuitively, start feeling excited and committed. Well, that’s at least what it should feel like.
A controlled and well designed first-time user experience has two major goals:
to give a first impression tempting enough to prevent the user from closing the app
to offer engaging content that lures the user to proceed.
There are, of course, many other direct and indirect goals, but none of them will ever be reached unless these two primary requisites are filled.
User motives during first-time use
Whether you are building a mobile application for the consumer market or a web-based tool for a defined group of professionals, same basic principals apply. When using any application for the first time, users are probably pondering these questions:
Where am I? Is this the application I wanted? How do I get started?
What can I do here? How does it work? How is it beneficial to me?
Where can I go from here? How can I accomplish the tasks I want to perform?
Let’s dig deeper into each one of the questions to see how they can be answered with a well designed FTUE.
While starting the app
The launch screen should clearly state what the application is all about. A brand logo or some other distinct identifier can be used to create reliability and familiarity. A short value statement or a tag line confirms that user is where they meant to be. If the value statement doesn’t resonate with the user’s expectations, it is unlikely that the user will continue any further.
The launch screen should also be the place to communicate any legal matters, such as terms and conditions. Providing transparency to any prerequisites as early as possible prevents unwanted surprises later on.
A well designed launch screen creates the first step of commitment: “I agree with the value statement and accept the terms. I want to continue using the app.” A clear call to action then seals the deal and carries the user experience forward.
Many apps use a so called onboarding phase to showcase the basic functionalities and main benefits. Onboarding can be implemented in a couple of ways, either as a pre-introduction before getting to the app or later on during the first user activities, in context.
Being too excited about showing off the nifty interactions you’ve created can cause user engagement to subside. Instead of creating immersion, showcasing complex interactions or parts of your app that could be useful instead of resonating with the user’s real needs causes disinvolvement, boredom and frustration. After all, the main incentive to use an application is to benefit from it in some way. Whether it’s a user friendly user interface, efficiency or some other benefit, making it as clear as possible from the start will increase attraction.
A good onboarding phase can also improve user conversion by activating the user before the actual use starts. Some apps, Foursquare for example, activate the user with a simple questionnaire about user’s interests. Questionnaire results can then be used to tailor the content to match the user’s interests. While seemingly just keeping things interesting, a well placed interaction creates enough time investment for the user to commit.
Regardless of the chosen onboard design model, it should always include a quick escape route. Just as there are people who want to attend the swimming classes before going to the pool, there are also those who will jump directly to the deep end to see how it goes.
While using the app
The FTUE is all about control. If we can estimate the user interactions and behaviour, we also have better tools to assure that everything works as planned, and we can prevent users from getting lost, or from losing their own sense of control. This subject easily extends way beyond the first-time use into general user experience design. There is, however, one very important thing to consider when user steps from onboarding phase into the application itself: managing app permissions.
Asking for app permissions
Any respectful and well built app always asks for user permission before performing an action requiring access to the device or using any personal information - right? Apps should also explain why they need the permission in question. Of course this is not always the case, and the reason behind it isn’t necessarily as much from 1984 as you might think.
Imagine a scenario: you’ve built an app with this clever personalisation feature which requires user location information. The user launches the app for the first time, the app opens the OS dialogue to ask for permission to use the location information. The user sees clearly why this is necessary for the app to function and presses “I agree”. Everyone will live happily ever after, the user gets an app that works as designed and the project team doesn’t get crap from building an unusable functionality.
If, however, the user selects “No, I don’t agree”, things go south. The app doesn’t work because the location information is missing. The user doesn’t necessarily see the relation between the unusable feature and the asked permission. And on top of that, the decision is final, and the app cannot ask that same permission again because it was managed straight away with the native dialogue component. You get only one chance with those.
Two solutions come to rescue. The first is self-evident and clear: make sure that the permission is asked in context, during an activity that is directly related to the permission asked. Even with the most self explanatory description, it is still likely that some people press “no, I don’t agree”.
The second solution is a bit more complex and requires some tinkering, but it has been proven to improve the conversion rate significantly, as explained in this TechCrunch article. The permission routine is started with an educational pre-permission dialogue that pops up before the actual OS dialogue. Educational content in the dialogue emphasises the purpose of asking the permission, thus deepening understanding and creating comfort. To have a custom made dialogue before the actual OS dialogue also offers a second chance of asking the permission again, even if the user isn’t convinced with the educational content the first time.
Start building your own FTUE
When designing FTU experience, it is important to plan the onboarding content to suit specifically your application the best. Benchmarking is always a good starting point, and there are many great applications to learn from, my personal favorite being Duolingo. Still your application has it’s own, unique features, benefits, personality and tone of voice. Careful content planning ensures that the user experience continues seamlessly when onboarding is over.
Most important things to consider while designing your first-time use experience:
- Craft your value proposition to match the content, consider the application’s brand and the tone of voice
- Validate what’s relevant for the users and showcase only the most beneficial features
- Demonstrate functionalities in an interactive way, concentrating on the interactions that are anticipated as the most obvious pain points