Part 3 – User Experience
Introduction
In the previous blog post, we went into detail about how and where we define the use and purpose of the Autopilot approach. We talked about whether to use the pre-provisioning (White Glove) vs. the normal method of Autopilot.
Now with that being established we want to dive into the user experience. We want to understand how we can approach and tailor the user experience so that the process is efficient. Let’s follow the instructions on how to setup and access your new managed device.
How do we determine what the user experience will be
There’s many categories which we would process through to understand how the user experience should be.
Pace of the Environment
So to give more context to this, we take into account the kind of environment in which the organization is working in. This can actually be a critical area to investigate as we would need to understand the role in which the average user would play.
So for example, perhaps a high pressured environment, or perhaps a high pressure role may require users to be in a more “hit the ground running” state. Therefore it could be determined that a White Glove Autopilot could be a better fit if we wanted to have a multitude of devices already pre-provisioned and ready to go. This is especially true if you are wanting to out-pace knowing each device and its primary user.
Convenience of Setup
There is a convenience of course which comes along from a device being absolutely ready to go. But then there is also a flare towards the Autopilot approach where there is the personal touch towards setting up your own device! Having the visual of seeing what is happening during the provisioning of your new device can also add a nice touch when it comes to any new user or an existing user.
Believe it or not there is a stigma around when you are handed another device or a spare one. As they could be just another run-of-the-mill process where a device has just been simply wiped, checked over, and then presented as another device to be used in circulation. While that kind of process does still apply even within an autopilot process, there is a better visual for the user experience. This negates the feeling of being presented with a device in that manor. It really comes down to the personalized experience of each device.
Key factors of the personalized user experience
The real gem in terms of the whole user experience comes primarily from the enrollment status page. And these key factors aren’t specific to whether you use a white glove approach or not. It’s simply how the user goes through the process and if they are able to understand and follow whats going on when its successful – and even in situations where there may even be a failure.
For most who specialize in endpoint manager this is something you’ve seen a million times already. It’s not so much just the technical aspect that comes into play. Because once this is setup, yes it works, but how does it come across to the user who is then going through their device setup?
So the best way to outline and understand the relevance of each area we’ll analyze each option so that we can provide a technical point of view as well as the user-perspective point of view.
Show the App and profile configuration progress
Technical Point of View
This is really a toggle of whether the user can see the enrollment status page and the progress of each section before the device is built.
User Experience Point of View
The toggling of this setup plays a big part in the overall user experience. Without the status page in progress, it can be difficult for the user to know exactly what is going on. So they will simply see a splash screen stating that the device is being set up. Depending on the duration of your Autopilot deployment, the feedback could come back looking quite problematic.
Show an error when the installation takes longer than a specified number of minutes
Technical Point of View
Here we would state the maximum amount of time we would allow for an application installation. If it takes longer than a certain amount of time, halt the Autopilot process to show an error.
User Experience Point of View
For the users sake, it’s good to have an understanding on how long the average Autopilot deployment takes, which we will cover a lot more in depth on the next part of this series. Some applications, depending on their setup, can take a long time and this could be down to either the size of the application, or the duration of the setup. One example would be a Microsoft Office 365 install. It may not always be easy to determine the exact time, but you also want to have a fine line between what is too long and what is just about acceptable.
Show custom message when time limit or error occurs
Technical Point of View
We would specify a message to be shown once the duration has passed for the Show an error when the installation takes longer than specified number of minutes setting.
User Experience Point of View
The communication for letting the user know what is happening, whether in a normal successful deployment or whether it’s not, is important. The default message is fine where it says “Installation exceeded the time limit set by your organization. Please try again or contact your IT support person for help“, but how personalized is it? If this issue happens, who can the user get in contact with to report this issue? How do they obtain help especially if it’s their first day?
So if we chop this up, the part where it says your organization can be replaced with the name of your actual organization. And the next section which advises you to contact an IT support person, is where you would perhaps list the contact details of your IT Support/Helpdesk with as much information as possible. We have to consider that in a remote-user environment this information is very vital.
Something like this could make sense; “Installation exceeded the time limit set by CompanyName Ltd. For assistance please contact our IT Helpdesk on Ithelpdesk@companyname.com. IT Helpdesk Number xxx-xxx-xxx. We are also available on Microsoft Teams at ITHelpdesk“
Turn on log collection and diagnostics pages for end users
Technical Point of View
This allows for a button to be left which the user can click to collect the log files and diagnostics if any errors occur.
User Experience Point of View
This can be factored into the user experience, and also factored into the custom message section above. Situations where helpdesk can manage these types of incidents can require help from the end users. It helps them gather the log files so they can understand where the errors are taking place and escalate those issues up the chain where needed.
Only show page to devices provisioned by out-of-box experience (OOBE)
Technical Point of View
Here we specify whether we want the enrollment status page to be only displayed when going through the OOBE experience. Or, do we want it to apply to the user who first logs in as well as the OOBE experience – but not to any additional users that use the device?
User Experience Point of View
This is what every user would essentially see when going through a new device allocation anyway. Depending on your requirements, it may be best for each device to be company standard as well as assigned for that user. Multiple users on a device could make things complicated on an audit perspective while managing the devices through Intune. The primary user won’t notice much difference with this setting but it’s something to take into consideration.
Block device use until all apps and profiles are installed
Technical Point of View
This toggles whether we want to allow a device to not be able to get onto the network, as device ready, until every single application and profile is installed. This is shared alongside another setting down below which is the Block device until these required apps are installed if they are assigned to the user/device setting. We’ll cover this in detail later.
But until that setting is configured, every application assigned to this device, whether that be group memberships dynamic to devices not enrolled by autopilot, or simply by a group membership with various assignments will all need to be completed.
User Experience Point of View
This becomes a factor in the next part where we will dive into more detail. But for the user, this will just add a duration to the overall Autopilot process where the applications assigned to it, as well as configuration profiles, are applied.
Allow users to reset the device if installation error occurs
Technical Point of View
Allowing a user to be able to reset the device if an error occurs during the Autopilot process.
User Experience Point of View
Decision time now! The user has the ability to reset their device. There are many good reasons, and not-so-good reasons, for this to be available.
If we look at it on the good side, this option would be handy for users who know this process already. That ratio of users might not be bigger than those who are not. This could be used where someone from IT Helpdesk can accommodate this option within their troubleshooting and case logging. It could also be handy to have if the device itself is not enrolled into Intune by any other means.
On the other hand, it does allow a user to have the option to reset the device. But this is why the user experience perspective is so important here. Because the right configuration and custom message can stop a lot of those potential issues from happening.
Allow users to use device if installation error occurs
Technical Point of View
This will decide if we will allow a user to still use the device if an installation occurs. Depending on your configuration this could have issues in going against conditional access rules if set up. A potential non-working company-standard device would be on the network and causing more issues.
User Experience Point of View
The user would most likely get in contact with support to acknowledge an error of an application which failed to install on the device. This can have a big impact based on the role they play within the organization. For completeness it’s maybe better to keep the default option of No for this, but if you are happening to use multiple ESP (enrollment status profile) pages, then maybe priority on some applications can be resolved with alternate required deployments.
Block device until these required apps are installed if they are assigned to the user/device
Technical Point of View
Perhaps the most interesting part to the technical point of view. We can decide which applications we would consider core or mandatory. This is also an area we’ll dive into more in the next part of this series.
User Experience Point of View
The user’s point of view will be more post autopilot once all of the necessary applications are ready on the device. But the most they would experience would be the duration of the overall Autopilot experience.
Visual of the Company Branding
From my experience, this is a slightly overlooked setting. This defines the overall visual difference between an out-of-the-box configuration for endpoint manager and the whole personalized experience for the end users.
The areas a user will see the most once managed through Endpoint Manager will be:
- Sign-In page before Autopilot Takes place
- Company Portal (Windows App or Web Based)
These are the same areas in which the user would also see the company branding – and none if it’s not set up.
If we look at Figures 1.2 and 1.3 we can see how we add the branding. You can see how they will show, whether that is just the logo or the logo and organization title. But then areas such as the mandatory information, which they will see around the support information, is just as important. The users need to know where they can obtain this information in case anything happens.
Next on Part 4
On the next part of the series we will dive more into the duration of the Autopilot process. That will be an extension to the current part of the user experience. We’ll analyze and reduce the time to get a device ready. Until then, reach out to us via email or phone if we can help.
