Defining the Problem Space: A Love Story between Engineering and UX
I’ve recently been teaching UX through a series of workshops on behalf of the UBC UX Hub to help get students into the field. As a mechanical engineer, one thing stood out to me as I was planning out the first exercise — and that was defining the problem space.
Let’s face it: engineers get a bad rep for not thinking about design when it comes to building out projects. Bear in mind, this goes beyond just thinking about how “pretty” or “user-friendly” the overall end-product is, but if we look at what design is as a whole, we’re only scratching the surface when it comes to understanding what’s really goes on.
As I was putting together the slides for our first UX workshop, a good friend of mine randomly messaged me with a casual question:
How would you design a touchless interface for an elevator?
As I explained my thought process through a series of eloquently-crafted, multi-lined text blocks, it occurred to me that I had been speaking with the left side of my brain; that is, the part of me that the faculty of engineering has been shaping for the past five years. But before I could correct myself, I had a thought about what I had written, and came to a realization. Let me paint you a scene.
It’s noon on an average Monday, and instead of having lunch with the boys, you’re at your MECH 467 (Computer Control of Mechatronic Systems) class. Today’s topic: state space analysis (yum). As the TA begins to draw out the block diagram of the ball-screw drive system, it occurs to you: I have no idea what I’m doing.
After a brief moment of panic followed by a short sense of disbelief in your abilities to pursue this degree any further, you look back at the tutorial handout and you realize that they give you a lot of information to begin with.
System variables, check. Initial conditions, check. The format for deriving the A, B, C and D matrices of the discrete state space form, check. You’re feeling pretty confident, and now you can miserably fail at solving the problem, but you start either way.
So what does this ball-screw drive system tutorial and UX have in common? A place to start.
The one thing I realized that engineering teaches us is to first understand the problem we’re trying to solve. Take the situation and break it down into manageable chunks. What are the limitations? What constraints are we working with? What reasonable assumptions can we make at this point? It’s such a crucial step in the engineering process, but once we’re given a question like this in a design-context, everyone starts talking about what sensors to use and how big the elevator should be.
As much as I’d to talk about using eye contact to determine the floor you want to go to, let’s not forget to think about why this problem matters in the first place. Who is our user? What is the scope? What limitations and constraints can we set? and so forth. Engineers define these boundaries in order to tackle the problem from an approachable angle and broaden these as we make progress.
In doing so, we define our starting point and use customer discovery and research in order to validate our assumptions and learn more about our user.
So on October 26th, we held our first workshop on the introduction of UX, where we tested out the idea of starting off with defining the problem space. We gave them the scenario of designing a touchless interface for an elevator, and asked them to map out the tasks and requirements for able-bodied users and users with disabilities.
As expected, we were met with mixed reactions about the exercise, which is totally fair. I used to be someone who would rush right into a solution without really thinking about the consequences of my designs. In a workshop setting, this is a common mistake with no real effect on anything, but when people’s lives and company reputations are on the line, there’s no question that understanding the problem at hand is a must.
So what’s next? We will explore the second stage of the UX process, and that is gathering data, but what determines good research? Is this information even relevant? Am I asking the right questions? Find out at our second workshop on November 2nd from 6pm to 8pm!
