I was sitting in a project meeting recently discussing a design with the team, and the feedback was frustrating.
Many people looking at the page we were critiquing said, “I don’t understand why we put so much emphasis on the application contact information, when what the user’s here for is the subscription information.”
“But this is the application page,” I argued. “The subscription information was added as an afterthought — as a nice to have. It’s not the point of the page.”
The room didn’t see it that way. They, acting as users (and they all had the right mindset to act as users in this situation), wanted to know where to find their subscription information, which was important. And we’d given them a page to do it, but that page was “cluttered” with application information.
When we hear the word “clutter”, we often think of useless stuff that gets in our way when we’re trying to do something. But both on my desk and on my webpages, it’s generally true that the “clutter” isn’t truly useless, it’s just in the wrong place at the wrong time. That pile of pens blocking space to put an important stack of papers isn’t useless or I’d throw the pens out. The pens just aren’t where they belong.
But the information about applications was where it belonged. It was on the applications page. So it wasn’t clutter; arguably, the subscription information was cluttering the applications page, not the other way around.
The problem wasn’t the “clutter”, the problem was that we’d put two top-level goals on the same page. In this case, we’d put the goal of “tell me about my applications” and “tell me about my applications’ subscriptions” on the same page.
When two top-level goals are competing for a page, one or the other is always going to seem like clutter to the user. Any given page can support one and only one top-level goal. My friend Ellen King calls this “every page has a hero”.
The hero is the point of the page. Why do you have an Accounts page on your bank website? To describe the list of accounts. Why do you have a separate Account Details page? To provide all the details of a single account. It’s possible that if only one account exists, you might skip the Accounts page, but that’s because that goal is irrelevant, not because you’re serving both goals.
One of my favorite guerrilla usability tests is the “what does this page do?” test. It’s similar to the five-second test.
- I remove the page title.
- I print the page I’m testing.
- I walk up to someone who’s not on the project (works best at the free-food table), and say, “I’m going to show you a page and I need you to tell me what it’s about. Ready?” Generally they eye me with suspicion and then nod.
- I show them the page for somewhere between one and five seconds, then hide it again.
- I ask, “What’s the point of that page?”
In a perfectly-designed world, the answer is always what I think it should be.
When we had reviewed the page in a design critique (where the page had a title) everyone understood it was the applications page. Without the title, most people thought the page was about the subscriptions. Our content wasn’t aligning with our goals – or rather, our content was revealing two different heroes.
This concept — that every page has a single primary goal whose success outweighs every other goal — is integral to a good design.
- If you can articulate the goal, then you can name the page, and you know how to refer to it in the navigation.
- If you can name the page, your users can identify whether a page is about the goal they’re trying to meet.
- Articulating the goal also helps you group the page with similar goals, or know how to order the page in a process flow.
- Understanding the goal helps you prioritize it with the other content on the site. Does it support the overall’s site goal? Or is it a tertiary thing that, ultimately, could be cut?
It’s important to note that while literally every page has a hero, some pages have heroes that aren’t as easy as labeling the Applications page “Applications”. Your site homepage, for example, probably has a huge list of competing goals and capabilities. (That’s one of the reasons I recommend a capability strategy sheet, especially for menu pages). But the top goal of a home page is (generally) “show me all the things I can do here”, “show me what you’re about”, or “sell me the product”.
“Every page has a hero” also simplifies in-page content strategy, because everything on the Applications page should serve the goal of “Tell me about the applications.” Otherwise, they’re clutter.
Your Project Manager wants to add a shout-out about extra features on the accounts page? Are they extra account features? No? Then in this context they’re clutter, and they go somewhere else where they better fit the context.
(Note: your mileage may vary in convincing your PM to keep things like advertising off the page, although I think we can all agree that advertising doesn’t serve anyone’s hero ever.)
When I’m doing high-level happy-path design, I’ll often skip the step of documenting the page goal in my wireframes because we’re still at the investigating stage and it’s probably not yet important. (Invision and similar tools make it harder to add this kind of documentation somewhere obvious anyway, but that’s a rant for another day.)
When I’m doing mid-level or detailed design, though, especially if it’s with developers or business folks who are new to working with UX, I document it loudly and clearly.
First, it makes sure that I’m doing my own due diligence. If I can’t put a statement on my wireframes that says “Page goal: _______” and fill in the blank, the page is broken, and will cause me nothing but heartache until I fix it.
Second, it makes sure that people down the road understand what we intended the page to do. This can both foster understanding in the sprint, and foster understanding four years later when someone is redesigning the whole site section and wants to know the history of the old design.
(And yes, I’m one of those designers that will still have my wireframes from “the last time we redesigned it” so that we don’t break things we already fixed, and so that we can revalidate the page goals.)
Speaking of fixing pages and accomplishing goals, our solution was simple: we now have two pages on the site, one for Applications where users can maintain their contact information at a per-application basis, and one for Subscriptions, where users can see what subscriptions they have on each application and modify those subscriptions. It did mean adding another top-level tab to our navigation, but in this case the site was so small that the extra tab had a negligible effect on the overall architecture.
Now when users look at the pages, they understand what each of them does and why they’d visit them.
Every page has one, and only one, hero. Know your heroes, and articulate them. Then ensure your page content serves them. You’ll save yourself a lot of architecture and design problems from that point forward.
