From following frameworks to creating them

TL;DR: Frameworks are useful because they give us proven ways to work through problems, but they don't have all the answers. While working on a SaaS product, my co-worker, a software engineer, and I reached a point where the design methods we normally relied on weren't helping us move forward. By stepping back and asking a different set of questions, we came up with a simple framework that helped us clarify the problem and find a solution. The experience reminded us that the real value of a framework isn't in following it exactly. It's in understanding why it works. Once you understand that, you can adjust existing frameworks or create your own when a problem calls for a different approach.

If you've ever worked in product design, or really any discipline that involves solving complex, ambiguous problems, you've probably leaned on frameworks. And for good reason, because they work.

Frameworks give structure to ambiguous problems. They take a sprawling problem space and hand you a way in. Whether it's a Jobs to Be Done interview, a user journey map, an affinity clustering session, or a round of Crazy Eights, these tools exist because smart people ran into hard problems before you did, developed a repeatable way through them, and wrote it down. When you're staring at a blank wall wondering where to begin, a good framework is a genuine asset.

For a lot of designers and product thinkers, accumulating those frameworks, learning them, practicing them, knowing when to reach for which one, is core to the craft. The more you have in your toolkit, the more capable and adaptable you become. That is genuinely true.

But there's something that doesn't come up as often: what happens when you run out of them.

While working on a SaaS product, my co-worker, a software engineer, and I found ourselves leaning heavily on that toolkit. We were part of a small team working through a novel problem space, and the frameworks were our scaffolding. We ran discovery sessions structured around Jobs to Be Done, mapping out what users were actually trying to accomplish and where existing solutions were falling short. We used journey mapping to understand the full arc of the user experience. We did affinity mapping to make sense of our research, tracking insights until patterns emerged that we could design around.

As we moved from discovery into ideation, HMW statements became a constant companion. If you haven't used them, the idea is simple: you take a problem or insight and reframe it as an open question that invites creative solutions. "How might we help users understand their progress without interrupting their flow?" They are generative and they keep you in the right mindset, curious and possibility-oriented, when it's tempting to follow the first solution that shows up.

We used all of these tools continuously. They were the way we thought together, the shared language we developed as a UX designer and software engineer working through challenging design problems day after day.

Then we hit a wall.

We were deep in the design of a specific feature, one component within a larger product context we were contributing to. It had been a stubborn one. The obvious solutions didn't fit. The less obvious ones kept falling apart under scrutiny. We had run HMW statements, sketched, critiqued, gone back to the research, and approached it from different angles across a few sessions.

Nothing was quite sticking.

There's a particular kind of feeling that sets in at that point. It's not the energizing friction of early-stage ambiguity where everything feels open. It's the feeling that you've been working hard and moving, but you're somehow nearly in the same place you started. The tools were running but the engine wasn't turning over.

So we stopped. Not in defeat, we just stepped back and decided to stop trying to solve it for a minute. We needed a wider view. We'd been so close to this feature for so long that we needed to reorient. What were we actually trying to do here? Not at the product level, not in terms of the broader problem space. What was this specific feature, fundamentally, supposed to be?

That's when my co-worker said it. We were somewhere in the middle of that reset conversation and he paused and said something like: "Wait, hold on. So, what does it do?"

Not what should it do. Not how might we make it better. Just: what does it do?

It was a plain question, almost embarrassingly simple. But it hung in the air for a moment. We'd been so deep in ideation mode that we had drifted from the most basic question about the thing we were designing. We didn't have a crisp, shared answer to what it actually did. A useful design cannot exist without that clarity.

We sat with it, wrote it down, tried to answer it in one sentence and then two. And then, almost on its own, the companion question surfaced: what does it not do?

That was the pivot. We stopped writing HMW statements and started writing what we ended up calling WDID statements (What Does It Do) and WDIND (or !WDID) statements (What Does It Not Do).

A WDID statement is a plain declarative sentence about the core behavior of the thing you're designing. It does this. It does that. Not aspirationally, but as a matter of design intent. A WDIND statement draws the boundary: it does not do this, it is not that, it explicitly refuses to be the other thing you keep almost accidentally designing it into.

What we discovered is that these two types of statements do something that HMW statements, for all their value, are not designed to do. HMW statements expand. They open the solution space and multiply possibilities. That is their job and they are good at it. But at some point, expansion is not what you need. At some point you need definition. You need to draw a box around the thing and say: this is what it is, and that is what it is not, and now design from there.

The WDIND statements turned out to be especially useful. There is something about articulating what a thing is not that makes its identity legible in a way positive description alone does not always achieve. Scope creep often starts as an answer to a HMW question, and WDIND statements act as a direct counterweight. They make choices explicit and force commitment.

By the end of that session there was a clear, shared picture of what this feature was. Not a wishlist, not a set of possibilities, but a definition. From that definition, a solution emerged that neither of us had arrived at through prior work. It was genuinely novel and became one of the most successful outcomes of the project work we contributed to.

HMW statements never failed us. We used them well, up until the point where we needed something different, and then we needed to recognize that and reach for something else. The something else did not exist yet, so it was created.

That is the meaningful part. Every tool in the design thinking canon was invented by someone who was stuck, figured something out, and wrote it down so the next person would not have to start from scratch. They were doing exactly what we did. They just got there first.

The designers and product thinkers I have learned the most from do not just know a lot of frameworks. They understand why each one works. They understand the underlying logic well enough that when the situation calls for something new, they can build it. Once you understand that, you can ask: what other reframe does this problem need right now? The answer for us was a definitional one rather than a generative one. So we built a definitional tool.

If you find yourself having run every play you know and still not moving, that is not a failure of process. That may be the moment your process is ready to grow. The frameworks you have internalized become raw material. The concepts you have borrowed become starting points. And the thing you build out of necessity, scrawled in the margins of a session that was not working, might be what you return to for years.

WDID and WDIND are ours. They came from one afternoon of being genuinely stuck, with a co-worker who is a software engineer and who asked the simplest possible question. The version you build will come from your own stuck moment, your own problem, your own plain question that breaks through.