Imagine you are a homeowner, and you need to renovate your kitchen. You do your research and hire a contractor. On day one, he shows up with a big trailer behind his tough-looking truck. You’re excited. But something weird happens. Every time you see him working, he’s only got a hammer. No measuring tape. No level. No saw. Just a hammer, or two.

The contractor swings it with confidence. They can drive nails like a pro. They’ve even gotten good at taking measurements with it. “That’ll be 5 hammers plus a head”. They’ll even bring in a sledgehammer every once in a while. But would you trust them to rebuild your kitchen? Handle the plumbing and electrical? Lay new flooring? Install the cabinets level?

Nope. Definitely not.

But, in digital experience design, we see this all the time. Designers rushing in to “solve” problems with one big hammer: a UI layout. Maybe it’s a “lo-fi” wireframe, or maybe they jump straight into hi-fi layouts in Figma. Either way, they are dragging rectangles around, hoping to fix whatever experience problem is in front of them. And just like that contractor, they make progress and look busy, but are they really being effective?

If we want to design truly great experiences, we need more than a hammer. We need a broader set of tools and the wisdom to know when to reach for each one.

Jesse James Garrett’s Elements of User Experience lays out a time-tested framework for what’s needed to create a user experience.

When most people think of “UX,” what they picture is the user interface. That glossy finish on top of a much deeper structure. For most of the UX partners, it’s the most compelling visual. And, at some level, UX designers have reinforced this expectation by over-relying on UI layouts to communicate.

But user interfaces are just that, “interfaces”. They’re the top-most layer that a user interacts with to experience the value that lies within a product or service. Interfaces are extremely important, but it’s only the access point of a good experience. They include what Garrett dubs the “surface”, or the visual styling and branding of the interface, and the “skeleton” which includes the structural nature of interface layout, navigation structures and patterns, and informational layouts and choices.

But, lingering beneath the shiny interface are critical foundational layers:

Structure: Interfaces are supported by information. Information is accessed by moving around to different spots within the system. Both the organization of the information and the choreography through the system must be solid or the interface will fall flat. If users don’t get the info they need, game over. If they can’t easily get from one spot to another, then they bail.

Scope: More importantly below the supporting structure is the scope of the product or feature. There must be a line in the sand explaining what’s in the product or service and what’s not. There must be clarity around what a feature means, and what’s needed for it to be valuable.

Strategy: For a product or service to be successful it must be created with users in mind. There must be a definition of what users want and what we choose to build for them. And, more importantly we must know what we will not build. It must be backed up by a solid business model that can support the product.

Each of these layers interact with the others, creating a strong, coherent experience from the ground up. If you only focus on the surface without addressing the underlying structure, you may fail to address the problem.

Understanding this metaphor of layers is essential for two reasons:

1. Identifying the problem type. It’s never as clean as a single layer, but typically the bulk of a problem lives in one of the layers that Garrett has laid out. Is the data well organized? Are we targeting the right users? Do workflows have logical steps and progression? The answers to these questions lead to the next reason.
2. Choosing a tool to solve it. You wouldn’t use a hammer to cut a board (I suppose you can, but it’ll be way more work and end up as a mess). In the same way, you can’t use UI layout to solve deeper information organization problems (well, you can, but it’s a lot more effort, and you would make a mess).

Each layer focuses on different types of questions: Why are we building this? What needs to be included? How will it be organized? How will it behave?

But we often find ourselves under deadlines and real-world pressure to ship it quickly. It’s tempting to stay in the interface layer to “save time”. Sure, it’s fast. It’s visible. It feelsproductive. You can show something tangible to stakeholders. But skipping layers can be like skipping steps in building a house. No matter how beautiful the walls look, if the foundation is messed up, it will eventually crumble.

UX Designers must be comfortable and skilled in wrestling with problems in all the layers. It takes patience to define strategy, intentionality to shape structure, and the foresight to ensure the skeleton will hold what we want to build.

After that exploration of the layers, I hope you start to feel the tension. When you’re in the middle of a project and things get fuzzy, opening your UI layout tool of choice can feel like progress. It’s fast. It’s concrete.

You can quickly start laying out information, drop in some buttons, craft the necessary content, add a dash of icons and typography. Look at you go! You’ve built a thing!

But when we jump straight to UI, we miss opportunities to address different kinds of problems:

• Clarify the user’s real goals. Determine the primary task the user needs to complete, and thus drive the affordances and signifiers you choose, and the visual hierarchy you construct.
• Align the front and backstage processes that support the experience. Digital experiences are supported by a variety of digital and human services that a consumer may never see. We are always seeking to provide harmony between the optimal experience of the user and the services needed to support it.
• Untangle broken user flows. Revisit the series of steps a user is proceeding through. Consider different choreography options that make more logical sense to the user.
• Fix missing or confusing content structures. Revisit not just one screen, but the entire context of the workflows and the application to ensure content is consistent throughout. Additionally, you can ensure that you balance too much information with too little, and leverage progressive disclosure. (This is not an excuse to just “add some content” to fix it.)

After looking at these few examples, you should see that the kinds of problems in digital experience design live at multiple different levels. They are of different kinds and types. Some are about organization, others about choreography, others about visual prominence, others about value match, and still others are more varieties than I have space to lay out here.

In my opinion, only a small percentage of UX problems are directly UI problems. So where does that leave us?

As we engage with the various kinds of problems, I recommend using Garrett’s layers as a diagnosis tool to help pinpoint the type of problem you’re dealing with. Then, grab an appropriate tool off the shelf to help with that problem type. You shouldn’t use a hammer to drive in a screw. And, you shouldn’t jump to your favorite UX tool or technique too quickly.

Here are a few of my favorite “deep tracks” from the world of UX that I’ve grown to love:

• Creative short-form briefs: From Jared Spool, these help you quickly define the real problem, constraints, and goals of a project or feature. It helps bring alignment to the end user and the goals of the project.
• Object mapping: From Sophia V Prater, this tool helps you organize the elements of objects (conceptual elements) which lays a clear foundation for representing them to the user. It identifies prominent elements of the digital experience and their relationships. (Learn more by checking out OOUX)
• Service blueprints: This is one of my personal favorites when dealing with a new or complex workflow. It brings UX close to development partners to clearly show what’s needed at each step from the user and the system.
• Wireflows: It’s not user flow and it’s not a wireframe. It’s in-between. I love using these to map and give more life to how a user will accomplish tasks, step by step, before any details are added to a screen. In combination with a service blueprint, this is a powerful visual. It also helps identify high-level patterns that can be used throughout a flow or a digital product.

These are just a few of my go-to tools. Each tool shines a light on a different part of the experience. They help you see the invisible stuff that UI layout might miss or make a mess of. UI layout is still an appropriate tool, but it’s best used when you’re dealing with a UI kind of problem.

Before I go any further, I don’t want to be mistaken for saying something I haven’t. You don’t need to use every tool. Effective designers aren’t over-eager with all the tools in their shop. They’re problem solvers. So they evaluate the best tool for the job and leave the rest back in the shop. If the tool fits the job, then they’ll grab it off the shelf or out of the yard.

Resist the temptation to use each tool as a “step” in the “design process”. Just don’t do it. Not every project needs you to bring in the heavy pneumatic jackhammer of service design. Not every project needs a full audit of the pages or views within an app. Not every project needs a full-on card sort. Sometimes all you need is a simple hand-drawn picture. And other times you may need a mix of tools and approaches to get the job done. Slow down to identify what tools are most helpful. Develop the skill to know which tool to grab based on the problem you’re facing.

Choosing wisely saves time, focuses effort, and makes your design work stronger.

Years ago, I was looking for a new job as a Lead UX Designer. As part of the interview process, I was given a design assignment (it was an era where this was more common). The challenge was given pretty clear, straightforward goals. I only had a few hours to work, so I set off to it quickly. Given the time pressure, I could have gone straight into UI layout and polishing screens to make something beautiful.

But I didn’t. I started by mapping out key flows to meet the goals of the user in this hypothetical project. I did some planning and organizing, then I set off to some wireframes to make it real enough to show my thinking and direction. I didn’t even get to a full prototype. I didn’t even have color or appealing typography. I ended up showing a crappy black-and-white wireframe with a few clickable elements to demonstrate key points. It was a pseudo-prototype.

Why do I tell you this story? Because the core problem I was solving for in this challenge was not a UI problem. It was a choreography problem. I spent more time mapping out the path a user would navigate, rather than the screens they would see in the experience.

And you know what? That’s what got me the job. They saw me targeting the core problem and not just the pretty visuals. Later I learned that I was actually competing against one other designer in this round. The other candidate? They created a beautiful UI, but it lacked the structure and rigor of a smooth flow. It came down to targeting the right level of problem. And that’s what led to multiple successful product releases over the years in that role.

If you want to grow in your UX work, I encourage you to slow down and look at the UX problems you encounter. Don’t assume that it’s a blank canvas for sparkly UI, but rather complex structures that need precision to target the level of problem you’re dealing with. It takes practice. It takes a little time up front. Most of all, it takes intention.

So, back to our contractor analogy. Be the kind of contractor who not only has the tools needed for the job, but the kind of person who chooses their tool carefully. Be the kind of contractor who understands what’s needed and can craft with precision because your tool matches the need for the job.

Design isn’t about swinging the same tool harder. It’s about knowing which one to reach for…and why.