TWW full feed: Recent Episodes
None
Our recent webinar on “See What’s New in MadCap Flare 2018” covered the new features available with the new release, such as the lightweight editor, Elasticsearch, and more. In addition to these major new features, a number of smaller (but …
The post MadCap Flare 2018 Feature Highlight: A Look Into the Find and Replace Enhancements appeared first on MadBlog: The Official Technical Communications Blog for MadCap Software.
We just released version 3.0 of XML Documentation for Adobe Experience Manager, Adobe’s enterprise-class DITA CCMS. See what’s new in this blog post by Product Manager Juhee Garg …
A note from the editors: It’s our pleasure to share this excerpt from Chapter 2 (“Pinning Down Touchpoints”) of Orchestrating Experiences: Collaborative Design for Complexity by Chris Risdon and Patrick Quattlebaum, available now from Rosenfeld Media.
If you embrace the recommended collaborative approaches in your sense-making activities, you and your colleagues should build good momentum toward creating better and valuable end-to-end experiences. In fact, the urge to jump into solution mode will be tempting. Take a deep breath: you have a little more work to do. To ensure that your new insights translate into the right actions, you must collectively define what is good and hold one another accountable for aligning with it.
Good, in this context, means the ideas and solutions that you commit to reflect your customers’ needs and context while achieving organizational objectives. It also means that each touchpoint harmonizes with others as part of an orchestrated system. Defining good, in this way, provides common constraints to reduce arbitrary decisions and nudge everyone in the same direction.
How do you align an organization to work collectively toward the same good? Start with some common guidelines called experience principles.
A Common DNA Experience principles are a set of guidelines that an organization commits to and follows from strategy through delivery to produce mutually beneficial and differentiated customer experiences. Experience principles represent the alignment of brand aspirations and customer needs, and they are derived from understanding your customers. In action, they help teams own their part (e.g., a product, touchpoint, or channel) while supporting consistency and continuity in the end-to-end experience. Figure 6.1 presents an example of a set of experience principles.
Figure 6.1: Example set of experience principles. Courtesy of Adaptive Path
Experience principles are not detailed standards that everyone must obey to the letter. Standards tend to produce a rigid system, which curbs innovation and creativity. In contrast, experience principles inform the many decisions required to define what experiences your product or service should create and how to design for individual, yet connected, moments. They communicate in a few memorable phrases the organizational wisdom for how to meet customers’ needs consistently and effectively. For example, look at the following:
- Paint me a picture.
- Have my back.
- Set my expectations.
- Be one step ahead of me.
- Respect my time.
Experience Principles vs Design Principles
Orchestrating experiences is a team sport. Many roles contribute to defining, designing, and delivering products and services that result in customer experiences. For this reason, the label experience—rather than design—reflects the value of principles better that inform and guide the organization. Experience principles are outcome oriented; design principles are process oriented. Everyone should follow and buy into them, not just designers.
Patrick Quattlebaum
Experience principles are grounded in customer needs, and they keep collaborators focused on the why, what, and how of engaging people through products and services. They keep critical insights and intentions top of mind, such as the following:
- Mental Models: How part of an experience can help people have a better understanding, or how it should conform to their mental model.
- Emotions: How part of an experience should support the customer emotionally, or directly address their motivations.
- Behaviors: How part of an experience should enable someone to do something they set out to do better.
- Target: The characteristics to which an experience should adhere.
- Impact: The outcomes and qualities an experience should engender in the user or customer.
Focusing on Needs to Differentiate
Many universal or heuristic principles exist to guide design work. There are visual design principles, interaction design principles, user experience principles, and any number of domain principles that can help define the best practices you apply in your design process. These are lessons learned over time that have a broader application and can be relied on consistently to inform your work across even disparate projects.It’s important to reinforce that experience principles specific to your customers’ needs provide contextual guidelines for strategy and design decisions. They help everyone focus on what’s appropriate to specific customers with a unique set of needs, and your product or service can differentiate itself by staying true to these principles. Experience principles shouldn’t compete with best practices or universal principles, but they should be honored as critical inputs for ensuring that your organization’s specific value propositions are met.
Chris Risdon
Playing Together Earlier, we compared channels and touchpoints to instruments and notes played by an orchestra, but in the case of experience principles, it’s more like jazz. While each member of a jazz ensemble is given plenty of room to improvise, all players understand the common context in which they are performing and carefully listen and respond to one another (see Figure 6.2). They know the standards of the genre backward and forward, and this knowledge allows them to be creative individually while collectively playing the same tune.
Figure 6.2: Jazz ensembles depend upon a common foundation to inspire improvisation while working together to form a holistic work of art. Photo by Roland Godefroy, License
Experience principles provide structure and guidelines that connect collaborators while giving them room to be innovative. As with a time signature, they ensure alignment. Similar to a melody, they provide a foundation that encourages supportive harmony. Like musical style, experience principles provide boundaries for what fits and what doesn’t.
Experience principles challenge a common issue in organizations: isolated soloists playing their own tune to the detriment of the whole ensemble. While still leaving plenty of room for individual improvisation, they ask a bunch of solo acts to be part of the band. This structure provides a foundation for continuity in the resulting customer journey, but doesn’t overengineer consistency and predictability, which might prevent delight and differentiation. Stressing this balance of designing the whole while distributing effort and ownership is a critical stance to take to engender cross-functional buy-in.
To get broad acceptance of your experience principles, you must help your colleagues and your leadership see their value. You will need to craft value propositions for your different stakeholders, educate the stakeholders on how to use experience principles, and pilot the experience principles to show how they are used in action. This typically requires crafting specific value propositions and education materials for different stakeholders to gain broad support and adoption. Piloting your experience principals on a project can also help others understand their tactical use. When approaching each stakeholder, consider these common values:
- Defining good: While different channels and media have their specific best practices, experience principles provide a common set of criteria that can be applied across an entire end-to-end experience.
- Decision-making filter: Throughout the process of determining what to do strategically and how to do it tactically, experience principles ensure that customers’ needs and desires are represented in the decision-making process.
- Boundary constraints: Because these constraints represent the alignment of brand aspiration and customer desire, experience principles can filter out ideas or solutions that don’t reinforce this alignment.
- Efficiency: Used consistently, experience principles reduce ambiguity and the resultant churn when determining what concepts should move forward and how to design them well.
- Creativity inspiration: Experience principles are very effective in sparking new ideas with greater confidence that will map back to customer needs. (See Chapter 8, “Generating and Evaluating Ideas.”)
- Quality control: Through the execution lifecycle, experience principles can be used to critique touchpoint designs (i.e., the parts) to ensure that they align to the greater experience (i.e., the whole).
Pitching and educating aside, your best bet for creating good experience principles that get adopted is to avoid creating them in a black box. You don’t want to spring your experience principles on your colleagues as if they were commandments from above to follow blindly. Instead, work together to craft a set of principles that everyone can follow energetically.
Identifying Draft Principles Your research into the lives and journeys of customers will produce a large number of insights. These insights are reflective. They capture people’s current experiences—such as, their met and unmet needs, how they frame the world, and their desired outcomes. To craft useful and appropriate experience principles, you must turn these insights inside out to project what future experiences should be.
When You Can’t Do Research (Yet)
If you lack strong customer insights (and the support or time to gather them), it’s still valuable to craft experience principles with your colleagues. The process of creating them provides insight into the various criteria that people are using to make decisions. It also sheds light on what your collaborators believe are the most important customer needs to meet. While not as sound as research-driven principles, your team can align around a set of guidelines to inform and critique your collective work—and then build the case for gathering insights for creating better experience principles.
Patrick Quattlebaum
From the Bottom Up The leap from insights to experience principles will take several iterations. While you may be able to rattle off a few candidates based on your research, it’s well worth the time to follow a more rigorous approach in which you work from the bottom (individual insights) to the top (a handful of well-crafted principles). Here’s how to get started:
- Reassemble your facilitators and experience mappers, as they are closest to what you learned in your research.
- Go back to the key insights that emerged from your discovery and research. These likely have been packaged in maps, models, research reports, or other artifacts. You can also go back to your raw data if needed.
- Write each key insight on a sticky note. These will be used to spark a first pass at potential principles.
- For each insight, have everyone take a pass individually at articulating a principle derived from just that insight. You can use sticky notes again or a quarter sheet of 8.5”’’x 11”’ (A6) template to give people a little more structure (see Figure 6.3).
Figure 6.3: A simple template to generate insight-level principles quickly.
- At this stage, you should coach participants to avoid finding the perfect words or a pithy way to communicate a potential principle. Instead, focus on getting the core lesson learned from the insight and what advice you would give others to guide product or service decisions in the future. Table 6.1 shows a couple of examples of what a good first pass looks like.
- At this stage, don’t be a wordsmith. Work quickly to reframe your insights from something you know (“Most people don’t want to…”) to what should be done to stay true to this insight (“Make it easy for people…”).
- Work your way through all the insights until everyone has a principle for each one.
Table 6.1: From insights to draft principles| Insight | Principle | | --- | --- | | Most people don’t want to do their homework first. They want to get started and learn what they need to know when they need to know it. | Make it easy for people to dive in and collect knowledge when it’s most relevant. | | Everyone believes their situation (financial, home, health) is unique and reflects their specific circumstances, even if it’s not true. | Approach people as they see themselves: unique people in unique situations. |
Finding Patterns You now have a superset of individual principles from which a handful of experience principles will emerge. Your next step is to find the patterns within them. You can use affinity mapping to identify principles that speak to a similar theme or intent. As with any clustering activity, this may take a few iterations until you feel that you have mutually exclusive categories. You can do this in just a few steps:
- Select someone to be a workshop participant to present the principles one by one, explaining the intent behind each one.
- Cycle through the rest of the group, combining like principles and noting where principles conflict with one another. As you cluster, the dialogue the group has is as important as where the principles end up.
- Once things settle down, you and your colleagues can take a first pass at articulating a principle for each cluster. A simple half sheet (8.5” x 4.25” or A5) template can give some structure to this step. Again, don’t get too precious with every word yet. (see Figure 6.4). Get the essence down so that you and others can understand and further refine it with the other principles.
- You should end up with several mutually exclusive categories with a draft principle for each.
Designing Principles as a System No experience principle is an island. Each should be understandable and useful on its own, but together your principles should form a system. Your principles should be complementary and reinforcing. They should be able to be applied across channels and throughout your product or service development process. See the following “Experience Principles Refinement Workshop” for tips on how to critique your principles to ensure that they work together as a complete whole.
I needed to include some Mac commands in a PowerPoint presentation, but couldn’t easily find how to create the loopy Command symbol (⌘). Google to the rescue! The symbol is U+2318 (Unicode) or these characters (but with NO spaces) & # 8984; (HTML), or, if you’re typing in Word using a full keyboard, hold down the […]
I joined a small group at this Content Strategy meetup and introduced myself as a tech writer. This surprised everyone. Weird. I shrugged it off, but then it happened again with another group… and again. What’s going on here? Maybe we don’t have that much in common?
Gretyl Kinsey: Welcome to the Content Strategy Experts podcast, brought to you by Scriptorium. Since 1997, Scriptorium has helped companies manage, structure, organize and distribute content in an efficient way. In Episode 29, we continue our occasional series on content strategy pitfalls. Our focus today ... Read More
The post Full transcript of Content strategy pitfalls podcast: change management appeared first on Scriptorium.
When you start working with truly large amounts of content, it’s nearly impossible to enforce standards, style guides, and content models. The answer to this problem is XML-based, structured content. Structured authoring also helps with things like content management, localization (translation), accessibility, searchability, and is even a requirement in the aerospace, defense, and other industries. Get an introduction to working with XML, DITA and S1000D in FrameMaker 2017 in this guest blog post by Matt Sullivan.
The next installment in an occasional series on how to avoid pitfalls in your content strategy. In this podcast, Gretyl Kinsey and Bill Swallow discuss common change management problems and how to make sure your content strategy accounts for them. Related links: Content strategy versus human ... Read More
The post Content strategy pitfalls podcast: change management appeared first on Scriptorium.
‘Tis a gift to be simple. Increasingly, in our line of work, ‘tis a rare gift indeed.
In an industry that extols innovation over customer satisfaction, and prefers algorithm to human judgement (forgetting that every algorithm has human bias in its DNA), perhaps it should not surprise us that toolchains have replaced know-how.
Likewise, in a field where young straight white dudes take an overwhelming majority of the jobs (including most of the management jobs) it’s perhaps to be expected that web making has lately become something of a dick measuring competition.
It was not always this way, and it needn’t stay this way. If we wish to get back to the business of quietly improving people’s lives, one thoughtful interaction at a time, we must rid ourselves of the cult of the complex. Admitting the problem is the first step in solving it.
And the div cries Mary In 2001, more and more of us began using CSS to replace the non-semantic HTML table layouts with which we’d designed the web’s earliest sites. I soon noticed something about many of our new CSS-built sites. I especially noticed it in sites built by the era’s expert backend coders, many of whom viewed HTML and CSS as baby languages for non-developers.
In those days, whether from contempt for the deliberate, intentional (designed) limitations of HTML and CSS, or ignorance of the HTML and CSS framers’ intentions, many code jockeys who switched from table layouts to CSS wrote markup consisting chiefly of divs and spans. Where they meant list item, they wrote span. Where they meant paragraph, they wrote div. Where they meant level two headline, they wrote div or span with a classname of h2, or, avoiding even that tragicomic gesture toward document structure, wrote a div or span with verbose inline styling. Said div was followed by another, and another. They bred like locusts, stripping our content of structural meaning.
As an early adopter and promoter of CSS via my work in The Web Standards Project (kids, ask your parents), I rejoiced to see our people using the new language. But as a designer who understood, at least on a basic level, how HTML and CSS were supposed to work together, I chafed.
Cry, the beloved font tag Everyone who wrote the kind of code I just described thought they were advancing the web merely by walking away from table layouts. They had good intentions, but their executions were flawed. My colleagues and I here at A List Apart were thus compelled to explain a few things.
Mainly, we argued that HTML consisting mostly of divs and spans and classnames was in no way better than table layouts for content discovery, accessibility, portability, reusability, or the web’s future. If you wanted to build for people and the long term, we said, then simple, structural, semantic HTML was best—each element deployed for its intended purpose. Don’t use a div when you mean a p.
This basic idea, and I use the adjective advisedly, along with other equally rudimentary and self-evident concepts, formed the basis of my 2003 book Designing With Web Standards, which the industry treated as a revelation, when it was merely common sense.
The message messes up the medium When we divorce ideas from the conditions under which they arise, the result is dogma and misinformation—two things the internet is great at amplifying. Somehow, over the years, in front-end design conversations, the premise “don’t use a div when you mean a p” got corrupted into “divs are bad.”
A backlash in defense of divs followed this meaningless running-down of them—as if the W3C had created the div as a forbidden fruit. So, let’s be clear. No HTML element is bad. No HTML element is good. A screwdriver is neither good nor bad, unless you try to use it as a hammer. Good usage is all about appropriateness.
Divs are not bad. If no HTML5 element is better suited to an element’s purpose, divs are the best and most appropriate choice. Common sense, right? And yet.
Somehow, the two preceding simple sentences are never the takeaway from these discussions. Somehow, over the years, a vigorous defense of divs led to a defiant (or ignorant) overuse of them. In some strange way, stepping back from a meaningless rejection of divs opened the door to gaseous frameworks that abuse them.
Note: We don’t mind so much about the abuse of divs. After all, they are not living things. We are not purists. It’s the people who use the stuff we design who suffer from our uninformed or lazy over-reliance on these div-ridden gassy tools. And that suffering is what we protest. div-ridden, overbuilt frameworks stuffed with mystery meat offer the developer tremendous power, agility. But that power comes at a price your users pay: a hundred tons of stuff your project likely doesn’t need, but you force your users to download anyway. And that bloat is not the only problem. For who knows what evil lurks in someone else’s code?
Two cheers for frameworks If you entered web design and development in the past ten years, you’ve likely learned and may rely on frameworks. Most of these are built on meaningless arrays of divs and spans—structures no better than the bad HTML we wrote in 1995, however more advanced the resulting pages may appear. And what keeps the whole monkey-works going? JavaScript, and more JavaScript. Without it, your content may not render. With it, you may deliver more services than you intended to.
There’s nothing wrong with using frameworks to quickly whip up and test product prototypes, especially if you do that testing in a non-public space. And theoretically, if you know what you’re doing, and are willing to edit out the bits your product doesn’t need, there’s nothing wrong with using a framework to launch a public site. Notice the operative phrases: if you know what you’re doing, and are willing to edit out the bits your product doesn’t need.
Alas, many new designers and developers (and even many experienced ones) feel like they can’t launch a new project without dragging in packages from NPM, or Composer, or whatever, with no sure idea what the code therein is doing. The results can be dangerous. Yet here we are, training an entire generation of developers to build and launch projects with untrusted code.
Indeed, many designers and developers I speak with would rather dance naked in public than admit to posting a site built with hand-coded, progressively enhanced HTML, CSS, and JavaScript they understand and wrote themselves. For them, it’s a matter of job security and viability. There’s almost a fear that if you haven’t mastered a dozen new frameworks and tools each year (and by mastered, I mean used), you’re slipping behind into irrelevancy. HR folks who write job descriptions listing the ten thousand tool sets you’re supposed to know backwards and forwards to qualify for a junior front-end position don’t help the situation.
CSS is not broken, and it’s not too hard As our jerrybuilt contraptions, lashed together with fifteen layers of code we don’t understand and didn’t write ourselves, start to buckle and hiss, we blame HTML and CSS for the faults of developers. This fault-finding gives rise to ever more complex cults of specialized CSS, with internecine sniping between cults serving as part of their charm. New sects spring up, declaring CSS is broken, only to splinter as members disagree about precisely which way it’s broken, or which external technology not intended to control layout should be used to “fix” CSS. (Hint: They mostly choose JavaScript.)
Folks, CSS is not broken, and it’s not too hard. (You know what’s hard? Chasing the ever-receding taillights of the next shiny thing.) But don’t take my word for it. Check these out:
- Getting Started with CSS Layout—Rachel Andrew, Smashing Magazine
- Learn CSS Grid—Jen Simmons
- CSS Grid Layout—MDN web docs
- Grid by Example—Rachel Andrew
- A Complete Guide to Grid—Chris House, CSS-Tricks
- Practical CSS Grid: Adding Grid to an Existing Design—Eric Meyer, A List Apart
- Jen Simmons Labs
- Layout Land—YouTube
- A Book Apart: The New CSS Layout, by Rachel Andrew
- The Story of CSS Grid, from its Creators—Aaron Gustafson, A List Apart
- Transcript: Intrinsic Web Design with Jen Simmons (The Big Web Show)
CSS Grid is here; it’s logical and fairly easy to learn. You can use it to accomplish all kinds of layouts that used to require JavaScript and frameworks, plus new kinds of layout nobody’s even tried yet. That kind of power requires some learning, but it’s good learning, the kind that stimulates creativity, and its power comes at no sacrifice of semantics, or performance, or accessibility. Which makes it web technology worth mastering.
The same cannot be said for our deluge of frameworks and alternative, JavaScript-based platforms. As a designer who used to love creating web experiences in code, I am baffled and numbed by the growing preference for complexity over simplicity. Complexity is good for convincing people they could not possibly do your job. Simplicity is good for everything else.
Keep it simple, smarty Good communication strives for clarity. Design is its most brilliant when it appears most obvious—most simple. The question for web designers should never be how complex can we make it. But that’s what it has become. Just as, in pursuit of “delight,” we forget the true joy reliable, invisible interfaces can bring, so too, in chasing job security, do we pile on the platform requirements, forgetting that design is about solving business and customer problems … and that baseline skills never go out of fashion. As ALA’s Brandon Gregory, writing elsewhere, explains:
I talk with a lot of developers who list Angular, Ember, React, or other fancy JavaScript libraries among their technical skills. That’s great, but can you turn that mess of functions the junior developer wrote into a custom extensible object that we can use on other projects, even if we don’t have the extra room for hefty libraries? Can you code an image slider with vanilla JavaScript so we don’t have to add jQuery to an older website just for one piece of functionality? Can you tell me what recursion is and give me a real-world example?
“I interview web developers. Here’s how to impress me.”
Growing pains There’s a lot of complexity to good design. Technical complexity. UX complexity. Challenges of content and microcopy. Performance challenges. This has never been and never will be an easy job.
Simplicity is not easy—not for us, anyway. Simplicity means doing the hard work that makes experiences appear seamless—the sweat and torture-testing and failure that eventually, with enough effort, yields experiences that seem to “just work.”
Nor, in lamenting our industry’s turn away from basic principles and resilient technologies, am I suggesting that CDNs and Git are useless. Or wishing that we could go back to FTP—although I did enjoy the early days of web design, when one designer could do it all. I’m glad I got to experience those simpler times.
But I like these times just fine. And I think you do, too. Our medium is growing up, and it remains our great privilege to help shape its future while creating great experiences for our users. Let us never forget how lucky we are, nor, in chasing the ever-shinier, lose sight of the people and purpose we serve.
I have a new article in my series on Simplifying Complexity. This article talks about why reconstructing the absent users is essential to creating good documentation.
The title “Heroic Technical Writing” and a picture of a true hero, Superman from the iconic 1978 movie, and a strong variety of writing-related topics combine to appeal to the inner geek in all of us, in Bart Leahy's blog.
At last week’s STC Summit, I attended a couple of presentations that probed the same question. It’s an old question, but it’s still a thorny one. How can we integrate content into a unified presentation when the content comes from all over the place? When different teams — communication specialists and nonspecialists — are creating […]
I’ve been working at Scriptorium for almost four years, but last week was my first opportunity to attend a conference. I spent a good amount of time on the exhibit hall floor, but I was also able to attend presentation sessions. On the exhibit floor ... Read More
The post Conference recap: STC Summit 2018 appeared first on Scriptorium.
Online user guides and manuals are absolutely convenient for users because they can be accessed easily and almost anywhere. As such, online user guides and manuals must be written appropriately to make them effective and user-friendly.
Unlike the print user guides and manuals, online manuals are often accessed via mobile devices such as smartphones and tablets. Although they aren’t restricted to such devices: learn more about the best formats to publish your help files.
So what should you consider when writing online user guides and manuals? Let’s get back to the basics.
Tags: HTMLHelp Authoring ToolsDocumentation FormatsTips & Tricks
In this post, Daniel Ferguson shares his journey as a technical writer and how MadCap Flare played a central role in getting him where he is today. This article was originally published in ISTC Communicator, Spring 2018 and the Smart …
The post How MadCap Flare Reignited My Technical Writing Career appeared first on MadBlog: The Official Technical Communications Blog for MadCap Software.
Author and storyteller Carla Johnson, in her keynote speech at this week’s STC Summit, described how inspiration comes, not as a bolt from the blue, but from observing other people’s creative work. She warned against brand detachment disorder, in which we see another brand — maybe Disney or Apple — doing something cool but immediately dismiss […]
At Adobe, we continuously strive to give our customers the best experience. For this, we would love to hear your feedback and understand how we can improve our products and services to serve you better going forward. We are pleased to announce the launch of Adobe Tech Comm Customer Experience Survey 2018. Have your “SAY” […]
What would you say if I told you I just read and analyzed over 350 articles from A List Apart in less than six weeks? “You’re crazy!” might have passed through your lips. In that case, what would you say if I was doing it for a grade? Well, you might say that makes sense.
As a part of an Independent Research Study for my undergraduate degree, I wanted to fill in some of the gaps I had when it came to working with the World Wide Web. I wanted to know more about user experience and user interface design, however, I needed the most help getting to know the industry in general. Naturally, my professor directed me to A List Apart.
At first I wasn’t sure what I was going to get out of the assignment other than the credit I needed to graduate. What could one website really tell me? As I read article after article, I realized that I wasn’t just looking at a website—I was looking at a community. A community with history in which people have struggled to build the right way. One that is constantly working to be open to all. One that is always learning, always evolving, and sometimes hard to keep up with. A community that, without my realizing it, I had become a part of. For me, the web has pretty much always been there, but now that I am better acquainted with its past, I am energized to be a part of its future. Take a look at some of the articles that inspired this change in me.
A bit of history I started in the Business section and went back as far as November 1999. What a whirlwind that was! I had no idea what people went through and the battles that they fought to make the web what it is today. Now, I don’t mean to date any of you lovely readers, but I would have been three years old when the first business article on A List Apart was published, so everything I read until about 2010 was news to me.
For instance, when I came across Jeffrey Zeldman’s “Survivor! (How Your Peers Are Coping with the Dotcom Crisis)” that was published in 2001, I had no idea what he was talking about! The literal note I wrote for that article was: “Some sh** went down in the late 1990s???” I was in the dark until I had the chance to Google it and sheepishly ask my parents.
I had the same problem with the term Web 2.0. It wasn’t until I looked it up that I realized I didn’t know what it was, because I never experienced Web 1.0 (having not had access to the internet until 2004). In that short time, the industry had completely reinvented itself before I ever had a chance to log on!
The other bit of history that surprised me was how long and hard people had to fight to get web standards and accessibility in line. In school I’ve always been taught to make my sites accessible, and that just seemed like common sense to me. I guess I now understand why I have mixed feelings about Flash.
What I learned about accessibility Accessibility is one of the topics I took a lot of notes on. I was glad to see that although a lot of progress had been made in this area, people were still taking the time to write about and constantly make improvements to it. In Beth Raduenzel’s “A DIY Web Accessibility Blueprint,” she explains the fundamentals to remember when designing for accessibility, including considering:
- keyboard users;
- blind users;
- color-blind users;
- low-vision users;
- deaf and hard-of-hearing users;
- users with learning disabilities and cognitive limitations;
- mobility-impaired users;
- users with speech disabilities;
- and users with seizure disorders.
It was nice to have someone clearly spell it out. However, the term “user” was used a lot. This distances us from the people we are supposed to be designing for. Anne Gibson feels the same way; in her article, she states that “[web] accessibility means that people can use the web.” All people. In “My Accessibility Journey: What I’ve Learned So Far,” Manuel Matuzović gives exact examples of this:
- If your site takes ten seconds to load on a mobile connection, it’s not accessible.
- If your site is only optimized for one browser, it’s not accessible.
- If the content on your site is difficult to understand, your site isn’t accessible.
It goes beyond just people with disabilities (although they are certainly not to be discounted).
I learned a lot of tips for designing with specific people in mind. Like including WAI-ARIA in my code to benefit visually-impaired users, and checking the color contrast of my site for people with color blindness and low-vision problems. One article even inspired me to download a Sketch plugin to easily check the contrast of my designs in the future. I’m more than willing to do what I can to allow my website to be accessible to all, but I also understand that it’s not an easy feat, and I will never get it totally right.
User research and testing methods that were new to me Nevertheless, we still keep learning. Another topic on A List Apart I desperately wanted to absorb was the countless research, testing, and development methods I came across in my readings. Every time I turn around, someone else has come up with another way of working, and I’m always trying to keep my finger in the pie.
I’m happy to report that the majority of the methods I read about I already knew about and have used in my own projects at school. I’ve been doing open interview techniques, personas, style tiles, and element collages all along, but I was surprised by how many new practices I’d come across.
The Kano Model, the Core Model, Wizard of Oz prototyping, and think-alouds were some of the methods that piqued my curiosity. Others like brand architecture research, call center log analysis, clickstream analysis, search analytics, and stakeholder reviews I’ve heard of before, but have never been given the opportunity to try.
Unattended qualitative research, A/B testing and fake-door testing are those that stood out to me. I liked that they allow you to conduct research even if you don’t have any users in front of you. I learned a lot of new terms and did a lot of research in this section. After all, it’s easy to get lost in all the jargon.
The endless amount of abbreviations I spent a lot of my time Googling terms during this project—especially with the older articles that mentioned programs like Fireworks that aren’t really used anymore. One of my greatest fears in working with web design is that someone will ask me something and I will have no idea what they are talking about. When I was reading all the articles, I had the hardest time with the substantial amount of abbreviations I came across: AJAX, API, ARIA, ASCII, B2B, B2C, CMS, CRM, CSS, EE, GUI, HTML, IIS, IPO, JSP, MSA, RFP, ROI, RSS, SASS, SEM, SEO, SGML, SOS, SOW, SVN, and WYSIWYG, just to name a few. Did you manage to get them all? Probably not.
We don’t use abbreviations in school because they aren’t always clear and the professors know we won’t know what they mean. To a newbie like me, these abbreviations feel like a barrier. A wall that divides the veterans of the industry and those trying to enter it. I can’t imagine how the clients must feel.
It seems as if I am not alone in my frustrations. Inayaili de León says in her article “Becoming Better Communicators,” “We want people to care about design as much as we do, but how can they if we speak to them in a foreign language?” I’m training to be a designer, I’m in Design, and I had to look up almost every abbreviation listed above.
What I learned about myself Prior to taking on this assignment, I would have been very hesitant to declare myself capable of creating digital design. To my surprise, I’m not alone. Matt Griffin thinks, “… the constant change and adjustments that come with living on the internet can feel overwhelming.” Kendra Skeene admits, “It’s a lot to keep track of, whether you’ve been working on the web for [twenty] years or only [twenty] months.”
My fear of not knowing all the fancy lingo was lessened when I read Lyza Danger Gardner’s “Never Heard of It.” She is a seasoned professional who admits to not knowing it all, so I, a soon-to-be-grad, can too. I have good foundations and Google on my side for those pesky abbreviations that keep popping up. As long as I just remember to use my brain as Dave Rupert suggests, when I go to get a job I should do just fine.
Entering the workplace Before starting this assignment, I knew I wanted to work in digital and interaction design, but I didn’t know where. I was worried I didn’t know enough about the web to be able to design for it—that all the jobs out there would require me to know coding languages I’d never heard of before, and I’d have a hard time standing out among the crowd.
The articles I read on A List Apart supplied me with plenty of solid career advice. After reading articles written by designers, project managers, developers, marketers, writers, and more, I’ve come out with a better understanding of what kind of work I want to do. In the article “80/20 Practitioners Make Better Communicators,” Katie Kovalcin makes a good point about not forcing yourself to learn skills just because you feel the need to:
We’ve all heard the argument that designers need to code. And while that might be ideal in some cases, the point is to expand your personal spectrum of skills to be more useful to your team, whether that manifests itself in the form of design, content strategy, UX, or even project management. A strong team foundation begins by addressing gaps that need to be filled and the places where people can meet in the middle.
I already have skills that someone desperately needs. I just need to find the right fit and expand my skills from there. Brandon Gregory also feels that hiring isn’t all about technical knowledge. In his article, he says, “personality, fit with the team, communication skills, openness to change, [and] leadership potential” are just as important.
Along with solid technical fundamentals and good soft skills, it seems as if having a voice is also crucial. When I read Jeffrey Zeldman’s article “The Love You Make,” it became clear to me that if I ever wanted to get anywhere with my career, I was going to have to start writing.
Standout articles The writers on A List Apart have opened my eyes to many new subjects and perspectives on web design. I particularly enjoyed looking through the game design lens in Graham Herrli’s “Gaming the System … and Winning.” It was one of the few articles where I copied his diagram on interaction personality types and their goals into my notebook. Another article that made me consider a new perspective was “The King vs. Pawn Game of UI Design” by Erik Kennedy. To start with one simple element and grow from there really made something click in my head.
However, I think that the interview I read between Mica McPheeters and Sara Wachter-Boettcher stuck with me the most. I actually caught myself saying “hmm” out loud as I was reading along. Sara’s point about crash-test dummies being sized to the average male completely shifted my understanding about how important user-centered design is. Like, life-or-death important. There is no excuse not to test your products or services on a variety of users if this is what’s at stake! It’s an article I’m glad I read.
Problems I’ve noticed in the industry During the course of my project, I noticed some things about A List Apart that I was spending so much time on. Like, for example, it wasn’t until I got to the articles that were published after 2014 that I really started to understand and relate to the content; funnily enough, that was the year I started my design degree.
I also noticed that it was around this time that female writers became much more prominent on the site. Today there may be many women on A List Apart, but I must point out a lack of women of color. Shoutout to Aimee Gonzalez-Cameron for her article “Hello, My Name is
Despite the lack of representation of women of color, I was very happy to see many writers acknowledge their privilege in the industry. Thanks to Cennydd Bowles, Matt Griffin, and Rian van der Merwe for their articles. My only qualm is that the topic of privilege has only appeared on A List Apart in the last five years. Because isn’t it kinda ironic? As creators of the web we aim to allow everyone access to our content, but not everyone has access to the industry itself. Sara Wachter-Boettcher wrote an interesting article that expands on this idea, which you should read if you haven’t already. However, I won’t hold it against any of you. That’s why we are here anyway: to learn.
The takeaway Looking back at this assignment, I’m happy to say that I did it. It was worth every second (even with the possible eye damage from reading off my computer screen for hours on end). It was worth it because I learned more than I had ever anticipated. I received an unexpected history lesson of the recent internet past. I was bombarded by an explosion of new terms and abbreviations. I learned a lot about myself and how I can possibly fit into this community. Most importantly, I came out on the other end with more confidence in myself and my abilities—which is probably the greatest graduation gift I could receive from a final project in my last year of university. Thanks for reading, and wish me luck!
Thanks Thanks to my Interactive Design professor Michael LeBlanc for giving me this assignment and pushing me to take it further.
I’m writing live this week from the STC Summit. Are you here too? If so, are you finding the experience worthwhile? Take a moment to answer the following question. Then use the Comments section to tell me why you answered as you did. (Your vote is anonymous; your comments are not.) If you’ve been to […]
I know how this happens, I do. A tech writer is given a task to "document the product," and it turns out there isn't much to say. But telling the bosses that nope, it's ok, we don't actually need to say anything about this might be perceived as, dunno, not being cooperative. Maybe even suggesting that the writer's job isn't that important.
Anyway, today we have a couple of examples of what might result if the writer (and common sense) does not prevail. First up, we have these, um, helpful instructions that came with a compass that I own:
There must be a universe in which people buy compasses who don't already know what N, E, S, and W mean. I don't believe we live in that universe.
But even that is reasonable compared to the following, which Twitter user Alex Warren posted today:
Better keep this for future reference in case I forget what each button does pic.twitter.com/UO795hO3Xn
— Alex Warren (@alexwarren) May 22, 2018
More dubious guidance: 1, 2, 3, 4, 5, 6, 7, 8, 9
Implementing a content strategy is tricky. Technical issues bubble up to the surface as challenges, but those issues usually have direct solutions. The real elephant in the room isn’t technology; it’s human nature. Human nature can thwart a content strategy implementation. To succeed, you will ... Read More
The post Content strategy versus human nature appeared first on Scriptorium.
When should we use one word, when should we use two, for terms like “log in”, “sign up”, “back up”, and the like? This is a hot topic among technical writers, UX writers, and any designers who use text in their products. The question is particularly relevant in the software industry, but it affects other […]
The MadWorld 2018 conference is approaching fast. With three full days of learning, four evening networking events, miles of coastline and an endless list of fun things to see and do in America’s Finest City — planning your days, and …
The post Conference Prep: Your Insider Guide to Attending MadWorld 2018 appeared first on MadBlog: The Official Technical Communications Blog for MadCap Software.
Alan Pringle: Welcome to the Content Strategy Experts podcast brought to you by Scriptorium. Since 1997, Scriptorium has helped companies manage, structure, organize and distribute content in an efficient way. AP: In episode 28 we discuss our approach to content strategy, which draws heavily on ... Read More
The post Full transcript of Content strategy and management consulting podcast appeared first on Scriptorium.
What If? “Yes, and…?” is the hallmark of improv comedy. It’s also key to our growth as leaders. What if we said, “Yes, and…?” when approached about taking a leadership role in an organization? For many of us, our first reaction to leadership requests are, “No, because…,” or perhaps, “There’s no way I can do
The post Saying, “Yes, and…?” to Leadership Opportunities appeared first on BenWoelk.com.
In just three short weeks, industry professionals in technical communication and content strategy will gather in sunny San Diego for the annual MadWorld conference. The premier conference is the setting for the largest gathering of MadCap Flare users, creating an …
The post MadWorld 2018 Speaker Spotlight: Patrick Calnan on Accessibility in Documentation appeared first on MadBlog: The Official Technical Communications Blog for MadCap Software.
At next week’s STC Summit I’ll present They’re Coming! Combining Teams and Cultures. If you’re coming to the Summit, I hope to see you in my session on Tuesday, May 22, at 4:00. M&A: it’s everywhere If you work for a company in almost any field, chances are good that you recently went through a […]
My first full-time developer job was at a small company. We didn’t have BrowserStack, so we cobbled together a makeshift device lab. Viewing a site I’d been making on a busted first-generation iPad with an outdated version of Safari, I saw a distorted, failed mess. It brought home to me a quote from Douglas Crockford, who once deemed the web “the most hostile software engineering environment imaginable.”
The “works best with Chrome” problem Because of this difficulty, a problem has emerged. Earlier this year, a widely shared article in the Verge warned of “works best with Chrome” messages seen around the web.
Hi Larry, we apologize for the frustration. Groupon is optimized to be used on a Google Chrome browser, and while you are definitely able to use Firefox or another browser if you'd like, there can be delays when Groupon is not used through Google Chrome.
— Groupon Help U.S. (@GrouponHelpUS) November 26, 2017
Hi Rustram. We'd always recommend that you use Google Chrome to browse the site: we've optimised things for this browser. Thanks.
— Airbnb Help (@AirbnbHelp) July 12, 2016
There are more examples of this problem. In the popular messaging app Slack, voice calls work only in Chrome. In response to help requests, Slack explains its decision like this: “It requires significant effort for us to build out support and triage issues on each browser, so we’re focused on providing a great experience in Chrome.” (Emphasis mine.) Google itself has repeatedly built sites—including Google Meet, Allo, YouTube TV, Google Earth, and YouTube Studio—that block alternative browsers entirely. This is clearly a bad practice, but highlights the fact that cross-browser compatibility can be difficult and time-consuming.
The significant feature gap, though, isn’t between Chrome and everything else. Of far more significance is the increasingly gaping chasm between Internet Explorer and every other major browser. Should our development practices be hamstrung by the past? Or should we dash into the future relinquishing some users in our wake? I’ll argue for a middle ground. We can make life easier for ourselves without breaking the backward compatibility of the web.
The widening gulf Chrome, Opera, and Firefox ship new features constantly. Edge and Safari eventually catch up. Internet Explorer, meanwhile, has been all but abandoned by Microsoft, which is attempting to push Windows users toward Edge. IE receives nothing but security updates. It’s a frustrating period for client-side developers. We read about new features but are often unable to use them—due to a single browser with a diminishing market share.
Internet Explorer’s global market share since 2013 is shown in dark blue. It now stands at just 3 percent.
Some new features are utterly trivial (caret-color!); some are for particular use cases you may never have (WebGL 2.0, Web MIDI, Web Bluetooth). Others already feel near-essential for even the simplest sites (object-fit, Grid).
A list of features supported in Chrome but unavailable in IE11, taken from caniuse.com. This is a truncated and incomplete screenshot of an extraordinarily long list.
The promise and reality of progressive enhancement
For content-driven sites, the question of browser support should never be answered with a simple yes or no. CSS and HTML were designed to be fault-tolerant. If a particular browser doesn’t support shape-outside or service workers or font-display, you can still use those features. Your website will not implode. It’ll just lack that extra stylistic flourish or performance optimization in non-supporting browsers.
Other features, such as CSS Grid, require a bit more work. Your page layout is less enhancement than necessity, and Grid has finally brought a real layout system to the web. When used with care for simple cases, Grid can gracefully fall back to older layout techniques. We could, for example, fall back to flex-wrap. Flexbox is by now a taken-for-granted feature among developers, yet even that is riddled with bugs in IE11.
``` .grid > * { width: 270px; / no grid fallback style / margin-right: 30px; / no grid fallback style / }
@supports (display: grid) { .grid > * { width: auto; margin-right: 0; } } ```
In the code above, I’m setting all the immediate children of the grid to have a specified width and a margin. For browsers that support Grid, I’ll use grid-gap in place of margin and define the width of the items with the grid-template-columns property. It’s not difficult, but it adds bloat and complexity if it’s repeated throughout a codebase for different layouts. As we start building entire page layouts with Grid (and eventually display: contents), providing a fallback for IE will become increasingly arduous. By using @supports for complex layout tasks, we’re effectively solving the same problem twice—using two different methods to create a similar result.
Not every feature can be used as an enhancement. Some things are imperative. People have been getting excited about CSS custom properties since 2013, but they’re still not widely used, and you can guess why: Internet Explorer doesn’t support them. Or take Shadow DOM. People have been doing conference talks about it for more than five years. It’s finally set to land in Firefox and Edge this year, and lands in Internet Explorer … at no time in the future. You can’t patch support with transpilers or polyfills or prefixes.
Users have more browsers than ever to choose from, yet IE manages to single-handedly tie us to the pre-evergreen past of the web. If developing Chrome-only websites represents one extreme of bad development practice, shackling yourself to a vestigial, obsolete, zombie browser surely represents the other.
The problem with shoehorning
Rather than eschew modern JavaScript features, polyfilling and transpiling have become the norm. ES6 is supported everywhere other than IE, yet we’re sending all browsers transpiled versions of our code. Transpilation isn’t great for performance. A single five-line async function, for example, may well transpile to twenty-five lines of code.
“I feel some guilt about the current state of affairs,” Alex Russell said of his previous role leading development of Traceur, a transpiler that predated Babel. “I see so many traces where the combination of Babel transpilation overhead and poor [webpack] foo totally sink the performance of a site. … I’m sad that we’re still playing this game.”
What you can’t transpile, you can often polyfill. Polyfill.io has become massively popular. Chrome gets sent a blank file. Ancient versions of IE receive a giant mountain of polyfills. We are sending the largest payload to those the least equipped to deal with it—people stuck on slow, old machines.
What is to be done?Prioritize content Cutting the mustard is a technique popularized by the front-end team at BBC News. The approach cuts the browser market in two: all browsers receive a base experience or core content. JavaScript is conditionally loaded only by the more capable browsers. Back in 2012, their dividing line was this:
if ('querySelector' in document && 'localStorage' in window && 'addEventListener' in window) {
// load the javascript
}
Tom Maslen, then a lead developer at the BBC, explained the rationale: “Over the last few years I feel that our industry has gotten lazy because of the crazy download speeds that broadband has given us. Everyone stopped worrying about how large their web pages were and added a ton of JS libraries, CSS files, and massive images into the DOM. This has continued on to mobile platforms that don’t always have broadband speeds or hardware capacity to render complex code.”
The Guardian, meanwhile, entirely omits both JavaScript and stylesheets from Internet Explorer 8 and further back.
The Guardian navigation as seen in Internet Explorer 8. Unsophisticated yet functional.
Nature.com takes a similar approach, delivering only a very limited stylesheet to anything older than IE10.
The nature.com homepage as seen in Internet Explorer 9.
Were you to break into a museum, steal an ancient computer, and open Netscape Navigator, you could still happily view these websites. A user comes to your site for the content. They didn’t come to see a pretty gradient or a nicely rounded border-radius. They certainly didn’t come for the potentially nauseating parallax scroll animation.
Anyone who’s been developing for the web for any amount of time will have come across a browser bug. You check your new feature in every major browser and it works perfectly—except in one. Memorizing support info from caniuse.com and using progressive enhancement is no guarantee that every feature of your site will work as expected.
The W3C’s website for the CSS Working Group as viewed in the latest version of Safari.
Regardless of how perfectly formed and well-written your code, sometimes things break through no fault of your own, even in modern browsers. If you’re not actively testing your site, bugs are more likely to reach your users, unbeknownst to you. Rather than transpiling and polyfilling and hoping for the best, we can deliver what the person came for, in the most resilient, performant, and robust form possible: unadulterated HTML. No company has the resources to actively test their site on every old version of every browser. Malfunctioning JavaScript can ruin a web experience and make a simple page unusable. Rather than leaving users to a mass of polyfills and potential JavaScript errors, we give them a basic but functional experience.
Make a clean break
What could a mustard cut look like going forward? You could conduct a feature query using JavaScript to conditionally load the stylesheet, but relying on JavaScript introduces a brittleness that would be best to avoid. You can’t use @import inside an @supports block, so we’re left with media queries.
The following query will prevent the CSS file from being delivered to any version of Internet Explorer and older versions of other browsers:
<link id="mustardcut" rel="stylesheet" href="stylesheet.css" media="
only screen,
only all and (pointer: fine), only all and (pointer: coarse), only all and (pointer: none),
min--moz-device-pixel-ratio:0) and (display-mode:browser), (min--moz-device-pixel-ratio:0)
">
We’re not really interested in what particular features this query is testing for; it’s just a hacky way to split between legacy and modern browsers. The shiny, modern site will be delivered to Edge, Chrome (and Chrome for Android) 39+, Opera 26+, Safari 9+, Safari on iOS 9+, and Firefox 47+. I based the query on the work of Andy Kirk. If you want to take a cutting-the-mustard approach but have to meet different support demands, he maintains a Github repo with a range of options.
We can use the same media query to conditionally load a Javascript file. This gives us one consistent dividing line between old and modern browsers:
(function() {
var linkEl = document.getElementById('mustardcut');
if (window.matchMedia && window.matchMedia(linkEl.media).matches) {
var script = document.createElement('script');
script.src = 'your-script.js';
script.async = true;
document.body.appendChild(script);
}
})();
matchMedia brings the power of CSS media queries to JavaScript. The matches property is a boolean that reflects the result of the query. If the media query we defined in the link tag evaluates to true, the JavaScript file will be added to the page.
It might seem like an extreme solution. From a marketing point of view, the site no longer looks “professional” for a small amount of visitors. However, we’ve managed to improve the performance for those stuck on old technology while also opening the possibility of using the latest standards on browsers that support them. This is far from a new approach. All the way back in 2001, A List Apart stopped delivering a visual design to Netscape 4. Readership among users of that browser went up.
Front-end development is complicated at the best of times. Adding support for a technologically obsolete browser adds an inordinate amount of time and frustration to the development process. Testing becomes onerous. Bug-fixing looms large.
By making a clean break with the past, we can focus our energies on building modern sites using modern standards without leaving users stuck on antiquated browsers with an untested and possibly broken site. We save a huge amount of mental overhead. If your content has real value, it can survive without flashy embellishments. And for Internet Explorer users on Windows 10, Edge is preinstalled. The full experience is only a click away.
Internet Explorer 11 with its ever-present “Open Microsoft Edge” button.
Developers must avoid living in a bubble of MacBook Pros and superfast connections. There’s no magic bullet that enables developers to use bleeding-edge features. You may still need Autoprefixer and polyfills. If you’re planning to have a large user base in Asia and Africa, you’ll need to build a site that looks great in Opera Mini and UC Browser, which have their own limitations. You might choose a different cutoff point for now, but it will increasingly pay off, in terms of both user experience and developer experience, to make use of what the modern web has to offer.
We’ve just announced the next Write the Docs meetup in Sydney: Sydney: Content strategy and more Tuesday, Jul 3, 2018, 6:00 PM Atlassian341 George St, Sydney NSW 2000 Sydney, AU 3 Documentarians Attending Join us to chat about docs – why they’re a Good Thing and how to make them even better. Tech writers, engineers, editors, […]
Sarah O’Keefe, Bill Swallow, and Alan Pringle discuss the connections between content strategy and management consulting. Twitter handles: Sarah O’Keefe Alan Pringle Bill Swallow Links: Podcast: You are not unique The rise and fall of #contentstrategy
The post Podcast: content strategy and management consulting appeared first on Scriptorium.
As the area coordinator for the online Professional and Technical Writing Program at Northern Arizona University, Erika Konrad can answer your questions and help you to figure out if the NAU program might be helpful to you.
We recently announced the new releases of MadCap Flare and MadCap Central, where we introduced new features designed to streamline collaboration between technical writers and subject matter experts. With features such as a new browser-based lightweight editor, new user types, and …
The post Enhanced Collaboration, Contribution and Review with the New Cloud-based Editor in MadCap Central appeared first on MadBlog: The Official Technical Communications Blog for MadCap Software.
An Adobe FrameMaker template stores formatting information so that it can be applied to one or more documents to ensure consistency. Learn more about working with templates in this guest blog post by Matt Sullivan.
Stoplight provides a platform with visual modeling tools to create an OpenAPI document for your API -- without requiring you to know the OpenAPI spec details or code the spec line by line. This API specification document can act as a single source of truth that empowers the whole API lifecycle, from UX prototyping to testing, development, documentation, sales, and more.
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.
Deep in the Amazon rain forest, they do a really marvelous thing. Have I seen it for myself? Well, no. Did I hear it from an eyewitness? No again. Truth to tell, I read about it on the internet. I need to back up and start from the beginning. Dave Thomas, in a recent article […]
MadCap released Flare 2018 last week. In this post, I’ll look at several of the new features that I think are most useful or have the most potential.
Side Navigation OutputThe tri-pane skin has existed since 1995 and works perfectly well but it screams “online help”. MadCap’s Top Navigation, or topnav, skin, introduced several years ago, added a more webby look to Flare targets. However, topnav has some limitations compared to the tripane, primarily the fact that it’s not good for targets with long or complex TOCs. Topnav displays the level 1 TOC heads in the upper pane so having a lot of level 1 heads means that the upper pane may use a lot of space, reducing the space available for content in the lower pane. See the image below for an (extreme) example of how the topnav uses the space in the upper pane.Reducing the blank space on the left and right sides of the upper pane will reduce the number of lines that the TOC needs. But a long or complex TOC may still need this much space.The next image shows what happens if the user hovers over one of the headings, in this case “Firewall Properties”.Again, it can be hard to fit long or complex TOCs into this structure. The tripane eliminates this problem but at the cost of an old-style look and some codes that could cause trouble under HTML5. MadCap’s solution was to create a side navigation version of topnav, as shown below, first collapsed.And then expanded, below…It’s showing the same TOC as the topnav example, but TOC length is no longer an issue since the TOC pane can scroll.Be aware that this skin, like topnav, assumes that the primary navigation for the target is the TOC and search. No index.In summary, I think this skin is exactly what we’ve needed to offset topnav’s TOC space limitations and I expect it to see wide use.Project AnalysisMadCap has offered a somewhat tangled set of project analysis options for years – a built-in report generator and a related file tag feature, a Project Analysis option (View > Project Analysis), and the separate Analyzer product. The report generator and Analyzer product are similar; both offer 120+ reports on broken links, snippet suggestions, undefined styles, and so on. The main difference is that the report generator just creates the reports whereas the Analyzer product can actively help you act on them. Flare has also offered a little subset of the Analyzer under its Project Analysis option (View > Project Analysis).In Flare 2018, MadCap appears to be taking steps to streamline all these options. The report generator and file tags features are still available but MadCap has added the core of the Analyzer product to Flare itself. In other words, we’ve gone from this in pre-2018 versions.To this is Flare 2018 (with just one of the menus expanded and 44 reports in total). It’s not the full Analyzer but it’s a good start.In summary, this should go a long way toward strengthening the analysis and management aspects of any Flare project.Find ElementsFind Elements is a seemingly innocuous little feature that should come in handy if you have to clean up the code in legacy files. It’s available from the Home ribbon’s Find and Replace group and looks like this when first opened.The Find What field offers the following options.The results appear in a Find Results pane, typically at the bottom of the screen.In summary, the most useful options, in my opinion, are inline styles, if you have to clean up legacy files, and MadCap, if you’re using Flare to create HTML files for use outside Flare, such as for a wiki, and have to find and remove Flare-specific tags in the output HTML files.Other Interesting FeaturesTwo in particular…* Review Workflow with MadCap Central – This new feature adds a new twist to your review workflows. If you’re a Contributor user, you’ve been able to solicit comments and new content from SMEs for years but you had to buy Contributor to do so. Now, if you’re a Central user, there’s no need to buy Contributor. Instead, you can add your SMEs to the review workflow through Central, in the cloud. Some of the benefits include multi-reviewer workflows, a simplified review-only interface, and change tracking. * Elasticsearch – This new feature adds a third search engine option to your projects in addition to MadCap’s own search and Google Search. My experience is that most users happily go for the MadCap search but a small number are looking for alternatives. For a comparison of the three types, see http://help.madcapsoftware.com/flare2018/Content/Flare/Targets/More/Setting-Up-Search-Engine.htm.
SummaryWhat I like:* How the Side Navigation Output allows Flare authors with long or complex TOCs to get the same benefits as topnav but without the space constraints. * How the Analysis feature adds tremendous project management and analysis control natively. * How the Find Elements feature helps authors look at the internals of their projects. * How the Central-based workflow adds a new option to Flare and continues what appears to be MadCap’s move into the cloud.
In my opinion, these features, especially the Side Navigation Output, make Flare 2018 a solid release that’s worth upgrading to.
In just a couple of weeks, technical writers and documentation strategists will gather in San Diego for MadWorld 2018, the premier technical communication and content strategy conference. They’ll be joined by our lineup of speakers, ready to deliver their deep …
The post MadWorld 2018 Speaker Spotlight: Kearsty Dunlap Schneider on Creating a Road Map for New Users appeared first on MadBlog: The Official Technical Communications Blog for MadCap Software.
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!
Make content production and publishing fun again with these 10 Adobe FrameMaker Features presented by Matt Sullivan …
I usually sleep quite well, but every once in a while, sleep eludes me for no apparent reason. So there I am at 2 a.m., awake. Here are some of the things that keep my mind spinning: Why, after 20 years, are we still introducing ... Read More
The post Insomnia, content strategy edition appeared first on Scriptorium.
To ensure that you maintain a unified company voice that aligns with your brand strategy, you should take advantage of the Content Development Guide, created by Jorsek (makers of easyDITA).
Docs By Design gives you a plate of Bob Watson’s professional life and and a side dish of the personal. His posts focus on his own experiences in the world of API documentation and his experiments in coding.
FrameMaker is better than Word for tech docs, says Matt Sullivan in his guest blog post. Why? Read yourself …
We’re excited to announce the new release of MadCap Flare 2018, introducing a number of significant features that provide users with enhanced functionality and flexibility. In this new release, we’re empowering entire documentation teams with features such as cloud-based editing …
The post Introducing MadCap Flare 2018: Cloud-Based Editing, Elasticsearch, MadCap Analyzer Functionality, and More appeared first on MadBlog: The Official Technical Communications Blog for MadCap Software.
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.
On Wednesday this week, the Write the Docs (WtD) Australia group held a meetup entirely in cyberspace. Or, in the cloud, remote, virtual… whatever you’d like to call it.
Here’s a neat trick for finding the date the content on a web page was last updated if it’s not clear from the page itself: Open the web page in a browser window. In the address box, type Javascript:document.lastModified then press Enter. The date and time the page was last updated is displayed (NOTE: The […]
When is a pet peeve more than just a pet peeve? When it drives I crazy! Let’s re-establish “me” as a perfectly lovely word and give “myself” the boot. We make up nouns and verbs at the drop of a hat – “Google it”, “Blog it” – and after a while these made-up verbs make […]