Header-wider.png
Scope of Internship

The 12-week internship work was focused on working and improving various components of the HP TechPulse dashboard which is a client facing web DaaS application for resource management. I worked on a couple of projects, some of which went directly to production. The dashboard UI is developed in ReactJS and Veneer (HP’s internal CSS framework). The projects I contributed to are:

  • Premier Care Processes

  • Engagement using Google Analytics

  • Skeleton Loading - a Concept

My contribution to these projects included (but not limited to):

  1. Using the previously collected UX data to create user stories in inVision.

  2. Use the user stories and workflows, to create a high-fidelity prototype and on approval develop the screen as a React component, while documenting the CSS for Veneer.

  3. Conduct secondary research, use it to create a prototype, and then test it with the employees (internally).

  4. Collaborate with the product and development team in Houston, Austin, and India to understand the engagement metrics for the dashboard and implement them in accordance with the GDPR compliance.

The above image shows how the chat support worked originally as a part of the Dashboard. Each of the CTA buttons took the user to an external web page containing FAQ and some provision to submit a support request.

Premier Care Processes

Premier Care is the care service provided to by HP to it’s clients for Device-as-a-Service resource management, service and delivery across the globe. The Premier Care process is fairly complicated and very extensive and is continuously updated and improved by HP Personal Systems group to ensure the best customer service. After a week of shadowing, going through the existing research and a detailed orientation of the UX gaps being explored, I created a succinct Journey Map that touched upon the different user groups and other actors participating in the process and the actions being taken.

From the Journey Map we learned that different actors or users in the journey are notified of relevant incidents at various steps in the process. Some of these notifications are automatically generated while others are generated and directed by the administrator to the device end-user. Feedback surveys conducted by the UX team suggested that device end-users as well as administrators were often overwhelmed by the number of service notifications and ended up missing the important ones. Another gap identified by talking to the users and looking at analytics data revealed that a support ticket with HP was created even when the incident could be resolved by the end-user or company administrator. 

 

To facilitate the journey in a more efficient way, I went through the current user flow and updated it to fit in the premier case journey created earlier and address the gaps identified. I suggested providing users - admins and partners - with a higher sense of control by enabling them to modify and create new notification formats. I along with another intern conducted some desk research and recommended creating a new level of default settings that could be different from factory-level settings that the dashboard/system came equipped with.

REQUEST FOR SERVICE LOCATION

Providing users a simple and quick way to request service location, integrated with the end-user notification workflow.

The workflow culminated in me creating a mid-fidelity design screen for Service Location Request. Given my background in frontend coding, I offered to develop the service location request component as a part of the dashboard ReactJS application and successfully delivered the component that went into production, thus saving the company a month of back and forth between the design and development teams.

The page is built web-first (as is the entire dashboard) and is mobile-responsive and built in strict adherence to the company’s design principles, using the Veneer CSS framework.

service_info_form.png
service_info_form2.png

LIVE CHAT SERVICE

Help & Support using the dashboard was offered in the form of FAQ with the users being directed to external links for all kinds of issues.

This was a tedious and time-taking process for any TechPulse user. The goal was to enable the users to access HP support via chat so that they can get help quickly and stay in the context of what they are working on.

I started by defining the users and created a workflow along with a wireframe to visualize the solution step-by-step.

We decided to allow the admin to control and manage the permissions for requesting a chat through the dashboard.

Chat Support (2).png

Chat Support Workflow

Below are the design images I created for the chat function within the dashboard in inVision. Using these images as a reference and inspiration, I ended up developing a Proof-of-Concept in ReactJS for testing the feasibility and usability of the designed chat solution.

Capture.PNG

Begin Live Chat

livechatended.PNG

Live Chat Ended

chatinprogress.PNG

Live Chat in-progress

waitingroom.PNG

Waiting Room for Live Chat

chatunavailable.PNG

Live Chat Unavailable

Skeleton Loading

Page-spinners are used uniformly through the DaaS dashboard which offers a varied range of services and features. Psychological studies into progress indicators show that our interpretation of them is anything but linear. Our method of processing a delay doesn’t match up with reality.  In software design, skeleton screens provide an alternative to the traditional methods. Rather than show an abstract widget, skeleton screens create anticipation of what is to come and reduce cognitive load.

dashboard.PNG

A snapshot of what the dashboard looks like while the content on the page is loading.

After a conducting some secondary research, I was more than convinced that Skeleton Loading would make the user journey, with a dashboard they interact with multiple times a day, a more joyful one. With some support from LinkedIn, Facebook and elements in the Google Suite I was able to convince my mentor and both my managers at the Personal Systems team, that Skeleton Loading was worth a shot. But at this point in time I had a few challenges to overcome:

  1. All the research and convincing left me with limited time until my internship ended.

  2. My mentor had planned and secured a week of holiday, assuming I would have by then finished all my internship projects (which I had).

  3. Even if I could manage to create some design screens, it would leave me almost no time to test the concept without which the project was as good as shelved.

  4. Static designed screens would not do justice to the concept while testing as Skeleton Loading relies heavily on the following visual design approaches:

    • ​Use of motion - type of motion used as well as speed​​

    • Use of a shade of grey or a neutral color (with respect to the rest of your application)

So, I decided to put my coding skills at practice and I developed an interactive prototype for Skeleton Loading for some specific sections of the dashboard using an npm package available for ReactJS.

Skeleton Loading - Backup Slides.pptx.pn
Skeleton Loading - Backup Slides.pptx (1

So, I decided to put my coding skills at practice and I developed an interactive prototype for Skeleton Loading for some specific sections of the dashboard using an npm package available for ReactJS.

ListSkeleton.PNG

A snapshot of what Skeleton Loading looks like for a page in the dashboard 

I then ran a quick usability test with 15 participants across Marketing, Sales and Development teams in the Personal Systems group. Being respectful of everyone's time, I designed my study in the following format:

  • The study spanned a time period of a few days (based on the availability of the full-time employees).

  • I tried to keep the pool of participants as diverse as possible in terms of their familiarity with technology.

  • I tried not to talk to the participants while the test/study was in progress, as generally they would use the dashboard in a fully-focussed state.

  • Because a part of the dashboard was something that every employee interacted with on a daily basis and because most participants in the study were working remotely, we conducted the study on each participant's work laptop/desktop.

  • A sandbox environment was created which mimicked the development environment functionally and visually.

  • Skeleton loading was implemented for loading content on only 3 pages across the dashboard.

  • Each participant was supposed to complete 4 tests and following each test answer a set of questions.

  • The test design sequence was such that the appearance of page spinner and skeleton loading was maximally randomized.

The end of test questions were designed to gather information on the following topics:

  • User's familiarity with the concept of Skeleton Loading 

  • Their perception of time taken for the page to load 

An estimation of the Perceived Loading Time based on the responses from the participants is mentioned below:

Frame 1.png

An average estimation of the perceived loading times as reported by the participants.

OUTCOME

Skeleton Loading attempts to improve client experience while using the dashboard by making the it act proactively in accordance to user expectations.

We started by addressing the gap at the root level and moved our implementation from a generic layout level to a customized component level. The project turned out to be a success in terms of the depth of research and the successful implementation as a POC.