How Does a Designer Work on a Team Focused on Problem Definition?
The Alarmy team always focuses on finding the root problem, not just surface-level phenomena
Since joining DelightRoom, the words I've used and heard the most are probably WHAT, WHY, and HOW. Even now, regardless of our roles, the Alarmy team always aligns on the core of the problem before diving into any work.
I’m writing this post to organize my thoughts and share the process of defining problems and deriving solutions as I grow as an Alarmy designer.
Close Figma for now
Focus on the steps that matter more than visualization!
For a designer, visual imagery holds a massive power to make abstract ideas concrete. But sometimes, that exact power ends up trapping our thoughts in a rigid box.
When visual deliverables are shared before we fully align on our goal or the problem we're trying to solve, the entire team often gets boxed into the limitations of those visuals. If the initial alignment focuses solely on the visual output, it's dangerously easy for the team to lose the project's direction—to the point where we forget what we originally set out to do. And when the creators themselves lose their way, the resulting work naturally fails to resonate with other teammates and users alike.
For this very reason, aligning with teammates on the purpose and the problem early on—before discussing the deliverables—is incredibly important. Plus, once that initial alignment is solid, discussing the deliverables becomes a whole lot easier.
Specifically, it becomes much easier for the team to evaluate whether the final design is actually good. When you look at the design through the lens of "Does this achieve our goal and solve the problem?" and "Is our initially aligned solution properly applied?", the criteria for judging the output won't vary from person to person, leading to far more efficient discussions.
So when a project kicks off, close Figma and hit pause on visualization!
Finding the purpose and problem of what we're trying to do, and aligning everyone on how to solve it, is way more important than making things look pretty!
What's the problem getting in the way of your goal?
Finding problems based on the goal
Alarmy designers often define the WWH (What, Why, How) on their own, but we also spend a lot of time aligning on and fleshing out the WWH brought in by a PM. To fully grasp the PM's WWH, I think it's crucial for the designer to be able to redraw that WWH using their own perspective.
There are many ways goals and problems get established, but when the company's growth direction is clear, the business objective the team needs to achieve is often communicated very clearly. In these cases, we focus on pinpointing exactly what the problem is when trying to achieve that clear goal.
Whenever a specific feature needs to be improved or a new one created for business reasons, we proceed by sharply identifying the obstacles getting in the way of that clear goal, and then deriving the appropriate solutions.
Let's take the revamp of Alarmy's Today's Panel as an example!
Today's Panel is a key page that serves up morning content to the user, but it's also a major advertising monetization touchpoint.
The goal we want to achieve with Today's Panel is clear: get as many users as possible to stay there as long as possible.
For a project with such a distinct business purpose, we look for the problem hindering that goal and come up with a solution like the following:
Turn the solution back into a design goal
Breaking down the 'How' into user actions to set design goals!
From the Today's Panel example above, we derived:
[What] To increase retention time,
[Why] tackle the problem of users not seeing the information they want,
[How] by reconstructing Today's Panel so they can see the information they personally select.
Once aligned this far, the designer moves on to their own specific workflow.
We break the solution down once more into design goals.
A design goal is set by breaking down the core units of action we need to ask the user to perform in order to implement the solution.
As shown in the image below, we can break down the Today's Panel solution even further.
The more you break down and specify the design goals beyond the example, the clearer the alignment on direction becomes, though how granular you get varies depending on the task.
Once the design goals are neatly chopped up into action units, it's time for the designer to map out the optimal UX/UI to achieve them.
You start brainstorming how to better hit those design goals, do your research, and now, finally, you can open Figma and bring it to life visually.
One more thing: Another way designers define problems
Observing phenomena, defining problems, and achieving results (goals)
While putting this post together, it hit me again that the Alarmy team actually splits our problem-definition approach into two distinct methods.
Above, I talked about working in a What → Why → How sequence for tasks with a crystal-clear purpose. But for designers, we also frequently find problems to improve based on visible phenomena.
In these cases, rather than defining the problem through a goal, we define it through the phenomenon itself. We don't just accept the phenomenon as the problem; we separate the two, define a more fundamental problem, and then figure out how to solve it.
If we try to map the phenomenon we see directly to a solution, our work loses its edge.
For example, let's say we observe the phenomenon: "Subscription users aren't utilizing all the premium features." If we jump straight to a solution, it just maps to "Make subscription users use premium features."
It's hard to imagine what exactly we should build. There seem to be way too many ways to do it. And even if we find a method, the criteria for judging whether this work was a success would be completely blurry.
That's exactly why we have to dig into the phenomenon, find the real problem, and flesh it out.
There could be all sorts of problems hiding within that phenomenon, but in the example below, we defined the problem as: "Users don't even know which features they've used and which they haven't."
From there, a much more concrete solution emerges compared to before.
When defining a problem starting from a phenomenon like this, the Alarm design group uses a custom problem definition table (like the one below) to ensure crystal-clear alignment. When a designer creates a backlog item themselves, they express it in the most specific, concise sentences possible so that we can clearly sync up just by reading the document. The golden rule is writing down exactly what we intend to do in a way that anyone can easily understand.
Wrapping up
Like in any team, if you aren't aligned on why you're doing the work, it's hard to even get started. I believe that syncing on why we need to do the work and why something is a problem is the absolute first step—an essential phase where we must invest a lot of time to ensure everyone completely understands.
Spending heavily on time upfront might look inefficient at first, but ultimately, you'll find that it cuts out a massive amount of inefficiency down the road.