Fall in love with the problem, not the prototype

Every studio has a story about an idea that was too juicy not to build. A live map. A beautiful timeline. An AI assistant in the corner of every screen. At Always 49 we know that feeling from the inside, which is why we have a rule about it. Fall in love with the problem, not the solution. The prototype is allowed to be charming. It is not allowed to become the brief.

This is a UX rule that doubles as project hygiene. Once a solution has been praised, the team starts protecting it. Objections become “edge cases”. Research that does not fit becomes “an outlier”. A client who is excited can accidentally freeze a bad idea by loving it too early, especially if it looks finished. That is why we hold visual fidelity back until the problem is clear. A sketch that fails is a conversation. A polished prototype that fails feels like a confrontation. People avoid confrontations. They do not avoid the user pain, which then leaks into launch.

What does falling in love with the problem look like in practice? It looks like staying with the awkward sentence. “We never know if the check is actually complete.” “Donors drop off when we ask for too much too soon.” “Drivers cannot prove the delivery without a paper stack.” “Staff spend Friday rebuilding a report the system already almost has.” Those sentences are gold. They are more valuable than a feature named after a competitor. Features are solutions in costume. Problems are the work.

We still bring our own knowledge. User-first does not mean the client and the user are always right about the fix. They are usually right about the pain. Our job is to mix that pain with what we know about interaction design, accessibility, and the way software ages. Sometimes the right response to “we need a dashboard” is a better email, a calmer default, or removing a step. Dashboards are a common way to look like you have solved visibility without making anyone more able to act. Action is the product. Charts are optional.

Testing is the anti-crush mechanism. Put the beloved prototype in front of someone who does not owe it loyalty. Give them a task, not a tour. If they cannot do the task, the prototype has not earned more code. This is uncomfortable for teams who have already scheduled development. Good. Discomfort at this point is the process supporting people. It supports the developers who would have built the crush. It supports the users who would have been trained around it. It supports the client who would have paid twice.

AI has made this rule harder, because generation makes solutions appear before problems have been sat with. You can now have five interface directions before you have a single verified user need. That feels like abundance. It is often avoidance. Exploring options is healthy after you can name the job to be done. Exploring options instead of naming the job is how you get a museum of plausible screens. Always 49 would rather one plain flow that removes the pain than a gallery of inventive ones that do not.

There is a human side for clients too. People come to us with a picture of the thing they want to exist. We respect that picture. We also ask what life looks like if it works. Time back. Fewer errors. A volunteer who can run the process without a specialist. A customer who does not need a phone call. If the picture on the wall does not produce that life, the picture is the wrong object of affection. We will help you find a better one. That is the spark of creativity we talk about on the site. Creativity in service of the problem, not in spite of it.

If your current project has a favourite screen, try a blunt experiment. Hide it. Can you still describe the user pain in a sentence that a stranger would care about? If you cannot, you are in love with the prototype. Come back to the problem. The software will be simpler, the process will be kinder, and the people on the other side of the interface will not have to admire your cleverness in order to get their work done.