hplogo2_tcm_184_2552055.jpg

HP Support Assistant 9

Lead UX/UI Designer

Overview

HP Support Assistant serves over 62 million customers worldwide with 16 million monthly users. New requirements called for the application to be updated to Microsoft's Universal Windows Platform environment, and this technology change was seen as an opportunity to improve the user experience and update the design. With limited resources, very strict technological constraints, and a 6-month release schedule, recreating this application took the efforts of a dedicated team of people I am proud to say I led.

Hats Worn

⛈   Concepting

🗺   Wireframing

👂🏽   UX research

♻️   Prototyping

💬   Copywriting

🔸   Animation

📢   Visual design

Deep Dive

HPSA 9 has not yet been released, so I am limited in what I can share. The screenshots below are from the previous version and are only there to help illustrate some of the UI problems I was trying to solve.

 

Seriously - this is boring stuff. You've been warned.

Initial Review

HP Support Assistant was a mess. The design team was being recreated from scratch. The majority of the design work was being done by an overworked team of engineers with no focused effort on the user experience. The most recent user study was 6 years old.

 

With two weeks to deliver my first prototype, I postponed true user research to a more luxurious time. I started the research with myself. I had no experience with the product and considered myself a good potential user. Here are some key points I thought needed to be changed in the app:

HPSA-support

The design was not credible.

 The application was not responsive. 

The app was very slow.

The information architecture was scattered and not well organized.

Persona Creation

I began with three personas, based on a favorite TV show.

 

'Michael' was a computer beginner and would most appreciate HP's guided troubleshooter resources and virtual assistants.

 

'Pam' was more advanced then Michael but still would need help doing the more complicated case creation and warranty management.

 

'Oscar' represented the advanced user who would most appreciate the ability to customize how often HP sent popups to his device, and whether or not he could directly access human support.

 

With these three skill levels in mind, I went on to define how a user would most commonly use HP Support Assistant.

c05985036

Information Architecture

With our users defined I went on to define the application's architecture. Where do these amazing features go and how can I ensure they are easily found by all of our wide variety of users?

 

I defined user flows for the following common device types: laptops, desktops, and printers. From that starting point, several commonly experienced support scenarios. User research would later inform the most common approaches to getting support on the HP ecosystem, but for the early 'pitch prototypes' I had to rely on my own experience, and what I could gather from testing my coworkers.

hp-support-assistant-3

Competitive Analysis

One thing I did get early was a competitive analysis. For legal reasons, I can't be specific with who we compared our product with, but I can tell you HP was not far behind in the Windows support sphere.

 

We gleaned some ideas, but mostly used our competive analysis to validate the features we were already pushing.

Wireframes

Using the organization we had created from the previous steps, I went through and sketched out the major screens of the application. This was so that we would have a good idea of the scenarios our design would have to adapt to before we established what colors, font sizes, navigational elements, and content layouts we would use.

 

While some would advocate the locking of a visual design before beginning to wireframe, this only works with an established brand. Because HP was in the middle of a brand update, we didn't have quite so solid a foundation and had to adapt the standards for some of the new scenarios we were facing.

 

While I would recommend having these branding decisions made before a interface project like this one begins, that isn't always possible. Adaptability is the only thing that will keep your project on course in that situation.

Visual Design

Once we had defined the product we wanted to deliver, organized it, and compared it with other solutions already doing well in the space, I moved on to the visual design of the product.

 

This included comparing the design standards from Microsoft (in this case the UWP standards) and the design standards HP required. I also compared with Google's Material Design, and Apple's iOS standards, as this application was expected to bring together all platforms under one support experience.

 

Because of technical limitations associated with the Cordova ecosystem, some of our more ambitious visual treatments had to be abandoned later on. However, our original mood boards focused on a bright, sharp, and glass-like interface.

Prototyping

With our basic wireframes established and the beginnings of our visual elements defined I began work on the first low fidelity prototype. In this version, like in all my first prototypes, I worked only in black and white to keep the testers' and managers' attention on the flows and page layouts.

 

Once consensus was reached on the foundational elements we introduced our icons, colors, images, and shadings. This kept unimportant discussions on the specifics of a particular icon to a minimum while keeping the focus on the basics.

 

 

User Testing

The users we tested all experienced similar things to what I had seen on my first day in the app. They reported the popups looked like those from common viruses, the design was hard to navigate, slow, and features were buried.

 

With the new hi-fidelity prototypes, we were able to test in earnest our hierarchy and navigation while delivering an experience that was virtually indistinguishable from what the live application would look like. When completed a testable prototype for UWP would have on average 200+ screens with multiple states and settings that allowed the user to play with the app as if it were their own. This allowed us to tweak individual elements and relay our findings to the development teams as they developed the main sections of the app.

Leave a Comment