Empowering relationships, efficiency and improved decision making with content strategy, messaging and improved information architecture

An iMac on a desk in a room with people in the background displaying the price change request application

Date Completed

March, 2024


Sherwin Williams salesforce utilizes price changes as a sales tool. Sales representatives submit requests for price changes through a web application. These requests are then reviewed by district managers and or their sales leads.

The existing web application used by district managers to approve or reject price change requests represents an opportunity to implement extended functionality to save the valuable time of district managers and sales leads, improve the quality of decisions, and build stronger working relationships.

Working as the senior designer on the project I lead the research and directed one junior designer in the production of a user centered web application delivered within tight deadlines.

Application modernization requirements

  1. Allow for a more intuitive experience for the users who will input and view the pricing changes as well as the users who will be providing decisions on the changes.
  2. Create one system from request to approval, so the requestor and approver have access to the same data.
  3. Need to provide the end user with better information to make appropriate decisions regarding the approval of requests.
  4. Utilize business unit flags to allow for business specific rules (instead of just P&M and non P&M)
  5. Display fields need to be created considering the more specific needs required by each division
  6. Implement a prioritization process and rank requests based on impact to the business – being evaluated
  7. Include the ability to escalate approval decisions – not built for requesting approval – just have auto vs manual approval – thresholds will be set to allow for the escalation of requests to reach multiple levels of approval 
  8. Provide the capability for users to communicate freely within the system including notifications when a request has been submitted or decisioned 
The detail page of the price change request application



Learning about the modernization of the price change application began with the review of requirements provided by business analysts, and meeting with the pricing team to walk through the current application together

This is one of those applications that is comprised of a simple four step task structure. Search, select, view, decide, repeat.

  1. Logs onto the application
  2. It displays all requests for the district that are associated with the user
  3. The user can search the results or filter them. There are rarely so many requests that they would need to do either. Occasionally they might be tasked to find a request and search by account number to find it.
  4. A request is selected. Often the user is just working their way down the table of requests from top to bottom.
  5. A request is selected. Often the user is just working their way down the table of requests from top to bottom.
  6. The detail panel opens over the page, and the work of investigating the request to decide to approve or reject it begins.

To understand how we might improve the quality and efficiency of the work that district manages do here on request detail pages, we need to understand how they are referencing the displayed information, and what they do when they do and why.


After being introduced to the project I planned scheduled and conducted task-based talk allowed protocol interviews with Sherwin Williams district managers

What district managers are considering to decide on a price change request is largely learned behavior that is playing out on an information display page. The only actions taken on the page are scrolling and setting a  designation for a request, and then submitting the request. To learn and understand what a user of the app is thinking and doing, we can't just ask them in an interview.

Learned behavior is often difficult to explain. Providing a context and asking for someone to talk through the experience moment by moment is a more accurate way to learn about user intent and the elements on the page.

I planned the research around the task structure of the application. I asked about search, selection, and then how the page is referenced to decide. These are the questions I asked DMs about the page they are viewing when deciding a request.

  1. What information did you reference from the account overview when deciding to approve or reject the request and why? 
  2. What is the value of the information you did not reference in the table? 
  3. If you could change anything about the account overview, what would you change? 
  1. What information did you consider when deciding to approve or reject the request and why? 
  2. What is the value of the information you did not reference in the table? 
  3. If you could change anything about the table, what would you change? 

Research Plan


With the recordings from my round of formative research I was set to begin summarizing and looking for patterns and insights useful for achieving our goals for the revised application

Research synthesis goals

  1. Identify opportunities to provide the end user with better information to make appropriate decisions regarding the approval of requests.
  2. Provide the capability for users to communicate freely within the system including notifications when a request has been submitted or decisioned.
  3. Determine where to time-stamp requests when submitted, apply a request ID, and set an expiration date for the approval request based on pre-established criteria.
  4. Design information architecture allowing for display of older requests that are expired and possibly provide approvers the ability to resubmit an expired request if needed.

Ideating for this application is a process constrained by the consistency that needs to exist across the price change request and change approval sides of the application

As we conducted our research, meticulously analyzing video recordings with district managers, we carefully aligned our objectives with the requirements outlined by our business analysts. Additionally, we took into account the insights shared by our expert users regarding their application usage. Our focus remained on reconstructing the application in a manner consistent with the request side of its functionality.

We considered a number of experience based changes to the application. These were largely based on observation and discussion of the application in use by our research participants.

  1. We considered a detail page solution that would reduce the amount of vertical scrolling by breaking up the scroll into product families. Progressiver disclosure.
  2. We debated and mocked up the tab navigation that would simplify the search experience.
  3. We considered and mocked up different solutions for a modal state for request details.
  4. We created variations of the page content stacking order
  5. We mocked up reordered table headers and table styling.

Once I had a complete experience I got one of our district managers back into a teams conference and walked through the new solution

Our great research participant Roy was impressed with the revised design of the application. As we walked him through the design we were able to confirm the. value of some design decisions we had made and learn about others that could still be made.


The final round one design came together as we worked through the process of documenting our rationales for presentation to the pricing team

After reviewing our new design, we compared it against the provided requirements and identified that certain specifications had not been adequately addressed. Consequently, we decided to schedule additional meetings with the pricing team to incorporate these  requirements into the design. We prioritized the user based changes to the application, and saved any requirement we were did not fully understand for discussion with the pricing team.

A number of business requirements were still in a speculative technical phase. We felt it would be good to get a comprehensive revision in hand and go back to stakeholders to work through the technically complex functionality.

  1. In the current application requests can only be approved or rejected. The rejection of a request creates work for the reps. They have to recreate a request. The system needs a solution to push forward rejections as a corrected price that they approve at the adjusted price they have chosen.
  2. We tend to think that a chat based UI would be a great addition to what is now an information display application. Transforming the pricing application into a communication platform would have clear advantages but this implementation has security and technical complexity that needs addressed.
The new design for the landing pa
  1. We felt that a better design solution was needed for the indication of the driving SKU of the request. The use of color alone, adn not both location and color seemed like a mistake. This would need furthur discussion with the team.
  2. The proposed linking of price change history comments violates the rules of modality. We felt that the surfacing of this information was useful but simply missed that it could ne be designed a a link to a page from a modal. Rather than taking it out we left it in as a point of diicsussion.

Reflections & takeaways

The pricing work that is done by district managers impacts the profitably of Sherwin Williams in a number of ways. Pricing is used as a tool to bring in new business and upsell to premium product lines.

In my role as the senior designer leading this initiative, I assigned the task of researching and documenting the request side of the application to the junior designer within our team. Additionally, I tasked him with creating UI components that maintain consistency across various applications. This allowed me to conduct the interviews and still be prepared to ideate and prototype within a tight deadline.

Our final design was informed by well documented insights from Sherwin Williams experts. We were able to add value that was well received by both the district manager we shared it with and the pricing team. Our decision to wait on certain requirements, and tackle them in a second round of design and research was also well received.  

I proposed a change in the working relationship of the pricing team and UX team which was greatly appreciated. From the presentation of this work moving forward the pricing team lead would schedule weekly two hour working sessions.

Not only did we transform an application from an information display space to a communication platform to build strong working relationships, we changed our way of working with business and stakeholders here at Sherwin Williams.