You are here

thinktime

Accessorials cost extra

Seth Godin - Sun 20th May 2018 18:05
{not a typo} In the trucking industry, they usually don't include the extra charges, unforeseen or not. "Accessorials" not included. Which often leads to surprise down the road for those that don't expect them. Tonu is another useful lesson. "Truck...        Seth Godin
Categories: thinktime

Mass personalization is a trap

Seth Godin - Sat 19th May 2018 18:05
Dear seth , Of course I could have sent you a personal letter. A direct 1:1 connection between you and me, thanking you for what you did, or letting you know about my new project, or asking for your attention....        Seth Godin
Categories: thinktime

Are you a genius?

Seth Godin - Fri 18th May 2018 18:05
In the latest episode of my podcast Akimbo, I riff about what it means to be a genius. Hint: You are one. PS more people are subscribing every day. It's short, free and sometimes fascinating. All the cool kids are...        Seth Godin
Categories: thinktime

The difference between time and money

Seth Godin - Thu 17th May 2018 19:05
You can't save up time. You can't refuse to spend it. You can't set it aside. Either you're spending your time. Or your time is spending you.        Seth Godin
Categories: thinktime

The triumph of everyday design

Seth Godin - Wed 16th May 2018 19:05
Luxury goods used to be better. Better than the alternatives. The best-made clothing, the best saddle, the most reliable luggage. The top of the market was the place people who cared needed to go to buy something that had the...        Seth Godin
Categories: thinktime

"You were right all along"

Seth Godin - Tue 15th May 2018 19:05
There's a hierarchy in the adoption of new techniques and approaches, particularly in the b2b setting: You were right all along: The thing you were waiting for is here. All of the cool kids are using this now: Take a...        Seth Godin
Categories: thinktime

The problem with forced rankings

Seth Godin - Mon 14th May 2018 17:05
What's the best college in the US? What about the best car? Best stereo speakers? Best pizza? The answer is always the same: It depends. People hate that. "It depends" puts you on the hook, requires you to have priorities...        Seth Godin
Categories: thinktime

Tactics without strategy is a scrum

Seth Godin - Sun 13th May 2018 18:05
When your timeline is an hour or a day, it's easy to get in the tactical groove. But repeat that hour after hour, day after day, and all you're making is a mess. This is bureaucracy run amok. This is...        Seth Godin
Categories: thinktime

Easier said than done

Seth Godin - Sat 12th May 2018 18:05
But at least you said it. It's a mistake to hesitate on the saying part. Because if you don't say it, it's unlikely to get done. Dreams, goals and projects don't require a likelihood of success merely to be discussed.        Seth Godin
Categories: thinktime

Monopoly is the goal, monopoly is the problem

Seth Godin - Fri 11th May 2018 19:05
Every public company seeks, at some level, to be a monopoly, an organization with enough market power to dictate pricing, profits and the future of the market. And monopoly is also a critical failure of capitalism. When monopoly occurs, when...        Seth Godin
Categories: thinktime

So You Want to Write an Article?

a list apart - Fri 11th May 2018 00:05

So you want to write an article. Maybe you’ve got a great way of organizing your CSS, or you’re a designer who has a method of communicating really well with developers, or you have some insight into how to best use a new technology. Whatever the topic, you have insights, you’ve read the basics of finding your voice, and you’re ready to write and submit your first article for a major publication. Here’s the thing: most article submissions suck. Yours doesn’t have to be one of them.

At A List Apart, we want to see great minds in the industry write the next great articles, and you could be one of our writers. I’ve been on the editorial team here for about nine months now, and I’ve written a fair share of articles here as well. Part of what I do is review article submissions and give feedback on what’s working and what’s not. We publish different kinds of articles, but many of the submissions I see—particularly from newer writers—fall into the same traps. If you’re trying to get an article published in A List Apart or anywhere else, knowing these common mistakes can help your article’s chances of being accepted.

Keep introductions short and snappy

Did you read the introduction above? My guess is a fair share of readers skipped straight to this point. That’s pretty typical behavior, especially for articles like this one that offer several answers to one clear question. And that’s totally fine. If you’re writing, realize that some people will do the same thing. There are some things you can do to improve the chances of your intro being read, though.

Try to open with a bang. A recent article from Caroline Roberts has perhaps the best example of this I’ve ever seen: “I won an Emmy for keeping a website free of dick pics.” When I saw that in the submission, I was instantly hooked and read the whole thing. It’s hilarious, it shows she has expertise on managing content, and it shows that the topic is more involved and interesting than it may at first seem. A more straightforward introduction to the topic of content procurement would seem very boring in comparison. Your ideas are exciting, so show that right away if you can. A funny or relatable story can also be a great way to lead into an article—just keep it brief!

If you can’t open with a bang, keep it short. State the problem, maybe put something about why it matters or why you’re qualified to write about it, and get to the content as quickly as possible. If a line in your introduction does not add value to the article, delete it. There’s little room for meandering in professional articles, but there’s absolutely no room for it in introductions.

Get specific

Going back to my first article submission for A List Apart, way before I joined the team, I wanted to showcase my talent and expertise, and I thought the best way to do this was to showcase all of it in one article. I wrote an overview of professional skills for web professionals. There was some great information in there, based on my years of experience working up through the ranks and dealing with workplace drama. I was so proud when I submitted the article. It wasn’t accepted, but I got some great feedback from the editor-in-chief: get more specific.

The most effective articles I see deal with one central idea. The more disparate ideas I see in an article, the less focused and impactful the article is. There will be exceptions to this, of course, but those are rarer than articles that suffer for this. Don’t give yourself a handicap by taking an approach that fails more often than it succeeds.

Covering one idea in great detail, with research and examples to back it up, usually goes a lot further in displaying your expertise than an overview of a bunch of disparate thoughts. Truth be told, a lot of people have probably arrived at the same ideas you have. The insights you have are not as important as your evidence and eloquence in expressing them.

Can an overview article work? Actually, yes, but you need to frame it within a specific problem. One great example I saw was an overview of web accessibility (which has not been published yet). The article followed a fictional project from beginning to end, showing how each team on the project could work toward a goal of accessibility. But the idea was not just accessibility—it was how leaders and project managers could assign responsibility in regards to accessibility. It was a great submission because it began with a problem of breadth and offered a complete solution to that problem. But it only worked because it was written specifically for an audience that needed to understand the whole process. In other words, the comprehensive nature of the article was the entire point, and it stuck to that.

Keep your audience in mind

You have a viewpoint. A problem I frequently see with new submissions is forgetting that the audience also has its viewpoint. You have to know your audience and remember how the audience’s mindset matches yours—or doesn’t. In fact, you’ll probably want to state in your introduction who the intended audience is to hook the right readers. To write a successful article, you have to keep that audience in mind and write for it specifically.

A common mistake I see writers make is using an article to vent their frustrations about the people who won’t listen to them. The problem is that the audience of our publication usually agrees with the author on these points, so a rant about why he or she is right is ultimately pointless. If you’re writing for like-minded people, it’s usually best to assume the readers agree with you and then either delve into how to best accomplish what you’re writing about or give them talking points to have that conversation in their workplace. Write the kind of advice you wish you’d gotten when those frustrations first surfaced.

Another common problem is forgetting what the audience already knows—or doesn’t know. If something is common knowledge in your industry, it doesn’t need another explanation. You might link out to another explanation somewhere else just in case, but there’s no need to start from scratch when you’re trying to make a new point. At the same time, don’t assume that all your readers have the same expertise you do. I wrote an article on some higher-level object-oriented programming concepts—something many JavaScript developers are not familiar with. Rather than spend half the article giving an overview of object-oriented programming, though, I provided some links at the beginning of the article that gave a good overview. Pro tip: if you can link out to articles from the same publication you’re submitting to, publications will appreciate the free publicity.

Defining your audience can also really help with knowing their viewpoint. Many times when I see a submission with two competing ideas, they’re written for different audiences. In my article I mentioned above, I provide some links for developers who may be new to object-oriented programming, but the primary audience is developers who already have some familiarity with it and want to go deeper. Trying to cater to both audiences wouldn’t have doubled the readership—it would have reduced it by making a large part of the article less relevant to readers.

Keep it practical

I’ll admit, of all these tips, this is the one I usually struggle with the most. I’m a writer who loves ideas, and I love explaining them in great detail. While there are some readers who appreciate this, most are looking for some tangible ways to improve something. This isn’t to say that big concepts have no place in professional articles, but you need to ask why they are there. Is your five-paragraph explanation of the history of your idea necessary for the reader to make the improvements you suggest?

This became abundantly clear to me in my first submission of an article on managing ego in the workplace. I love psychology and initially included a lengthy section up-front on how our self-esteem springs from the strengths we leaned on growing up. While this fascinated me, it wasn’t right for an audience of web professionals who wanted advice on how to improve their working relationships. Based on feedback I received, I removed the section entirely and added a section on how to manage your own ego in the workplace—much more practical, and that ended up being a favorite section in the final piece.

Successful articles solve a problem. Begin with the problem—set it up in your introduction, maybe tell a little story that illustrates how this problem manifests—and then build a case for your solution. The problem should be clear to the reader very early on in the article, and the rest of the article should all be related to that problem. There is no room for meandering and pontification in a professional article. If the article is not relevant and practical, the reader will move on to something else.

The litmus test for determining the practicality of your article is to boil it down to an outline. Of course all of your writing is much more meaningful than an outline, but look at the outline. There should be several statements along the lines of “Do this,” or “Don’t do this.” You can have other statements, of course, but they should all be building toward some tangible outcome with practical steps for the reader to take to solve the problem set up in your introduction.

It’s a hard truth you have to learn as a writer that you’ll be much more in love with your ideas than your audience will. Writing professional articles is not about self-expression—it’s about helping and serving your readers. The more clear and concise the content you offer, the more your article will be read and shared.

Support what you say

Your opinions, without evidence to support them, will only get you so far. As a writer, your ideas are probably grounded in a lot of real evidence, but your readers don’t know that—you’ll have to show it. How do you show it? Write a first draft and get your ideas out. Then do another pass to look for stories, stats, and studies to support your ideas. Trying to make a point without at least one of these is at best difficult and at worst empty hype. Professionals in your industry are less interested in platitudes and more interested in results. Having some evidence for your claims goes a long way toward demonstrating your expertise and proving your point.

Going back to my first article in A List Apart, on defusing workplace drama, I had an abstract point to prove, and I needed to show that my insights meant something. My editor on that article was fantastic and asked the right questions to steer me toward demonstrating the validity of my ideas in a meaningful way. Personal stories made up the backbone of the article, and I was able to find social psychology studies to back up what I was saying. These illustrations of the ideas ended up being more impactful than the ideas themselves, and the article was very well-received in the community.

Storytelling can be an amazing way to bring your insights to life. Real accounts or fictional, well-told stories can serve to make big ideas easier to understand, and they work best when representing typical scenarios, not edge cases. If your story goes against common knowledge, readers will pick up on that instantly and you’ll probably get some nasty comments. Never use a story to prove a point that doesn’t have any other hard evidence to back it up—use stories to illustrate points or make problems more relatable. Good stories are often the most memorable parts of articles and make your ideas and assertions easier to remember.

Stats are one of the easiest ways to make a point. If you’re arguing that ignoring website accessibility can negatively impact the business, some hard numbers are going to say a lot more than stories. If there’s a good stat to prove your point, always include it, and always be on the lookout for relevant numbers. As with stories, though, you should never try to use stats to distort the truth or prove a point that doesn’t have much else to support it. Mark Twain once said, “There are three kinds of lies: lies, damned lies, and statistics.” You shouldn’t decide what to say and then scour the internet for ways to back it up. Base your ideas on the numbers, don’t base your selection of facts on your idea.

Studies, including both user experience studies and social psychology experiments, are somewhere in between stories and stats, and a lot of the same advantages and pitfalls also apply. A lot of studies can be expressed as a story—write a quick bit from the point of view of the study participant, then go back and explain what’s really going on. This can be just as engaging and memorable as a good story, but studies usually result in stats, which usually serve to make the stories significantly more authoritative. And remember to link out to the study for people who want to read more about it!

Just make sure your study wasn’t disproved by later studies. In my first article, linked above, I originally referenced a study to introduce the bystander effect, but an editor wisely pointed out that there’s actually a lot of evidence against that interpretation of the well-known study. Interpretations can change over time, especially as new information comes out. I found a later, more relevant study that illustrated the point better and was less well-known, so it made for a better story.

Kill your darlings

Early twentieth century writer and critic Arthur Quiller-Couch once said in a speech, “Whenever you feel an impulse to perpetrate a piece of exceptionally fine writing, obey it—whole-heartedly—and delete it before sending your manuscript to press. Murder your darlings.” Variants of this quote were repeated by many authors throughout the twentieth century, and it’s just as true today as when he originally said it.

What does that mean for your article? Great prose, great analogies, great stories—any bits of brilliant writing that you churn out—only mean as much as they contribute to the subject at hand. If it doesn’t contribute anything, it needs to be killed.

When getting your article ready for submission, your best friend will be the backspace or delete key on your keyboard. Before submitting, do a read-through for the express purpose of deleting whatever you can to trim down the article. Articles are not books. Brevity is a virtue, and it usually ends up being one of the most important virtues in article submissions.

Your intro should have a clear thesis so readers know what the article is about. For every bit of writing that follows it, ask if it contributes to your argument. Does it illustrate the problem or solution? Does it give the reader empathy for or understanding of the people you’re trying to help? Does it give them guidance on how to have these conversations in their workplaces? If you can’t relate a sentence back to your original thesis, it doesn’t matter how brilliant it is—it should be deleted.

Humor can be useful, but many jokes serve as little more than an aside or distraction from the main point. Don’t interrupt your train of thought with a cute joke—use a joke to make your thoughts more clear. It doesn’t matter how funny the joke is; if it doesn’t help illustrate or reinforce one of your points, it needs to go.

There are times when a picture really is worth a thousand words. Don’t go crazy with images and illustrations in your piece, but if a quick graphic is going to save you a lengthy explanation, go that route.

So what are you waiting for?

The industry needs great advice in articles, and many of you could provide that. The points I’ve delved into in this article aren’t just formalities and vague ideas; the editing team at A List Apart has weighed in, and these are problems we see often that weaken articles and make them less accessible to readers. Heeding this advice will strengthen your professional articles, whether you plan to submit to A List Apart or anywhere else. The next amazing article in A List Apart could be yours, and we hope to see you get there.

Categories: thinktime

Putting a value on a story

Seth Godin - Thu 10th May 2018 18:05
Walk through the diamond district in Manhattan and in the course of one block, at least a dozen men will stop you and ask if you're hoping to sell a diamond ring. A few blocks away, Tiffany will happily sell...        Seth Godin
Categories: thinktime

Considering the buyout

Seth Godin - Wed 09th May 2018 19:05
Is it ever okay to sell the rights to your work? Milton Glaser was paid about $2,000 in expenses to create the I Love NY logo, one of the iconic marketing images of its decade. He later said, "I was...        Seth Godin
Categories: thinktime

We’re Looking for People Who Love to Write

a list apart - Tue 08th May 2018 23:05

Here at A List Apart, we’re looking for new authors, and that means you. What should you write about? Glad you asked!

You should write about topics that keep you up at night, passions that make you the first to show up in the office each morning, ideas that matter to our community and about which you have a story to tell or an insight to share.

We’re not looking for case studies about your company or thousand-foot overviews of topics most ALA readers already know about (i.e., you don’t have to tell A List Apart readers that Sir Tim Berners-Lee invented the web). But you also don’t have to write earth-shaking manifestos or share new ways of working that will completely change the web. A good strong idea, or detailed advice about an industry best practice make excellent ALA articles.

Where we’ve been

Although A List Apart covers everything from accessible UX and product design to advanced typography and content and business strategy, the sweet spot for an A List Apart article is one that combines UI design (and design thinking) with front-end code, especially when it’s innovative. Thus our most popular article of the past ten years was Ethan Marcotte’s “Responsive Web Design”—a marriage of design and code, accessible to people with diverse backgrounds at differing levels of expertise.

In the decade-plus before that, our most popular articles were Douglas Bowman’s “Sliding Doors of CSS” and Dan Cederholm’s “Faux Columns”—again, marriages of design and code, and mostly in the nature of clever workarounds (because CSS in 2004 didn’t really let us design pages as flexibly and creatively, or even as reliably, as we wanted to).

From hacks to standards

Although clever front-end tricks like Sliding Doors, and visionary re-imaginings of the medium like Responsive Web Design, remain our most popular offerings, the magazine has offered fewer of them in recent years, focusing more on UX and strategy. To a certain extent, if a front-end technique isn’t earth-changing (i.e., isn’t more than just a technique), and if it isn’t semantic, inclusive, accessible, and progressively enhanced, we don’t care how flashy it is—it’s not for us.

The demand to create more powerful layouts was also, in a real way, satisfied by the rise of frameworks and shared libraries—another reason for us to have eased off front-end tricks (although not all frameworks and libraries are equally or in some cases even acceptably semantic, inclusive, accessible, and progressively enhanced—and, sadly, many of their users don’t know or care).

Most importantly, now that CSS is finally capable of true layout design without hacks, any responsible web design publication will want to ease off on the flow of front-end hacks, in favor of standards-based education, from basic to advanced. Why would any editor or publisher (or framework engineer, for that matter) recommend that designers use 100 pounds of fragile JavaScript when a dozen lines of stable CSS will do?

It will be interesting to see what happens to the demand for layout hack articles in Medium and web design publications and communities over the next twelve months. It will also be interesting to see what becomes of frameworks now that CSS is so capable. But that’s not our problem. Our problem is finding the best ideas for A List Apart’s readers, and working with the industry’s best old and new writers to polish those ideas to near-perfection.

After all, even more than being known for genius one-offs like Responsive Web Design and Sliding Doors of CSS, A List Apart has spent its life introducing future-friendly, user-focused design advances to this community, i.e., fighting for web standards when table layouts were the rage, fighting for web standards when Flash was the rage, pushing for real typography on the web years before Typekit was a gleam in Jeff Veen’s eye, pushing for readability in layout when most design-y websites thought single-spaced 7px Arial was plenty big enough, promoting accessible design solutions, user-focused solutions, independent content and communities, and so on.

Call to action

Great, industry-changing articles are still what we want most, whether they’re front-end, design, content, or strategy-focused. And changing the industry doesn’t have to mean inventing a totally new way of laying out pages or evaluating client content. It can also mean coming up with a compelling argument in favor of an important but embattled best practice. Or sharing an insightful story that helps those who read it be more empathetic and more ethical in their daily work.

Who will write the next 20 years of great A List Apart articles? That’s where you come in.

Publishing on A List Apart isn’t as easy-peasy as dashing off a post on your blog, but the results—and the audience—are worth it. And when you write for A List Apart, you never write alone: our industry-leading editors, technical editors, and copyeditors are ready to help you polish your best idea from good to great.

Come share with us!

Categories: thinktime

Kurtosis is not a disease (but getting it wrong is painful)

Seth Godin - Tue 08th May 2018 19:05
The mass producers of the world (from ketchup to school) tried to persuade us that by grouping everyone into a tight bundle of normal, everything would become more efficient and we'd all do better. In stats, this is called leptokurtosis....        Seth Godin
Categories: thinktime

Bigger to feel safer

Seth Godin - Mon 07th May 2018 18:05
Creative institutions get bigger so that they can avoid doing things that feel risky. They may rationalize this as leverage, as creating more impact. But it's a coin with two sides, and the other side is that they do proportionally...        Seth Godin
Categories: thinktime

The pre-mortem

Seth Godin - Sun 06th May 2018 19:05
If you want us to take your new proposal seriously, consider including a pre mortem. Include a detailed analysis of why your project might fail. Specific weak spots, individuals who need to come on board, assumptions that might not be...        Seth Godin
Categories: thinktime

Failsafe tip

Seth Godin - Sat 05th May 2018 18:05
The last thing to add to an important email is the email address. Write the thing, save it as a draft, and, an hour later, put the email address in and then hit send. It's not clear that you should...        Seth Godin
Categories: thinktime

How are you organized?

Seth Godin - Fri 04th May 2018 19:05
Any organization of more than two people has a structure, intentional or not. It might be a hub and spoke, a ladder, a pyramid, a lattice, a hive, a circle... Each has an advantage. But the structure of your organization,...        Seth Godin
Categories: thinktime

Priority Guides: A Content-First Alternative to Wireframes

a list apart - Thu 03rd May 2018 23:05

No matter your role, if you’ve ever been involved in a digital design project, chances are you’re familiar with wireframes. After all, they’re among the most popular and widely used tools when designing websites, apps, dashboards, and other digital user interfaces.

But they do have their problems, and wireframes are so integrated into the accepted way of working that many don’t consider those drawbacks. That’s a shame, because the tool’s downsides can seriously undermine user-centricity. Ever lose yourself in aesthetic details when you should have been talking about content and functionality? We have!

That’s why we use an alternative that avoids the pitfalls of wireframes: the priority guide. It not only keeps our process user-centered and creates more valuable designs for our users (whether used alongside wireframes or as a direct replacement), it’s also improved team engagement, collaboration, and design workflows.

The problem with wireframes

Wikipedia appropriately defines the wireframe as “a visual guide that represents the skeletal framework of a website. … [It] depicts the page layout or arrangement of the website’s content, including interface elements and navigational systems.” In other words, wireframes are sketches that represent the potential website (or app) in a simplified way, including the placement and shape of any interface elements. They range from low-fidelity rough sketches on paper to high-fidelity colored, textual screens in a digital format.

Examples of low-fidelity (on the left) and high-fidelity (on the right) wireframes

Because of their visual nature, wireframes are great tools for sketching and exploring design ideas, as well as communicating those ideas to colleagues, clients, and stakeholders. And since they’re so easy to create and adapt with tools such as Sketch or Balsamiq, you also have something to user test early in the design process, allowing usability issues to be addressed sooner than might otherwise be possible.

But although these are all valuable characteristics of wireframes, there are also some significant downsides.

The illusion of final design

Wireframes can provide the illusion that a design is final, or at least in a late stage of completion. Regardless of how carefully you explain to clients or stakeholders that these first concepts are just early explorations and not final—maybe you even decorated them with big “DRAFT” stickers—too often they’ll still enthusiastically exclaim, “Looks good, let’s start building!”

Killing creativity and engagement

At Mirabeau, we’ve noticed that wireframes tend to kill creativity. We primarily work in multidisciplinary teams consisting of (among others) interaction (UX) designers, visual designers, front-end developers, and functional testers. But once an interaction designer has created a wireframe, it’s hard for many (we’re not saying all) visual designers to think outside the boundaries set by that wireframe and challenge the ideas it contains. As a result, the final designs almost always resemble the wireframes. Their creativity impaired, the visual designers were essentially just coloring in the wireframes.

Undermining user-centricity

As professionals, we naturally care about how something looks and is presented. So much so that we can easily lose ourselves for hours in the fine details, such as alignment, sizing, coloring, and the like, even on rough wireframes intended only for internal use. Losing time means losing focus on what’s valuable for your user: the content, the product offering, and the functionality.

Static, not responsive

A wireframe (even multiple wireframes) can’t capture the responsive behavior that is so essential to modern web design. Even though digital design tools are catching up in efficiently designing for different screen sizes (here’s hoping InVision Studio will deliver), each of the resulting wireframes is still just a static image.

Inconvenient for developers and functional testers

Developers and functional testers work with code, and a wireframe sketch or picture provides little functional information and isn’t directly translatable into code (not yet, anyway). This lack of clarity around how the design should behave can lead to developers and testers making decisions about functionality or responsiveness without input from the designer, or having to frequently check with the designer to find out if a feature is working correctly. Perhaps less of a problem for a mature team or project where there’s plenty of experience with, and knowledge of, the product, but all too often this (unnecessary) collaboration means more development work, a slower process, and wasted time.

To overcome these wireframe pitfalls, about five years ago we adopted priority guides. Our principal interaction designer, Paul Versteeg, brought the tool to Mirabeau, and we’ve been improving and fine-tuning our way of working with them ever since, with great results.

So what are priority guides?

As far as we know, credit for the invention of priority guides goes to Drew Clemens, who first introduced the concept in his article on the Smashing Magazine website in 2012. Since that time, however, it seems that priority guides have received little attention, either from the web and app design industry or within related education establishments.

Simply put, a priority guide contains content and elements for a mobile screen, sorted by hierarchy from top to bottom and without layout specifications. The hierarchy is based on relevance to users, with the content most critical to satisfying user needs and supporting user (and company) goals higher up.

The format of a priority guide is not fixed: it can be digital (we personally prefer Sketch), or it can be physical, made with paper and Post-its. Most importantly, a priority guide is automatically content-first, with a strong focus on providing best value for users.

The core structure of a priority guide

Diving a bit deeper, the following example shows the exact same page as shown in the wireframe images presented earlier in this article. It consists of the title “Book a flight,” real content (yes, even the required legal notice!), several sections of information, and annotations that explain components and functionality.

A detailed digital priority guide for an airline’s flight overview page

When comparing the content to the high-fidelity wireframe, you’ll notice that the order of the sections is not the same. The step indicator, for example, is shown at the bottom of the priority guide, as the designer decided it’s not the most important information on the page. Conversely, the most important information—flight information and prices—is now placed near the top.

Annotations are an important part of priority guides, as they provide explanations of the functionalities and page behavior, name the component types, and link the priority guide of one page to the priority guides of other pages. In this example, you can find descriptions of what happens when a user interacts with a button or link, such as opening a layover screen to display flight details or loading a a flight selection page.

The advantages of priority guides

Of course, we can debate for hours whether the creator of, or team responsible for, the above priority guide has chosen the correct priorities and functionalities, but that goes beyond the scope of this article. Instead, let’s name the main advantages that priority guides offer over wireframes.

Suitable for responsive design

Wireframes are static images, requiring multiple screenshots to cover the full spectrum from mobile to desktop. Priority guides, on the other hand, give an overview of content hierarchy regardless of screen size (assuming user goals remain the same on different devices). Ever since responsive design became standard practice within Mirabeau, priority guides have been an essential addition to our design toolkit.

Focused on solving problems and serving needs

When creating priority guides, you automatically focus on solving the users’ problems, serving their needs, and supporting them to reach their goals. The interface is always filled with content that communicates a message or helps the user. By designing content-first, you’re always focused on serving the user.

No time wasted on aesthetics and layout

There’s no need for interaction designers to waste time on aesthetics and layout in the early phases of the design process. Priority guides help avoid the focus shifting away from the content and user toward specific layout elements too early, and keep us from falling into the “designer trap” of visual perfectionism.

Facilitating visual designers’ creativity

Priority guides provide the opportunity for designers to explore extravagant ideas on how to best support and delight the user without visual boundaries set by interaction designers. Even when you’re the only designer on your team, working as both interaction and visual designer, it’s hard to move past how those first wireframes looked, even when confronted with new content.

Developers and testers get “HTML” early in the process

The structure of a priority guide is very similar to HTML, allowing the developer to start laying the groundwork for future development early on. Similarly, testers get a checklist for testing, allowing them to begin building those tests straight away. The result is early feedback on the feasibility of the designs, and we’ve found priority guides have significantly speeded up the collaborative process of design and development at Mirabeau.

How to create priority guides

There are a number of baselines and steps that we’ve found useful when creating priority guides. We’ve fine-tuned them over the years as we’ve applied this new approach to our projects, and conducted workshops explaining priority guides to the Dutch design community.

The baselines

Your priority guide should only contain real content that’s relevant to the user. Lorem ipsum, or any other type of placeholder text, doesn’t communicate how the page supports users in reaching their goals. Moreover, don’t include any layout elements when making priority guides. Instead, include only content and functionality. Remember that a priority guide is never a deliverable—it’s merely a tool to facilitate discussion among the designers, developers, testers, and stakeholders involved in the project.

Priority guides should always have a mobile format. By constraining yourself this way, you automatically think mobile-first and consider which information is most important (and so should be at the top of the screen). Also, since the menu is typically more or less the same on every screen of your website or app, we recommend leaving the menu out of your priority guide. It’ll help you focus on the screen you’re designing for, and the guide won’t be cluttered with unnecessary distractions.

Step 1: determine the goal(s)

Before jumping to the solution, it’s important to take a step back and consider why you’re making this priority guide. What is the purpose of the page? What goal or goals does the user have? And what goal or goals does the business have? The answers to these questions will both guide your user research and determine which content will add more value to users and the business, and so have higher priority.

Step 2: research and understand the user

There are many methods for user research, and the method or methods chosen will largely depend on the situation and project. However, when creating priority guides, we’ve definitely found it useful to generate personas, affinity diagrams, and experience maps to help create a visual summary of any research findings.

Step 3: determine the content topics

The aim of this stage is to use your knowledge of the user and the business to determine which specific content and topics will best support their goals in each phase of the customer journey. Experience has taught us that co-creating this content outline with users, clients, copywriters, and stakeholders can be highly beneficial. The result is a list of topics that each page should contain.

Step 4: create a high-level priority guide

Use the list of topics to create a high-level priority guide. Which is the most important topic? Place that one on the top. Which is the second most important topic? That one goes below the first. It’s a straightforward prioritization process that should be continued until all the (relevant) topics have found a place in the priority list. It’s important to question the importance of each topic, not only in comparison to other topics, but also whether the topic should really be on the page at all. And we’ve found that starting on paper definitely helps avoid focusing too much on the little visual details, which can happen if using a digital design tool (“pixel-fixing”).

A high-level priority guide for FreeBees, a fictional company Step 5: create a detailed priority guide

Now it’s time to start adding the details. For each topic, determine the detailed, real content that will appear on the page. Also, start thinking about any functionalities the page may need. When you have multiple priority guides for multiple pages, indicate how and where these pages are connected in a sitemap format.

We often use this first schematic shape of the product to identify flows, test if the concept is complete, and determine whether the current content and priorities effectively serve users’ needs and help solve their problems. More than once it has allowed us to identify that a content plan needed to be altered to achieve the outcome we were targeting. And because priority guides are quick and easy to produce, iterating at this stage saved a lot of time and effort.

A detailed priority guide for FreeBees, a fictional company Step 6: user testing and (further) iteration

The last (continuous) step involves testing and iterating your priority guides. Ask users what they think about the information presented in the priority guides (yes, it is possible to do usability testing with priority guides!), and gather feedback from stakeholders. The input gained from these sessions can then be used to validate and reprioritize the information, and to add or adapt functionalities, followed by further testing as needed.

Find out what works for you

Over the years we’ve seen many variations on the process described above. Some designers work entirely with paper and Post-its, while others prefer to create priority guides in a digital design tool from scratch. Some go no further than high-level priority guides, while others use detailed priority guides as a guideline for their entire project.

The key is to experiment, and take the time to find out which approach works best for you and your team. What remains important no matter your process, however, is the need to always keep the focus on user and business goals, and to continuously ask yourself what each piece of content or functionality adds to these goals.

Conclusion

For us here at Mirabeau, priority guides have become a highly efficient tool for designing user-first, content-first, and mobile-first, overcoming many of the significant pitfalls that come from relying only on wireframes. Wireframes do have their uses, and in many situations it’s valuable to be able to visualize ideas and discuss them with team members, clients, or stakeholders. Sketching concepts as wireframes to test ideas can also be useful, and sometimes we’ll even generate wireframes to gain new insights into how to improve our priority guides!

Overall, we’ve found that priority guides are more useful at the start of a project, when in the phase of defining the purpose and content of screens. Wireframes, on the other hand, are more useful for sketching and communicating ideas and visual concepts. Just don’t start with wireframes, and make sure you always stay focused on what’s important.

Categories: thinktime

Pages

Subscribe to kattekrab aggregator