When you store user data based on logins to your software, you’re in a position to dive deeper into contextual embedded help. User data can drive your embedded content, providing more relevant information for each user. In this article, we’ll talk about using data derived from authenticated users to design personalised user content.
Authentication refers to the login process in which each user is identified with a username and password. In recent years, we’ve seen more software companies adding contextual access to traditional authentication methods.
The information gleaned using contextual access can also be used to drive content.
What is user access management?
Let’s define each type of authentication generally.
Traditional Authentication: Users are created and assigned roles as well as a username and password. Users are given access based on the authentication of an assigned username and password. Each role has a predefined level of access.
Contextual Access: Access requests are granted or denied based on user context. Also referred to as Adaptive Access.
What factors determine contextual access?
Theoretically, any type of information you can gather about the user could be considered during authentication. Commonly, these factors can include geo-location, device verification, proximity, IP address, location velocity and time.
What are typical use cases for contextual/adaptive access?
Typically, companies will use contextual access management to reduce risk by determining an overall risk factor. In an environment where employees work remotely or must access sensitive data outside of company walls, contextual access management allows user context to determine risk.
You can see an example of this when you try to sign into your Google account while traveling. If Google notes that you are logging in from an unknown device, an unknown IP address or a geographical location that is different from your usual access location, Google may ask you to sign in again using your password. You’ll usually get an email from Google notifying you that your account was accessed under unusual circumstances.
Contextual access management in user journeys
We’ve talked a lot about user journeys, especially in relation to context (and personas). Delivering users the right information at the right time implies knowing the user’s context.
For a discussion on context, see Contextual Information for Software.
Using the same data you gather for contextual access, you can design software help that delivers a more personal user experience. Think about the things you can determine when a user logs in to your software.
First, you know who the user is. You can probably call them by name. While this may seem simplistic, calling users by name is the beginning of developing loyalty.
You may have gathered other information about the user in the registration process. Leverage this information in software help to provide a more personal experience.
Using authentication, you can know whether this is the user’s first time, fifth time or 100th time logging in to your software. The information you deliver should change over time, based on user experience or other factors affected by the number of logins. You can also know how long it’s been since the user’s last login. Such information can inform your content.
Using APIs to gather user context
Depending on your system, you may need extra tools to gather information about users (with their consent, of course). Various products have APIs that allow you to connect your authentication process and gather additional data.
For example, some APIs allow you to enhance data based on users’ social activity. A sentiment API will allow you to monitor negative and positive user comments in reference to your software.
The Google Awareness API for app developers gathers basic context based on time, geo-location, place and place type (such as a business name), activity (such as motion), nearby places, headphone use and weather conditions. Maybe your software has important information to share on rainy days!
The Orion Context Broker is an open-source implementation for the FIWARE API. The context broker allows you to manage the lifecycle of context factors. You can query real-time data from public or private context providers. For example, you can query traffic information, temperature, water currents, stock prices, or any system that provides real-time data streams from sensors or data sets.
Using triggers to drive content
Once you know your user’s context, think about triggers that allow content to be personalised to the user’s situation.
You’ve seen a trigger before. When you try to delete something from an app or software, you get a message that asks, “Are you sure you want to delete this?” In this case, the simplified context is that a user is deleting something, and the software recognizes this trigger and sends a message to the user.
Imagine a more complex trigger, coupled with user access management:
- A trigger returns TRUE when the user clicks an INSERT operation; the context reveals that the user is a first-time user and may need some onboarding help to understand the functionality of the operation.
- The trigger returns FALSE when the user clicks the same INSERT operation; the user context reveals that the user has been using this software every day for 3 months and has used this operation 10 times. This user probably already knows the function of the INSERT operation.
Let’s take this example one step farther:
- The trigger returns TRUE when the user clicks INSERT; the context reveals this authenticated user has logged in to the software 5 times over a one-year period. The user is not ‘new’, but logins have been infrequent. At this point, you’ll want to decide if the trigger should return TRUE and deliver some basic info, or assume the user doesn’t need this type of help.
An example using sensors:
- Let’s say you’ve developed software specifically for boating enthusiasts. Using your software, a user wants to plan which days she’ll go out on an excursion and what route she’ll navigate. Your software can gather real-time marine data of water currents, wind speed and direction, and wave swell, and couple this data with personalized user data. Your software tracks the user’s geo-location and based on data they entered when signing up for your software application, you know the boat type, boat size, motor size, and other details that would affect marine navigation.
Design personalized user content using edc
Admittedly, it’s going to take some writer and developer collaboration to design embedded help content based on user personas.
And edc is here to help.
Using edc, writers and developers can log in to access the same content, add IDs to connect content to the software UI, add screenshots for clarity, comments, and links to related content. Embedded help with edc addresses the users context, and related links to online help allow the user to go as far as he or she wants to go in search of information.
Of course, you’ll want to spend some time developing user personas , planning how you will address the context of each persona, and mapping your content [link to article] for each persona.
In our next post, we’ll look at how YouTube designs contextual help for users and how we see taking it one step further.
