Lean UX

Throughout my career, I have worked on a wide variety of projects with different project timelines. While it is always great to work on a long-term project with generous time for a discovery phase, I have definitely had experience working on much more rapid projects!

The following is an example of just such a rapid paced project. While working at Accenture, I was assigned to a team that had two weeks to go from a rough idea to a fully functioning proof of concept that combined original software and hardware and could be demoed in front of a client.

I cannot disclose too much of the specifics of the project, so this will just be an overview of the work that I did so you can see my approach to rapid user research.

  • February 2020 to February 2020
  • User Research, Design, Strategy
  • Capability Team
  • AirTable, Miro/Realtimeboard

The Challenge

My division in Accenture was just starting to enter the embedded technology space and had created small teams to rapidly learn about the space and then prototype proof of concepts that could be used in sales pitches with clients.

The teams would have two weeks to take a very rough problem statement and:

  • Research it
  • Identify an embedded technology solution
  • Determine needed hardware
  • Ship hardware to the office
  • Validate the designs
  • To (hopefully) demo to a client

Completing this all in two weeks meant that the team had to move extremely quickly, and because of the time it took to order parts there was limited scope for changing direction.

The specific area my team focused on was how to bring embedded technology into the office space.

The Who

My Role

User Experience Architect

The Team

Product Owner

Delivery Lead

4 x Developers

Finding a Solution

This project required me to juggle multiple objectives as a User Experience Architect, but the main three were as follows:

1 Problem and Vision Framing

2 Lean User Research

3 Bridging Business Goals and User Needs

Problem and Vision Framing

I started the project by leading the team through exercises such as How Might We questions and the Google Venture Design Sprint sprint mapping technique.

A version of one of the sprint maps with How Might We questions placed at relevant sections of the map can be seen below.

By leading the team through these exercises, I was able to refine the original problem statement into something more concrete and actionable that we would be able to actually achieve in the two weeks.

Having a concrete vision and problem statement was critical because the developers had to order any necessary hardware within the first few days in order to have it shipped in time. And once the hardware was ordered, there would be less room for changing project scope.

Lean User Research

As mentioned above, the timeline for this project was extremely short.

In order for the developers to be able to order all the necessary hardware components in time, the team needed to have at least a rough idea of the functionality and features the end product might have.

Thus, the discovery phase research ideally had to be completed within the first few days of the project.

During this time, the team was still getting to know each other, and the project vision was still shifting so, as a researcher, I had to be extremely flexible and able to shift direction at any point.

A great example of this occurred when the developers called an emergency meeting right before I had a scheduled a user interview.

Technical constraints meant that we had to change the scope of our project significantly. So, while helping the team define a new vision for the project, I had to simultaneously rework my interview protocol so I would be able to get meaningful findings out of my upcoming interview and not waste the user's time.

Bridging Business Goals and User Needs

One of the most challenging parts of this project was bridging the gap between the end-user's desire for privacy in their office environment and business interests in monetizing their data.

The Product Owner on the project was looking for a quick business win and saw a chance for profit in using embedded technology to monitor employee's data such as productivity and their health.

However, my research clearly demonstrated that both end-users and HR Departments were very opposed to this.

When communicating these findings were not enough to dissuade the Product Owner from monetizing users' data, I worked hard to reframe the project in a way that would bridge her goals with the needs of the user.

I quickly researched other environments outside of the workplace where embedded technology could ethically be used and drafted proposals that referenced how such an approach could fit with our prospective clients.

The Outcomes

Unfortunately, we were not able to find a client for any part of the project by the end of the two-week timeline. However, one great success of the project was that I was able to convince the business that monetizing the workplace data of users was not a good idea.

The project also established me as a strong advocate for the end-user and ethical research and design in the organization.

The Learnings

The biggest learning for me during the project was how to directly monetize user research findings and frame them as potential avenues for business growth.

Skills Developed

  • Service Monetization
  • Embedded Technology

Skills Enhanced

  • User Research
  • Ethical Design