Working backwards to design a new user experience for Virtual Engineering Workbenches on AWS

Introduction

This blog post walks you through the synergies between the Amazon Working Backwards mechanism and User Experience (UX) design that we used to accelerate the adoption of Software developers, Software integrators and Software testers using the Virtual Engineering Workbench (VEW) through improving their onboarding experience. VEW is a cloud-based development environment allowing its users to access a preconfigured development environment in minutes instead of weeks. At Amazon, “Working Backwards is a systematic way to vet ideas and create new products. Its key tenet is to start by defining the customer experience, then iteratively work backwards from that point until the team achieves clarity of thought around what to build.”

Build the right thing

The first steps of the Working Backwards mechanism focus on the customer and the problem to solve. In our case, we help automotive companies in both the short-term and long-term to sustainably adapt to their end customer needs that are radically changing. Our customers, global automotive companies, seek to enhance their innovation capabilities to speed up their delivery time of new products and support the vision of Software-defined-vehicles (SDV). Providing their software development engineers with the necessary tools through VEW is key to achieving this. The VEW includes pre-installed 3rd party software used in automotive software development, the virtual targets (e.g. a head unit within the car) to integrate the developed software (e.g. infotainment applications or climate control) as well as automated pipelines for its validation and verification.

The power of the first impression and the importance of user feedback

The users of VEW are developers, integrators and testers of automotive software. During the beta phase, after the first developed version of VEW, we conducted interviews with beta users and listened to their feedback. Through this we learned that the onboarding experience for new users of VEW was proving painful, both for end users and the teams managing those environments as there was no structured procedure users could follow. The onboarding phase is the first point of contact between a potential user and VEW and consists of providing information and access to the solution. As VEW is aiming for more than 5,000 potential users, it was important to improve the experience of new users during their onboarding phase to provide a positive first impression.

“You never get a second chance to make a first impression.”- Will Rogers; entertainer, radio personality, film actor, and writer.

Statistics show that 88% of users are less likely to return to a site after a bad experience, and that 94% of user first impressions are related to User Interface design. A bad UX can impact a business in two primary ways, adoption and effort. From an adoption perspective, applications will lose 9 out of 10 users because of design-related issues. From an effort perspective, 50% of developer time is spent fixing preventable bugs. A good UX design can improve both experiences. In 2017 alone, $150 billion were spent on fixing preventable bugs. Therefore, it’s critically important to make a good impression on users from the very first moment if you want to improve the chances of adoption, engagement, and their advocacy of your solution.

Then, build the thing right

Once we received feedback from our beta users, we wanted to offer a good first impression and a pleasant end-to-end UX for VEW during the onboarding phase. In Figure 1 is the diagram that describes our approach, which is based on the Design Thinking methodology and customized to our project’s needs. It includes 3 main phases: Engage, Define and Build. We describe each in the following sections.

Figure 1 – Customized Design Thinking Framework

Engage

During the “Engage” phase of the Working Backwards process, we understood in detail our customer’s problems and opportunities for improvement. We approached this phase as follows:

• Build a Service Blueprint
• Create Personas
• Map User Journeys

Service Blueprint

The UX is a continuum. It is the result of the processes and interactions that are carried out, both by the organization and by the end users. Understanding the relationships of all the components that are part of the VEW throughout the customer journey is key for the builders and contributor of VEW to being able to optimize the solution.

Service Blueprints as shown in Figure 2 allowed us to surface relationships, both visible and invisible to the end user. It is a visualization of the components involved in the delivery and use of a service, including the customer journey, touch points, and organizational processes. You could consider this the front- and back-end view out of a user focusing on the actions instead of the technical components. By this, we identified gaps in the customer onboarding journey about touch points to inform the VEW, a process to onboard them, and support them getting started.

Figure 2 – Exemplary Service Blueprint

Once we created the Service Blueprint, it was important to understand the people who would be using the VEW.

Personas

We created Personas to understand the motivations, behaviors and pain points of the users working with the VEW as shown in Figure 3.

Personas allowed us to empathize with our users. They enabled us to design a solution that not only solves the problem of our users, but also provides a customer experience that encourages and supports adoption of the VEW on a regular basis during the day-to-day work.

Before we identified Personas, we described users with roles and activities each role can perform. While having a role description was a good starting point and beneficial for software design in general, like the design of the identity and access management, it was not enough for building a satisfying customer experience.

We used the role description and activities to check against feature implementation for a pure functional perspective. A feature was complete when Role A could perform activity X. This led to a solution that focused on the results only, not on the customer experience while using the VEW.

User research helped us identify behavior patterns of beta users and potential users. We had some beta users who were skeptical and did not make use of VEW and, on the contrary, potential users who were motivated and wanted to get value out of VEW to make their daily work more efficient. That’s why we created Personas on both sides of the spectrum, one Motivated Persona and one Skeptic Persona as shown in Figure 3. This helped us consider a wider variety of use cases, behaviors, feelings, and interactions.

Figure 3 – Exemplary Persona

Journey map

Journey maps are visual representations of the process a Persona follows to achieve a goal as shown in Figure 4. They highlight the human experience of the Persona making the journey: actions, thoughts, and feelings. Although different Personas can start from the same point, the experience can turn in one direction, or another based on the attitudes and preferences of the Persona in question.

Figure 4 – Exemplary Journey map for skeptic and motivated Persona

There are two types of Journey maps, those that reflect the current experience, an “as-is Journey map,” and one that reflects the ideal experience, the “to-be Journey map.”

We created the as-is Journey map for each of our Personas for the current onboarding experience. This helped us understand how the user experience is lived from two different perspectives, and ultimately gain insights into how to best respond to their needs and expectations: how to keep and respond to the motivation of our Motivated Persona as well as how to manage and overcome the objections of the Skeptic Persona.

Once we mapped the journey, we used the insights that emerged from the exercise to identify opportunities and potential solution ideas. This helped lay the foundation for the next phases.

Outlook and next steps

With the work and UX artifacts (Service Blueprints, Personas, Journey maps) we developed during the “Engage” phase, we achieved to align the front- and backstage of our solution in a comprehensive vision, empathize with users through the creation of Personas and defined the pain points and benefits we will use as a guideline to optimize the UX.

The next step is the “Define” phase, in which we need to define the ideal experience for our users in a to-be Journey map and create prototypes. The result of this phase is the defined solution.

In the final “Build” phase, we will use the best and most recent version of our prototypes to perform usability tests to help validate if we reached the defined goals for our users. This allows us to make final adjustments before handing over our prototype to the development team of VEW to build the solution and release it to the users of VEW.

Conclusion

In this blog AWS and PwC discussed how they incorporated UX design principles into the Amazon Working Backwards mechanism to help improve the UX of new VEW users during their onboarding phase. By following this approach, we helped accelerate the adoption of new users and reduce the effort for developing VEW. The same approach can be considered for any application you want to scale out.

Learn more about AWS offerings at the AWS for automotive page, or contact your AWS team today.