Lowe’s Pricing

Project Snapshot

After our initial core release, I played a key role in leading the UX for Lowe's internal Pricing application. I led its evolution from the initial UI release to the development of more intricate data views. Notably, we achieved a significant milestone when we reevaluated our approach to aggregating data within versatile data tables. This case study delves into how our UX team empathized with users to transform a short-term request into a durable, adaptive solution.

Note: This case study is for a proprietary Internal application.

My Role

UX Architect

Our Team

Primary Users

Peripheral Users

Senior PMs

4 PMs

2 Associate PMs

6 Dev Teams

2 UX Designers

UX Researcher

Content Strategist

Our Tools

Abstract

Adobe XD

Axure

JIRA

Sketch

Whimsical

My Deliverables

Sketches

Use Cases

Flowcharts

Diagrams

Lo-fi Wireframes

Prototypes

User Research

Features

User Stories

The challenge

The challenge was to design a comprehensive and adaptable solution for complex data views, addressing the ever-changing needs of users across various scenarios and individual preferences. This solution needed to be versatile for future requirements while efficiently managing heavy data loads and ensuring seamless data management.

The Starting Point

We closely collaborated with Product leadership to identify key opportunities. The initial discussions led to a compelling business case: As a Pricing Analyst, I aim to enhance data aggregation to navigate granular information efficiently and uncover significant insights.

Our initial release laid a strong foundation for the Pricing application, employing tables to present complex data sets. However, tables with limited functionality are ineffective in conveying a data-driven narrative. Naturally, users and, by extension, our Product group sought practical data “aggregation” methods to streamline their analysis and avoid sifting through tremendous amounts of raw data.

The problem with the broad stroke request of “aggregate” was that as soon as we started looking more deeply, each user had a unique understanding and interpretation of what that meant to them. Our users’ diverse traits made the data needs highly complex. Simply put, adding on the traditional sets of enhanced table functionality would not cut it, and this case study explores how we approached solving this.

Research

I strongly hypothesized that we needed more adaptive and dynamic views. Still, uncertainty surrounded how much adaptability would be required and the best iterative approach to avoid coding ourselves into a corner in the future. Given that we were rebuilding data structures from the ground up, we needed to consider implications on the backend architecture.

To gain a deeper understanding, I collaborated with our UX Researcher to conduct virtual user interviews. The interviews were structured to learn more about how users approach their work and their tools to make high-level data decisions and solve problems with a mix of open questions and card-sorting exercises. While we anticipated some variation, the results were surprisingly inconsistent. The inconsistency was the constant element - our users needed versatility, allowing them to determine their own data views and controls to address specific problems.

Learning about our users

Experience

Users had a wide range of experience on the job from one month to almost a decade.

Way of Working

Not only did users differ in what they worked on, but they also differed in how they approached their tasks and way of working.

Background

Backgrounds differed significantly from user to user, how they got into the industry, education level of experience, age, and more.

Tools

While there were core tools, user’s go-to applications varied greatly from user to user.

Focus Area

Each user had a specific area of expertise, and each of these areas had dramatic differences and needs.

Responsibilities

Users had different categorizations and teams, which created a situation where a role title was the same, but responsibilities differed.

Reframing the Strategy

Business Case

As a Pricing Analyst, I want to view or group data at the level I need and then modify the view of specific segments in various ways so I can access the right data at the right levels to solve the problem at hand.

Once we took the time to examine the problem from many angles, we knew we had a new core problem and business case.

Over time, we had a lot of inputs to consider, including brainstorming and white boarding sessions, discovery interviews, architect & designer collabs, UXA team discussions, timeline constraints, technology limitations, and future considerations.

When approaching the work, I focused on objectivity and user needs rather than personal preferences. To achieve this, I researched and developed a mind map to dissect table functionality, filter options, data grouping, and aggregated views. Within this framework, our team prioritized functionality, created concept maps, and planned for future scalability.

The mind map allowed us to make specific calls about what functionality the design needed to support and assist users most. This breakdown was essential for our designer and me to collaborate and clearly define what we were going after.

The Redesign

Next, we started to take it from theory to reality. Our designer and I collaborated through multiple iterations to ensure the design met standards for assessability, scannability, grouping, affordances, and hierarchy. At the time, our design system did not have standards for such a complex scenario, which drove us to intentionally create a pattern that could potentially serve other teams. After collaborating iteratively, we reached a final design that we could hand off to our development team. This update included simple, impactful changes, especially as you consider pages that could consist of multiple tables or variations of data grouping. 

Designing enhanced table functionality

What was it missing?

As our designer and I approached this problem, we considered much of what we had learned of our users and our expertise to identify gaps within the data landscape and the table itself. With this, we focused on three more significant problems: readability, adaptability, and customization.

Strategizing the approach

When we initially tackled this project, we recognized a gap in understanding the users' requirements as the team worked on creating views. While this observation held true, the process of identifying user needs revealed that a one-size-fits-all solution wasn't the answer. Instead, we discovered the significance of developing something versatile.

In my role as a UX Architect, I sought ways to structure table functionality that would allow for multiple views of the same dataset. Simultaneously, I aimed to pave the way for user customization of the data view. This approach emerged as the key to meeting user needs without overwhelming them with complex datasets or burdening them with the management of numerous pages of data. It also considered the adaptability required as both the product and user needs evolved over time.

Changes made

  • Added presets & custom views

  • Joined filter to the table

  • Added ability to drill down into information

  • Moved the primary function out of the menu

  • Added custom exports

  • Improved accessibility

  • Redesigned ambiguous pagination

Beyond table functionality

At first glance, this project might draw your attention to the added functionalities in the tables or the design tweaks to enhance readability. However, the true value of this design lies in its versatility and adaptability to various data scenarios within the product, all while preserving user customization.

The integration of presets with table menu functionality was a pivotal element. It enabled the viewing of a single dataset in numerous ways, addressing diverse problems for different roles. This dynamic approach elevated the overall user experience, offering flexibility and efficiency in handling various data scenarios.

Next Steps

For the visual design, while the selected preset styling was working, we felt there was a better style treatment that could be explored to make the interaction more intuitive. Lastly, we wanted to find ways to create a relationship between the tables with data visualizations to create a fuller story. Initially, these were not included as users across the board prioritized control of the data over any visualization or summary.

While we had completed the initial designs, it marked the beginning of a broader journey. The core structure was established, yet several considerations remained: data organization, initial views, layout integration, and preferred view methodology. We were also planning for subsequent design evolutions, including advanced filtering.

Lessons Learned

Although we identified a core problem and made strides in addressing user issues, I couldn't help but feel somewhat uneasy about the design. This was our initial attempt at complex tables, and while I was proud of our achievements, I recognized untapped potential. The reality was that the process had been rushed due to tight deadlines and resource constraints. In hindsight, iterative usability testing would have provided a more precise understanding of the table's performance pre-implementation.

What did I learn about balancing UX and business needs?

This was when I learned just how much business needs, deadlines, and the UX process can be at odds. I developed the ability to make sound decisions in integrating UX principles within time constraints and learned to influence others to embrace the UX process. Key values like focus, compromise, and leadership through influence became my daily practices. I worked on practicing effective leadership and learned the importance of teaching and guiding over directing; furthermore, I learned how to show and not just tell.

What did I learn about design?

  • During this period, I completed an online certification in Human-Computer Interaction for UX design, where I gained insights into conceptual design principles.

  • Our designer taught me the importance of easily overlooked assessability considerations, including scanning and readability design choices for dyslexia.

  • This project reinforced the idea that creating a simple, intuitive design can be deceptively challenging but makes a substantial difference when achieved.