Join the fine folks at World IA Day on Feb 20, 2016 to celebrate advancing the practice of information architecture.
Join the fine folks at World IA Day on Feb 20, 2016 to celebrate advancing the practice of information architecture.
Sometimes the writing comes easily, and then there’s the last two months. I really wondered if I had run out of things to say. I knew I wanted to write about how more web designers and developers need to write about their work. So I wrote a bunch of paragraphs down, and then on a lark (I’m not even a regular listener), I downloaded episode 110 of The Web Ahead.
I nodded along with host Jen Simmons and guest Jeremy Keith saying some very smart things about the web and its roots as the El train cut across Philadelphia. But at the 48-minute mark things got weird, because Jen and Jeremy basically started writing my column for me while I listened. Jeremy said:
The fear of stating the obvious is one of my primary personal roadblocks to writing. Jeremy’s words evoke Samuel Pepys’ diary, which is a famously important resource for historians precisely because it includes so much detail about life in the 1600s—including many items that he could have dismissed as being mundane and obvious.
I appreciate a well-written, logically-structured, authoritative blog post about code as much as the next person. But I also have a love for the blog post that is written with a posture of humility: I know this much, so far. Or even: Why is this happening? Seeing your own stop-start journey through design and code reflected in someone else’s writing can remind you that it’s ok to not have everything figured out. Turns out nobody does.
Often when a teammate shows me something cool, at the end of our conversation I’ll half-jokingly say, “write it up.” I think that’s pretty good advice regardless of where you currently sit on the continuum of despair to triumph. Don’t even wait until you have everything figured out, at the end of the project. It’s ok to write what you know now, while everything is fresh in your mind and the sheer agony (or thrill of discovery) borders on the physical. If you’ve just solved a particularly flabbergasting problem, imagine yourself on the other side of that experience, just hoping that DuckDuckGo or Google will turn up a post with even the barest hint of a solution. If that were you, you wouldn’t care that the blog post wasn’t polished. You’d just thank your lucky stars that someone took the time to bang something out and hit publish.
“But nobody will read it,” you say. That may be true. But the opposite could also happen. A few years ago I was interviewing for a job, and my future boss said, “I like how you articulate things. I’ve read some of the stuff on your blog.” I was so surprised, I didn’t even think to ask which posts she liked. For all I know it was the ones where I recount the silly things my kids say. That memory made me think of this fantastic interview with Ursula K. Le Guin, where she says, “There’s always room for another story… So if you have stories to tell and can tell them competently, then somebody will want to hear it….”
On the other hand, that might be exactly what you fear—that someone actually will read it. But that needn’t be an intimidating thought. Through your writing people can to get to know you, in a way that often gets lost in casual interactions with coworkers (or formal ones with a potential boss or client). Because if you read enough of a person’s writing, their voice comes through. It doesn’t matter if it’s just explaining a technical issue and offering a solution. Their quirks, their interests—these things bleed through if you read enough of their words.
Getting more adept at writing can help you communicate confidently in other ways too. In a recent ALA On Air live event, Jeffrey Zeldman emphasized the benefit writing can have on your problem-solving process:
So now that you’re convinced, where do you start? You might start by giving yourself permission: “I allow myself to publish this thing.” This is one of those things that I’m still working on, myself. I’ve always found writing enjoyable, even easy. Publishing, however, is not. I’ve been blogging for several years, but my ratio of drafts to final posts is pretty dismal. This column has been good for me, because now I’m accountable to someone other than myself. I’ve got an editor that I don’t want to let down. I’ve got folks who actually read this column and respond. But maybe you don’t need more accountability. Maybe you actually need to lower the stakes, and give yourself permission to just get it out there. And again, Jeremy Keith said something along the lines of what I wanted to write:
Holy smokes. I heard that, and I almost bulk-published my entire WordPress drafts bin.
Recently, CSS-Tricks ran a survey that asked its community to weigh in on topics that they face daily. I answered the survey, and one of the interesting results was for the question, “You’re stuck. You search the web. You prefer to find answers in these formats:”. The top answer was blog post. Blog post! One of the other leading answers was “Q&A format page” (something like Stack Overflow). That made me think. Why wasn’t Q&A the top answer? Maybe it’s because while web designers want something that works if we simply copy-and-paste, we are also driven by why as much as how.
Code has a story. One of my favorite posts to write (and read) goes something like: “This wasn’t documented anywhere I could find, and it’s such a weird situation that if I don’t write about it nobody would believe me.” I made a category on my blog just for those posts: Technology’s Betrayal. I feel like a web designer’s life is full of those little stories, every day. And usually you tell your teammates over lunch, or over a beer, and you laugh and say, “Isn’t that nuts?” Well, I’m here to say, “write it up.” Let someone else hear that story, too.
A note from the editors: We’re pleased to offer this excerpt from Chapter 5 of Aaron Gustafson’s book, Adaptive Web Design, Second Edition. Buy the book from New Riders and get a 35% discount using the code AARON35.
■ ■ ■
Late one night in January 2014 the “parental filter” used by Sky Broadband—one of the UK’s largest ISPs (Internet service providers)— began classifying
With the domain so mischaracterized, Sky’s firewall leapt into action and began “protecting” the vast majority of their customers from this “malicious” code. All of a sudden, huge swaths of the Web abruptly stopped working for every Sky Broadband customer who had not specifically opted out of this protection. Any site that relied on CDN’s copy of jQuery to load content, display advertising, or enable interactions was dead in the water—through no fault of their own.
■ ■ ■
In September 2014, Ars Technica revealed that Comcast was injecting self-promotional advertising into websites served via its Wi-Fi hotspots.3 Such injections are effectively a man-in-the middle attack,4 creating a situation that had the potential to break a website. As security expert Dan Kaminsky put it this way:
Comcast isn’t the only organization that does this. Hotels, airports, and other “free” Wi-Fi providers routinely inject advertising and other code into websites that pass through their networks.
■ ■ ■
In traditional software development, you have some say in the execution environment. On the Web, you don’t. I’ll explain. If I’m writing server-side software in Python or Rails or even PHP, one of two things is true:
In the more traditional installed software world, you can similarly control the environment by placing certain restrictions on what operating systems your code supports and what dependencies you might have (such as available hard drive space or RAM). You provide that information up front, and your potential users can choose your software—or a competing product—based on what will work for them.
On the Web, however, all bets are off. The Web is ubiquitous. The Web is messy. And, as much as I might like to control a user’s experience down to the pixel, I understand that it’s never going to happen because that isn’t the way the Web works. The frustration I sometimes feel with my lack of control is also incredibly liberating and pushes me to come up with more creative approaches. Unfortunately, traditional software developers who are relatively new to the Web have not come to terms with this yet. It’s understandable; it took me a few years as well.
First, a little about GDS’s methodology. It ran the experiment on a high-traffic page that drew from a broad audience, so it was a live sample which was more representative of the true picture, meaning the numbers weren’t skewed by collecting information only from a subsection of its user base. The experiment itself boiled down to three images:
imgcontained within a
noscript element entirely.
What could cause something like this to happen? Many things:
http://perma.cc/BPN4-5XRRif you’d like to decorate your workspace.
Having defined goals and set an agenda for a workshop are a crucial first step. But what happens during the workshop is even more critical. Last time, we looked at how to define goals and attendees. This time we’ll look at the tasks and activities you choose to use, and how they’re determined by your stated goals. In the last post, these were our workshop goals:
Let’s take a look at a few common types of tasks we can use to get there.
The task of brainstorming simply asks participants to generate information. It’s not important exactly what they generate, as long as it’s on topic and there’s a lot of it. Using post-its, paper, and other tools for quick documentation are essential. One participant should be assigned as a scribe, so every idea is taken down. Participants should not be evaluating the worth of the ideas, just making a lot of them.
Sketching and drawing activities ask participants to generate versions or concepts of a general idea. Sketching wireframes, tools, or content structures for example. This process is a bit more focused, as there is a concrete topic or interface structure everyone is riffing on.
Ranking is putting existing options or ideas in order from best to worst, or from one to five—just like the Olympics, where only one person can win gold, silver, or bronze. Rating is assigning a value to existing options. More than one option can have the same rating, like on Yelp, where lots of restaurants have three or four stars. These tasks force attendees to use discussion and debate to evaluate existing options and how they relate to each other.
Mapping asks attendees to provide suggested actions based on certain constraints or criteria. It can mean mapping pathways through research questions, an interface, or even product delivery strategies. The key is that the obstacles to success are previously defined, and the attendees choose procedures that minimize those risks.
These activities form a core set that you can rely on in any workshop. Regardless of the specific steps in the task, it needs to relate to your goal. Let’s look again at our example.
We want to define UX research on a new product feature. This means it’s at the beginning and all wide open. A brainstorming activity would work well here, as you want to uncover new ideas and interface concepts.
We also want to decide on a set of research questions. This could call first for ideation on a general question format, and then ranking or rating to choose research questions the team feels will be most effective.
Finally, in order to show the value of the workshop and research in general, we want to demonstrate the power of UX research internally. There are a few ways to connect this goal with the activities. First, we can brainstorm a short list of internal company objections to UI and product changes. Then, we map our research questions to those objections, in essence forcing our research to prove them right or wrong. We’re making a direct link between information we want to get, and how it will affect design changes.
Now that you have some ideas of tasks to run and have connected them to the goals, we can go over how to actually set it all up in the workshop.
Workshops are hard work. A lot of that comes in the preparation, but carefully choosing tasks that match your stated goals is also key to success. Think carefully about what you want attendees to do, and then define the activities to achieve that. Explain what will be happening, as many times as necessary, and then step back and act as a facilitator, the person in charge, so they don’t need to worry about it. Each of these steps sets you up for success. But people are complex, and not every workshop goes according to the plans you set out. In the third installment of this series, we’ll look at some techniques for dealing with difficult attendees.