HP Support Assistant Mobile
HP Support Assistant Mobile, developed under the codename ‘Project Sanctuary,’ aims to bring the support tools offered by the desktop application to the mobile space. It was to be developed using Cordova, having a single code base for both iOS and Android. Originally there were efforts to develop the desktop application from the same code, but the different experiences that were offered cause too many issues and the project was scaled back to a more manageable iOS and Android only release. HP Support Assistant Mobile is scheduled to be released in November of 2018.
As this product has not yet been released I am not yet free to release any final designs. The images below show some steps of our process but are not indicative of a final design
Hacky front-end dev
Working from the desktop app HPSA 8.3, my first task was to define the MVP for a mobile support application. With a wide range of features and an information architecture that had evolved over several years, there was not a clear a path to mobile from the desktop application. I chose to force a device-centric support experience as support, in the minds of a user, will always be based around a specific problem on a specific device. From there I organized the support options around defining specific issues that the device can experience and only presenting solutions relevant to those specific problems.
A key part of our process and one which informed many of our decisions was our competitive studies. We made a special effort to learn from the wins and losses of organizations already operating in the mobile space. Confirming design decisions, such as our device centric IA, and discovering new best practices, such as the omnipresence of virtual support options were only possible through the use of competitive study. One of the key resources always available to a design team is the designs already in the space they wish to join. One of the key marks of an innovator of design is whether they can learn from and adapt designs that someone else has created. There is never a reason to reinvent the wheel from scratch.
Responsive design was something that HPSA 8.4 was trying to do. It, however, was not mobile first. The Windows application had a minimum width that allowed some customization of fonts and window size but was not fully responsive. Project Sanctuary revealed how far the app and web resources had to go before it was truly responsive. I was able to design and code templates that gave the development teams starting points for translating the current resources to a more mobile first.
With the MVP defined and an IA to match the mobile environment, I began the wire-framing phase with paper sketches. I find these preliminary prototypes are best suited to the minimal investment required to produce a paper sketch. Once I have the design outline it is an easy step to translate a sentence outline into design sketches. Getting the ideas down on paper make the first digital wireframes a very simple step. Sketching and seeing a design take shape also helps to identify key features or requirements that may have been otherwise missed, and allows for ideas to be validated by the design team.
The team I was working with was most familiar with the prototypes generate by Axure RP. I was able to learn the software and generate full prototypes a day into getting the application. These prototypes were what the majority of our user testing was performed on. Changing copy and icons are much easier in a web prototype than in a native application.
An important part of our process was testing our application on users. This informed many of our decisions and validated others that we were unsure of. The importance and priority of specific details can only be confirmed by the users. Our user validation included fortnightly tests that were both moderated and unmoderated, scripted and exploratory. This paired with constant testing within my team gave us high confidence in how the application would be received and used.
High Fidelity Prototypes and Design Language Definition
The issue of what design language to follow was a special concern. At the beginning of the project, we were expecting our design to be used on iOS, Android, and Windows 10. While we eventually removed the Windows experience from our supported operating systems, we still had to make sure the application was identifiable as an HP product. Because of our technological constraints, we would not have separate designs for each mobile OS, but had to have a single UI that would work on both systems. We eventually created a set of custom UI elements taking sizes from iOS, positioning from Android, and color and font weight from HP’s standards. For navigation, we suggested a bottom menu, however, a hamburger menu was later decided on by management. The scalability of the hamburger menu allowed a gradual release of a constantly expanding feature set.
Because we were bringing a new product to market, the design resources that teams typically use were not well suited for our application. The iconographic standards did not scale well to what Android and iOS users were accustomed to. I believe the requirements my team defined helped to contribute to the update of the HP design standards that resulted in HP’s latest design language.
Bringing together the vast resources and widespread teams involved in the HP support experience into a single mobile application was a challenge. Throughout our design process, we spent considerable time and money in user testing. Scheduled every two weeks we supplemented our testing with daily evaluations of the previous days' designs and discussions on usability.
I am proud to have worked with such a talented and dedicated team and thankful for the opportunity to continue to contribute to the first fully comprehensive mobile HP support app.