HP works closely with other technology giants like Microsoft and Google. As the manufacturer of the hardware where the operating system is located, we sometimes run into challenges that are a result of engineering choices by these partners.
Summary
Microsoft employed a technique on lower power devices that would be most impacted the “boot storm”… the first time a device powers up.
This was to force any application that launched during this time period into a smaller experience as to make the most possible resources available for all applications. This was self-serving on Microsoft’s end as they wanted to make sure they had the platform to launch their web browser and get a user started with that experience as soon as possible.
The onboarding and welcome application we were designing had some very specific (and contractually obligated, BTW) requirements about which content showed. These requirements were necessary to fund the project and team.
With the edict from Microsoft that we had to fit our experience into a constrained smaller window, I set to work with our User Research lead to identify ways we could guide the user to expand the viewport and receive the best possible experience.
Framing the problem
- Our desired first-use experience was 3/4 to full screen
- During first boot, Microsoft limited our size to about half (500dp)
- This might force important content “below the fold”
Strategy
- Conduct User testing to identify how we might:
a) encourage users to expand the window
b) solve for a different responsive size
c) identify this as a pattern for other auto-launched applications
Tactics
Using a survey and clickable prototype(s) on Usertesting.com, We tested three possible solutions: A) Show a screen that included a banner which encouraged enlargement.
The second group could see a similar experience, but with cropped content instead of the banner affordance.
Third option, the layout was responsive to show content that fit (width-wise). Here we wanted to see if the user wouldn’t adjust the screen if there wasn’t content being limited by the viewport.
Results and choices made
This was the final choice made by the product team to help solve this issue. It was both the cropped experience and banner affordance. Note that the banner was modified to be less of a danger, and more of a warning.
In the limited testing we were able to accomplish, we saw that a cropped experience with the banner was the most consistently enlarged.
This gave us the opportunity to feature enough content and encourage the user to experience our application in the best possible light. Additionally, we were able to meet the business needs of showing the right content at the time of first launch.
Afterward and follow-up:
Given technical challenges with the final implementation, and continuing testing with the users, we determined the banner was not as needed as other enhancements to the application, so it was dropped.
The additional technical challenges of limiting the initial view to a cropped experience further made the experience feel broken. The app is now always responsive.