Radia Lahlou
Product Designer

Problem

Torrential rain, sewer bypasses, and underground mining all lead to an excess of water. When uncontrolled, this excess water leads to widespread destruction and devastation - and the danger of human lives.

Xylem engineers and local field technicians need a way to mitigate risk when dewatering a flood site. For one, these sites are often inaccessible or unsafe in person. Secondly, when they are accessible, having a crew member on site for the sake of monitoring the pump in person wastes time and labor.

Solution

Field Smart Technology provides users with a way to optimize their use of assets with real time alerts of fault conditions, remote control for better pump performance and labor utilization, and safety/peace of mind with remote monitoring under challenging conditions.

My Role

I work as the primary product designer on the Field Smart Technology (FST) team, collaborating with product management, engineering, and marketing. I also help to guide the other designer on this project and integrate our work into the Agile process.

The current FST user experience and interface is cumbersome, difficult to navigate, and prevents users from completing their jobs efficiently. I have been tasked with spearheading a redesign of the product.

Dewatering pumps using Xylem's Field Smart Technology after tragic flooding in Liege, Belgium in July 2021

Dewatering pumps using Xylem's Field Smart Technology after tragic flooding in Liege, Belgium in July 2021

Redesigning Device Details
01. Research

Preliminary Research

I commenced the project by conducting an extensive review of research run by an outside design agency before I had joined the team, in addition to reviewing the three personas they identified (see image below).

I also spent time communicating with the product owner, product manager, and marketing manager of the project, as well as collaborating laterally with the Xylem UX team to get a better sense of the design ecosystem across products.

Two distinct but related design and business goals became apparent:

  1. Within the FST team, it was clear that a new user interface was needed in order to increase adoption of Field Smart Technology - customers were purchasing and renting pumps, but not the software that accompanied it. This is in large part because of the complex, table heavy user experience.

  2. Within the broader Xylem design team, it was clear that the success of Field Smart Technology would serve as a keystone example of the way interfacing with users can solve problems in effective ways - it would also serve to push forth usage of Xylem's new but continuously developing design system, "Gravity."

02. Experiment

Heuristic Analysis

After gaining a better understanding of the current pain points and business needs of Field Smart Technology, I conducted a heuristic analysis of the existing solution in order to guide future design experiments.

Below, you'll first see the original Field Smart Technology remote control design with customer pain points flagged.

Field Smart Technology
By creating preliminary sketches of the device data page, I was able to communicate a clear visual hierarchy to the product team. Sketching also helped stakeholders move away from conceiving of the

By creating preliminary sketches of the device data page, I was able to communicate a clear visual hierarchy to the product team.

Sketching also helped stakeholders move away from conceiving of the "control panel" as a piece of hardware, to be designed like a physical control panel (a design that lead to many documented challenges in the existing mobile experience, such as cumbersome incremental speed controls).

Formulating Design Experiments

I then began sketching, and formulated my first design experiment based off of the previous customer research, business needs, and gravity design system standards.

Research indicated to us that users feel overwhelmed when viewing FST - there is too much data at once, and no hierarchy of information. Research also indicated that information is often repeated in multiple pages, and in order to access details or the control panel for a device, a user will have to search the device multiple times in the user journey.

We wanted to reduce friction by providing users wit high priority information first. Users need to know: where their device is, if anything is wrong with the device and lastly, how they can start and stop their device.

User Research

In collaboration with my design colleague and product team, we then conducted 3 rounds of customer research sessions, in order to validate our design decisions as we continued to iterate. We used the research session time as effectively as possible, asking discovery questions about features we were about to start working on, running users through prototype sessions for features we needed validation for, and conducting A/B tests for smaller design tweaks.

03. Iterate

Below, you'll see 3 key usability issues my teammate and I flagged in the first design experiment we put in front of FST users, along with the fixes we proposed to stakeholders, to be implemented in production.

Compromise

Although the team was mostly in alignment on the usability fixes above, there were a few concessions I had to make while iterating - for example, usability testing showed that when it came to alarms, users needed binary information: As a user, either my pump is ok and I don't have to worry, or it's not and I need to take action - the type of alarm is arbitrary to the vast majority of users.

However, due to the way alarm codes are processed in the hardware, and the way our internal engineers troubleshoot pump faults, it was required that we divide alarms into "common" and "service" alarms.

We found a balance by including an indication of "acknowledgement" - As a user, if my alarms aren't acknowledged, I need to take action. If they are acknowledged, I can assume someone else is taking action. This provided users with hierarchy that lead to feelings of assuredness and a more useful high level picture of their pump's status.

05. Deliver
An example of some detailed design specs from out production file.

An example of some detailed design specs from out production file.

Development Collaboration

I'm not a huge fan of the term "development handoff" - to me, it implies that a designer throws a design file over a wall to developers, never to speak again.

In our case, development collaboration is a more apt name - we work carefully in tandem with developers to ensure our design is being executed efficiently. At this stage of the process, we provide detailed design specs and prototypes and continuously communicate via Slack and Zoom.

Responsive Design

In our user research sessions, we identified the need for a mobile and tablet solution - often service technicians or branch mangers will set up a device out on the field and will need a way to view device details from their mobile phone.

In terms of technical requirements, we needed to create a design that was scalable across screen sizes, as well as when a desktop's screen reduced. In order to do this, I made use of autolayout and the Figma plugin "breakpoints." You can take a look at the responsive prototype in the video below (at 00:30 seconds).

After a zoom call, I provide the dev team with asynchronous walkthroughs so they are able to keep track of interaction patterns and understand how the design will respond to various device types. Making sure my design was responsive was critical to user workflow, because many users need to monitor and control their pump out on the field.

05. Next Steps

What comes next?

FST is currently in development, with a Beta MVP to be released in July 2022. We will be monitoring usage through LogRocket, and working as a team to define UX success metrics in order to determine the efficacy of our redesign.

User testing has shown positive reactions from seasoned and new users alike. Users are looking forward to being able to monitor and control their pump with ease, from whatever device is most convenient for them.

In the 8 months I've been working on Field Smart Technology, I've learned a lot.

  1. Articulating design decisions is just as important as designing effective solutions. If you'e unable to communicate why the solution you propose is effective, the team lacks a cohesive vision.

  2. Designing a good solution that works is better than designing a perfect solution. A design is rarely perfect, and is always a work in progress. Drawing from user research and ensuring a product works for its users is critical, but that doesn't mean the product has to be 100% perfect.

  3. Unforeseen circumstances skew deadlines. I was hired at a time when the Field Smart Technology team was low on development resources. As such, it wasn't until very recently that the designs I've created have been implemented in code, and thus many of my deadlines were self-directed. I learned to use this situation as an opportunity to grow - to dive deep into research, build connections with customers and my team, and use my spare time to contribute to Xylem's design system.