I would expect the finished product would feel foreign to most drivers.
The basic form of the vehicle – tires, steering wheel, seats – might be in their proper places, but the interface and cockpit dials might be put in spots that make it unconducive to the driver. Maybe the heating and cooling controls are just out of reach. Maybe there are no cupholders for your morning coffee.
There could be any number of things wrong within the vehicle. But the designer would never know because they didn’t put themselves in the shoes of the end user.
When it comes to designing software for our customers, we make sure everything we build is built with the user at the top of our minds. If the product isn’t built to make an operator’s life easier, there’s no point in building it.
Technology, however, is always in transition, which can make software design a tricky beast to slay. So, we designers need to be smarter about how we work.
Going mobile on the shop floor
One of the biggest changes we are adapting to in manufacturing is the move from desktops and workstations to handheld devices as the industry evolves. Before the advent of mobile devices on the shop floor, operators were relegated to their desks, where they made the necessary changes after making note of what needed to be worked on. It was a cumbersome process, but it was the best solution available at the time.
Fast forward a few years, and mobile applications began to be more widely available, but they were still clunky and confusing. There was no uniformity built into the technology, meaning operators had to endure the inconsistency that comes with software that isn’t purpose-built for their needs. We saw this as an opportunity to make the operators’ work easier, so we ran with it.
As we were going through the design process, there was one key point we knew had to be addressed. The mobile device must assist a user throughout the plant floor on a variety of operating systems and displays. But just like an automotive engineer getting behind the wheel to truly understand how to design the car for the user, we needed to witness how operators use these products on the shop floor to truly understand how to design for their benefit.
Real users completing real tasks
When we began work on what became Plex Mobile, we spent a lot of time just walking the shop floor where the operators worked. To create software solutions that meet the needs of our users, we needed to understand the problems they were facing and predict the needs they haven’t yet thought of.
That’s where I come in. As a user experience designer, observing real users completing real tasks is one of the most powerful and valuable aspects of my job. Visiting our Plex Champions, talking with operators, and sharing in their environment impacts how we design our product and how we prepare our product to handle future industry needs.
While working on a recent project, I had the pleasure of visiting a handful of sites to observe the different ways in which each handles a similar data-entry task. To complete the same task, they either used a computer on a rolling cart, a tablet, and pencil and paper which they then carried to a mounted desktop computer to complete the data-entry task.
Can you guess which operator was able to complete the task more quickly and accurately?
Walking in the operator's shoes
Efficiency benefits aside, today’s manufacturing process is made up of countless practices impacted by the methods each business chooses to deploy on their shop floor. With the availability of new technology comes the challenge of adapting both the user and the design to new features and capabilities.
But how do we design for the mobile tidal wave splashing down on manufacturing without disrupting our users? We accomplish this by carefully designing our products with a foundation for change and scalability built around our users’ needs and environment.
At Plex, before we form a solution, we talk with users about their needs and expectations, and we observe their interactions with the environment. This goes back to having the ability to walk a mile in their shoes. We don’t start work on any component of the project without knowing which challenge or pain point we need to address. With 18,000 settings, Plex’s ability to scale and adapt can be complex. A single task may incorporate many personas, settings, and unique objectives that exist only for a specific configuration.
Designing around the user experience
Consider the Manage Container application within Plex Mobile, which displays information about a chosen container. A user may choose to access this app from the main menu and view the contents, status, or location of a given serial. In addition, whenever a container serial is shown within the app, the user has the ability to drill into the serial and view the properties in the same format as the Manage Container screen, regardless of how they access it. This creates a familiar and consistent experience.
We deconstructed the current process to understand the key objective of a certain function based on the chosen persona. So in Manage Container, the objective of the task became the anchor around which we designed the clean, palm-sized solution.
By designing the software around a predictable, consistent experience, we gave the operators several benefits that would vastly improve their work lives, not the least of which included less likelihood of making errors, improved data accuracy, easier adoption of new systems, and less strenuous training for new employees.
And, as the needs of our customers change regularly, our software can change without minimal disruption to the user. We’ve all experienced that horrifying realization when you turn on a device after a late-night update, only to find nothing is where you left it. That’s a thing of the past.
Products tuned to manufacturing needs
Because we have spent time with our customers, we know exactly what they want, and how they want it. The operators are given a product tuned to their specific needs, and their work improves because of it. They’ll find new features easier to understand and use since the interface is built for the work they do.
If you do it any other way, you’re just adding unnecessary steps to the process. Take the time to watch how your customers actually use the product, then design to their specifications.
It’s that simple.