Rethinking a Quality Control Tool
My latest project at work focused on our internal customers, the manufacturing team. Specifically, how to reinvigorate our current quality control (QC) software.
Any time spent with our team on the manufacturing floor is enlightening to our business model and operations. This team is responsible for cranking out orders of circuit boards. At any given time, they may be working on QC, hand placing parts, connecting wires, or any number of tasks that require a visual reference of the board. Our team was running into some challenges using the current UI, so I worked with them overhaul and redesign.
As it was, they had a few sources of information and like many software woes, this caused them to hunt around for what they needed and hack together their own workflows. Additionally, they wanted enhancements to make the data and elements stand out.
Talking the talk | Walking the walk
The first leg of this journey was starting the conversation with actual users and doing research through a UX lens. I spent several days on the floor speaking to everyone on the team, observing their work stations, and even taking a stab at QC'ing a few boards. (I also completed one sub-par soldering test. Soldering microscopic resistors is NOT easy! 😜 )
I happen to love doing UX research. I love writing software, but sometimes it is a fun break to step into someone else's shoes. For large projects with unknown features, it is necessary to take the time to thoroughly communicate with users before writing any code.
Based on my experience, there are a few simple rules to exchanging a dialogue with users that are helpful to us developers in researching:
1. Do more listening than talking
As programmers, we have tendency to want to solve the problem immediately. Avoid suggesting changes and interrupting. Let people talk and just listen! You will learn so much more that way.
2. Everyone's opinion is valid
We are human. Everyone does things differently and that is okay. One person likely has a completely opposite workflow from another and neither is incorrect.
3. Speak like a human (not a computer)
This is kind of silly, but developers do communicate in technical terms with each other. Because of that, I've heard many developers drop the same phrases to users leaving users perplexed. If a user asks you about an issue, don't reply with, "the solution is non-trivial." It might be, but that means absolutely nothing to your users who are simply trying to use the tools you've provided them.
4. Follow through
This is so, SO IMPORTANT! If you have sat with users to plan and develop a piece of software collaboratively, never put it out into the world and drop communication. Always, always follow up. Your users will discover things you might not have thought of and help you make refinements.
Following these helps to ensure not only a clear plan for development, but will prevent scope creep in the long run. The unexpected bonus is often a more mutual respect on both sides for developers and users.