skip to Main Content

Swiffer & the Power of Observation

The invention of the Swiffer is a very interesting story, and one that can be reasonably applied, even in the world of enterprise application design, and digital transformation. This might sound far-fetched, but the key breakthrough for Procter and Gamble, and the techniques used by the design team can be applied to any initiative where we are genuinely interested in creating value for our users or customers.

Image result for swiffer

Customers were not happy with their cleaning experience. Mopping classically required some sort of sponge on a stick and a bucket of water with some soap in it, which gradually turned more into a bucket of dirt as your mopping progressed. Customers didn’t like wringing out mops, dirty buckets of water, and the feeling that they were eventually smearing dirt back onto their floors. So, P&G chemists set out to make a better soap, which inevitably failed. It turns out they were looking in the wrong place.

Enter an experienced design thinking team, that ended up spending a lot of time observing customers, and learning about their frustrations. Their conclusion was not that P&G needed to invent a new soap, but that customers actually wanted a new mop. Enter the Swiffer line of products, trapping dust, eliminating the need for buckets of soapy water, and an easy way to dispose of the mess when finished cleaning. This discovery, only made possible by directly observing the cleaning habits of customers in their own homes, launched a billion-dollar product that continues to evolve, and sell, today. It turns out, that applying this same observation technique to our ERP users can also yield fantastic results.

Similar to the challenge that the team at Proctor and Gamble faced, it can be hard to make sure that you are focusing on the right challenge. The P&G team immediately went to the solution of creating a better soap without first understanding what their customers’ real challenges were. In a recent design thinking session, our team was sent to a warehouse to observe how employees interact with the time clock system, which was thought to be slowing them down. It turns out this was not the case, and in fact, the time clock was pretty efficient and easy to use. What was slowing the warehouse workers down was actually a lack of real-time information and the project pivoted to creating ways to get that information to users quickly, as opposed to redesigning an already great time clock. Without those observations, the project would’ve headed down the wrong path, and not achieved maximum value to both the workers and the business.

Sometimes, in the case of complex business processes, we know that the process as a whole may need some updates or fixes, but not exactly which part of the process is causing the most pain for the users. Once again, direct observation and interaction with our end users can help. During another design session, our team was working with the business to understand their process, and where the inefficiencies may lie. For a while, they seemed to just be getting overall process information, until one user mentioned something about this process they had to resolve pricing issues in contracts, and how it was a big pain for them, and others. This a-ha moment led the design team to poke more into this process, discovering that there were over 40,000 contracts being updated each year, potentially leading to incorrect or even not billing customers, and countless hours of rework by the team. The overall process was estimated to cost the company north of $1 million per year. This incredibly important process was made possible only through direct observation and interaction with the users.

It turns out that the key was to observe and understand customers, as they use the products, and gain a good feel for what the challenges they faced were. Once the problem was understood and framed correctly, there was a real opportunity for innovation. A new soap probably wouldn’t have been a huge win for P&G, but Swiffer certainly turned out to be, and that’s because it provided real value to its customers.

This same practice can be applied to understanding the users of our software systems. It’s very helpful to observe our users as they go through their day-to-day activities, whether that’s in a manufacturing environment, a call center, or anywhere our end users go to complete their daily tasks. Taking notes and, if you have permission, photographs, are key during this phase. By observing our users, instead of just asking them questions, we gain some important benefits. The first is avoiding bias in our questions, a problem that exists in many surveys or focus groups. The second is that innovation and true value for our users often lies in their unarticulated needs. This is why we make sure observations are a big part of our design sessions, ensuring we are solving the right problem, and delivering maximum value to our end users.

 

If you have an interest in viewing similar content, visit our blog, here

View our LinkedIn, here

Dan Flesher is an experienced SAP UX Architect and Design Thinker. He began his SAP career as an ABAP developer, and transitioned to a focus on SAPUI5 and Gateway OData service development. In addition to his development background, Dan has a passion for Digital Transformation, and Design Thinking, helping clients with their trickiest challenges. With a user-centered focus, Dan is typically involved in all stages of projects, from design workshops and prototyping, through development and delivery. Dan is a frequent speaker at ASUG and SAP UX events, and contributes blogs and development tips through the SAP UX newsletter and the Mindset blog.

Back To Top