KnowYourUser

Source: A List Apart

This week, we at ALA have been thinking about processes of inclusion—that is, how we communicate with our communities. Who (and what) gets to be included? How do we use vocabularies, fonts, even emojis, to make those choices? And how do those choices create our culture?

Here’s what’s on our radar:

Anna Debenham, technical editor:
The UX team at Salesforce have written about the difficulties they’ve had coming up with color schemes that look good and meet the WCAG2 guidelines on color contrast—so they’ve built a wonderful site called Color Safe that generates color palettes that meet these guidelines. It’s great to see companies release tools like this that help make everyone’s sites more accessible.

Marie Connelly, blog editor:
I really loved this piece over on Hopes & Fears on how the Deaf community is incorporating new terminology (think: selfie, photobomb) into American Sign Language. It touches on so many things I love: words, the subtle complexities of language, and the beautiful messiness of community collaboration. I think the examples of how the Deaf community works through this process offer great food for thought for any of us working on content and communication.

Caren Litherland, editor:
“I’m pretty content,” writes Indra Kupferschmid in a pragmatic survey of the current state of web typography. Almost anything we could ever do in print, we can now do on the web; the web “forces us to think about typography in terms of parameters and to get clear about content versus form.”

Ethan Marcotte, technical editor:
Kathy Sierra’s essay on skater culture is a fascinating, moving look at a once-inclusive industry that, over time, marginalized its female members. It’s also an urgent warning for the digital industry, which faces a similar crisis.

A gif about a music video we are into:

What about you?
What stories are drawing your attention? Got any posts, pictures, tools, or code you want to share? (We love sharing!) Tweet us what’s on your radar—and what should be on ours.

Read the full article

Source: A List Apart

I toured the world twice—first in 2009–10, then in 2013–14. Only four years between the two trips, but it felt like a century internet-wise. Where I had to go wifi-hunting in 2009, in 2014 the web was absolutely everywhere—even in places with no mobile coverage, such as remote El Chaltén in Argentine Patagonia. Yet, I had the feeling this advent of a truly connected world wasn’t much cause for celebration. Indeed, I met many who struggled with an increasing need to disconnect.

I heard this line from fellow travelers numerous times, be it in Laos, Costa Rica, or New Zealand. I actually said it myself! As absurd as it sounds, it’s a perfect illustration of our ambiguous relationship with the internet.

Hyper-connected, hypo-social

Has the internet become repulsive? It certainly has in the eyes of Italian artist Francesco Sambo. His HyperConnection series depicts a dark and creepy humanity transformed—or tortured—by technology. Strikingly, Sambo is a savvy internet user, showcasing his work through Behance and SoundCloud.

Artists are often the first to capture the collective unconscious. Antisocial network I and II by Congolese artist Maurice Mbikayi are skulls made out of keyboards. “The […] sculptures ask questions such as to whom such technological resources are made available and at what or whose expense? What are the consequences impacting on our people and environment?” states Mbikayi. Less morbid but equally shocking is the alienation depicted in the Strangers in the Light series by French photographer Catherine Balet. In a very visual way, she questions us: are our babies born in a mad world?
<!–

–>

Digital malaise

Not only does hyper-connection alter our social relationships, it also makes us dumber, as pointed out as early as 2005. It threatens our health too. Twenty-first-century afflictions include digital fatigue, social media burnout or compulsive internet use.

Cures for these rising internet-related disorders include such radical solutions as rehab centers, or disconnection.

“I was wrong”

Most of the experiments in living offline have begun with the same cause and led to the same conclusion: the internet drives us crazy, but it brings us much more than we realize.

“The internet isn’t an individual pursuit, it’s something we do with each other. The internet is where people are,” says journalist Paul Miller in his famous “I was wrong” piece on The Verge. When you disconnect, you’re not just cutting the link with a network of computers, you’re actually isolating yourself from the rest of society. Miller also emphasizes that there is no such thing as a divide between virtuality and reality. To me, the best example of this is the sharing economy of “virtual” communities such as AirBnb or Kickstarter that is all about changing the “real” world.

The cure is worse than the disease

A lot of people today feel torn between two extremes. They aren’t against modern ways of interaction per se, but they won’t close their eyes to the excesses. The concern becomes even greater when the developing minds of children and teenagers are at stake. Many parents believe their digital-native offspring aren’t capable of using the internet moderately. You can’t blame them when you come across stats such as 20 percent of French young people are addicted to their mobile.

Is disconnection the only alternative to unhealthy internet use? That cure is worse than the disease. There must be another way.
Internet users are ripe for a new era, for the next step. A “more asserted, more mature” use, in the words of Thierry Crouzet, another famous disconnectee. Neither hyper- nor dis-connected: post-connected.

I see the advent of post-connected users wary of addictive or invasive tools. Post-connected users are also well aware that a social network centered on the individual, rather than on the group, inevitably leads to narcissism. They see the internet as a means for more direct human relationships—not a thing that feeds on our continual attention.

The internet pictured as monstrous should sadden us all, for it is one of mankind’s greatest inventions, one which has done so much for knowledge, education and human rights. Besides, it isn’t addictive by nature, we have turned into a drug.

We are the drug dealers

We, the web makers, have designed interactions which encourage selfishness and competition. We created tools that cause fatigue and stress. We practically invented hyper-connection.

It is therefore our responsibility to design for post-connected users. If we’ve been powerful enough to create addiction, then we must surely have the resources to imagine post-connected user experiences. How? I’ll give you some leads in my next column.

In the meantime, I would very much like to discuss this topic with you. Have you ever felt the urge to disconnect? Do you agree there is such a thing as post-connected users? Would you say addiction is the sign of a successful design? Your comments, criticism, and true stories are most welcome.

Read the full article

Source: A List Apart

Thanks to Proposify for sponsoring A List Apart this week! They know you don’t love writing proposals, so they built some tools to help your agency win more projects.

Read the full article

Source: A List Apart

WARNING: there are experimental elements and deeply controversial syntaxes ahead! Proceed at your own peril! You have been warned, and the website you save…could be your own. Ten years ago, right here in ALA, a wild-eyed hell-raiser going by “PPK” made a radical proposal: custom attributes in markup.

Well, okay. At the time it was radical. Here in the future, we have perfectly valid HTML5 data- attributes to contain all manner of information and act as behavioral triggers for our scripts.

All of this holds as true today as it did a decade ago. I know I’ve used data- attributes for both: to invoke custom behavior without touching the classes I use for styling—keeping my behavioral layers and presentation layers separate—and to pass relevant configuration information to said scripts. Picturefill 1’s data-srcset="1x source.jpg, 2x hd-source.jpg" comes to mind: we could define an attribute and write a script that dictates how the associated element should behave, all in one perfectly valid package.

maxlength? required? These custom attributes that once so daringly flew in the face of conventional web standards are now part of the HTML5 standard.

Maybe it’s best that the web didn’t linger too long on our warning at the top of the page.

Read the full article

Source: A List Apart

We work in interesting times. We recognize and accept that if you want to move “up” at a company, you have to become a manager. So, to rise up in the ranks means doing less of the thing you’ll be more responsible for. For a design manager, this means more time in email and Evernote, less time in Sketch and Photoshop. That doesn’t make a lot of sense, but it’s the way it is.

I’m not saying we don’t need managers—we desperately need good ones. But I started thinking about our blind acceptance of this cornerstone of modern business, and I wonder if there might be a way to create a system that values doing as much as managing—while also improving the skills of both groups.

I moved into my first management role about six years ago. I can’t quite remember the motivation behind it, but it was some combination of company need and my desire to further my career (and a little bit of “I wonder if I can do it,” I guess). I also had the good fortune of having an excellent manager in one of my first jobs. It opened my eyes to the challenges and opportunities of management, and I wanted to contribute to that. It’s been a huge learning experience (I would say it was humbling, but hashtags have ruined that word forever) and I’m glad I did it.

But a couple of years ago something about being a manager started to bother me. At first it was just a a small voice in the back of my head: How can you be a good design manager if you don’t design any more? I tried to ignore it, but that voice grew louder over time, and eventually I had to deal with the question head on.

The problem is, if you’re a manager, you have career opportunities. Manager turns into Senior Manager turns into Director turns into Senior Director, and so on. If you’re “just a designer,” the path is less clear. Sure, there are Senior and Lead roles out there, but they’re very rarely equated with real career progress. And that’s a problem. It forces some individual contributors to become managers even if they prefer to let someone else take the lead, and it creates a management culture that can become extremely out of touch with day-to-day design activities.

So at the end of last year I made a change. Partly because I was tired, partly to test this theory, I stepped away from management and became “just a designer” again. At first it was weird. Where did all the meetings go? What is this flat surface that I get to sit and work at for most of the day? But then the weirdness subsided and it just got… enjoyable. I now spend most of my days designing products, talking about and helping teams implement those designs. I realized I fell behind on design skills a little bit, so I went into a learning phase, and it was fun.

What does this mean? Am I done with management? Is anyone who chooses a life of management doomed to heartache and despair? Absolutely not! If anything, going back to being an individual contributor has cemented my belief that good managers are as important as they are hard to find. And I certainly hope and plan to be in that role again in the future. Just not right now.

So here’s how all of this comes together. I think we need a career system that encourages people to oscillate between individual contributor roles and manager roles. Maybe we provide “manager sabbaticals” where a manager becomes an individual contributor on a team for six to nine months. Maybe when a manager goes on vacation, an individual contributor takes on their role for a period of time (or for the duration of an entire project). I don’t know exactly what this looks like yet, but I think it’s important for us to figure it out.

Being an individual contributor makes you a better manager because you understand the day-to-day frustrations of your team better, and it ensures that you keep your technical skills up to date. Being a manager makes you a better designer because you understand the needs of leadership teams better, which allows you to communicate more effectively. One feeds the other, so we shouldn’t be forced to “pick a track.”

There are, of course, caveats. People shouldn’t be forced into management by the stigma that only management = career advancement. Some managers have no desire to become individual contributors again, and they shouldn’t have to. It’s about choice. If we encourage (and reward) people to have the freedom to explore different kinds of roles, it can only be a good thing for our industry—and, more importantly, for users.

Read the full article

Source: A List Apart

A couple of years ago I hit a crisis point. There was a distinct divide between disciplines at my company; I had been labeled a “backend developer,” and it was starting to feel restrictive. The label wasn’t wrong: I spent most of my working hours writing server-side code. I enjoyed it, and I was good at it—but it wasn’t all that I could do.

I’ve always considered myself to have a fairly generalist skill set, and slapping a label on me meant that I wasn’t allowed to work on anything other than that which fell under my remit as a backend developer. I felt typecast. And, unfortunately, it’s not a divide found solely at that company; it’s ubiquitous across the industry.

So what’s the problem?

Consider the following project scenario: someone in marketing has an idea. They discuss it with a designer, who mocks it up in Photoshop. The designer hands it over to the front-end developer, who complains that the designer hasn’t considered how difficult X is to implement without major JavaScript hacking. She finishes her work and tosses it over to the backend developer, who flips out because the front-end developer hasn’t given a single thought to how Y is going to work with the company’s CMS.

Sound familiar?

Creating narrow groups of specialists divides teams and restricts the way we work together. In his article “Development is Design,” Brad Frost describes this divide as a fence over which specialists throw their respective pieces for other specialists to catch and run with. It’s not uncommon to see individual teams of “specialists” all sitting apart from each other. The larger the company grows, the more specialist stations are added, each with their own tasks to complete, and mostly working in isolation—isolation that fosters unhealthy environments, restricts collaboration, and creates silos.

The key is to find the right balance of specialists and generalists on your team—to use both to their advantage and to nurture healthy, productive environments. Ultimately, the question is: how can experts collaborate better together?

Balancing your team

The appeal of generalists

In my formative years, I worked as a developer at a small software agency. There was complete freedom—absolute trust and no red tape. If one of the live sites had a bug, I had free rein to jump on the live server and peruse the logs, or check the configuration file for errors. I was not only allowed, but often required to do anything and everything. It was such a small company that there simply were no specialists.

In this way, I picked up some rudimentary design skills; I learned to navigate my way around a server and a database; and I became fairly confident in developing on the client-side.

This type of generalist approach to developing websites clearly has advantages: generalists learn how each component works with the others. They develop an understanding and appreciation of the whole process. They’re also good at just getting things done; there’s no waiting around for a specialist to do the database work for you.

Generalists can apply their hands to most things, but they’re never going to master everything. Sometimes, having someone who roughly knows their way around something just isn’t enough.

If you have a rock band made up of members who can play “Smoke On The Water” on every instrument, but you don’t have individuals who can belt out a Slash solo, or drum like John Bonham, then you’re never going to play to a sold-out house.

Making the most of specialists

Specialists are the experts in their field. They have spent their careers honing their skills on a given subject, and so it stands to reason that they’re going to be better at it than someone who doesn’t have their experience.

But misusing them will result in barriers to strong team collaboration. For example, once, at a large software company, I was tasked with investigating why our team’s build had broken. I identified that the problem was a missing dependency reference in the build definition. So, easy fix, right? Just pull up the build definition and fix the dependencies—until I realized I didn’t have access. I couldn’t edit the build definition directly, and was told I needed a “configuration specialist” to implement the fix.

What should have been a quick edit ended up taking hours while I waited for a specialist on another team to fix a problem that I knew how to solve. Unfortunately, this is a common scenario: rather than collaborating with the rest of the company, insular groups of specialists are given sole ownership over particular tasks.

Specialists are best placed in roles where they work alongside other team members, rather than separately. As Henrik Kniberg from Spotify says, “It’s like a jazz band—although each musician is autonomous and plays their own instrument, they listen to each other.”

Tear down the walls

Collaboration is the ultimate goal when forming a team, since it allows ideas to flow freely and encourages innovation. Creating specialist groups with total ownership and little to no cross-team communication will erect unnecessary barriers to collaboration. So how do we identify and remove these barriers?

Open up bottlenecks

I once worked with a company where the generalist development team outnumbered the specialists by fifteen to one. When developers required alterations to an automated build, they had to submit a ticket for a specialist to address. At one point, developers were submitting tickets faster than specialists could pick them up—resulting in a workflow bottleneck.

If the developers had been able to manage the automated builds themselves, the bottleneck could have been avoided. The knowledge held in the configuration team could have been shared among the developers, creating a more generalist approach and eliminating a silo.

To identify and open up your own bottlenecks, ask yourself:

• What part of the process is the slowest, and why?
• Are you relying on a single person to do all of your front-end development? Why?
• Are there any other people in the team who have similar skills, or show an aptitude for learning those skills?
• Do restrictive job titles prevent people from benefiting from each other’s skills and expertise?

Encourage communication

I’ve seen companies where software testers and developers were entirely independent teams. Testers were often only engaged at the end of the development process, when they received a test module based on the original requirements. But requirements can and do change during the development process—which, when teams operate completely independently, can lead to a lot of misunderstandings and lost productivity.

Including the testers throughout the development process would have improved communication and performance. Instead, project releases suffered as a consequence of the teams’ separation.

There are many ways to limit these kinds of divisions and foster communication on teams:

• Try to arrange the workspace so project teams can sit together. If they can’t sit together, then make sure that they have at least one conversation about the project every day.
• Remote working is a privilege, but it’s only possible if you make yourself available for discussions. A huge benefit of working in an office is being able to wander over to a colleague’s desk and just ask them something; remote working can make people seem unreachable. If you must work remotely, then make sure your colleagues feel comfortable contacting you.
• Scrum is a great tool for encouraging communication, especially the daily stand-up, during which each team member describes what they’re working on and any problems they need help with.

Fill in the skill gaps

Does your team lack the skill necessary to complete a project or deliver it efficiently? Is the team unfamiliar with a particular approach or technology? Do they lack the confidence required to successfully overcome a problem? Use specialists as a means to train your staff:

• Bring in a specialist from elsewhere in the company or, if the skills don’t exist internally, hire a consultant.
• Don’t allow specialists to solve the problem in isolation. Give your team members the opportunity to work closely with them, to learn from their experience, and to begin building the skills they lack.
• Encourage your specialists to conduct workshops. Workshops are also a nice way to build an interactive relationship between specialists and generalists; they open communication and foster a knowledge-sharing environment.

Promote knowledge-sharing

I once worked in a team that made a point of identifying silos. We were encouraged to work on the whole system and no single developer owned a specific area, though people had their preferences—I gravitated more towards client-side, while a colleague favored web services.

When I admitted that I was unfamiliar with how the company’s internal web services functioned because I hadn’t worked on them for so long, my colleague and I decided to alternate between client-side and web-service work during the next sprint, thus sharing our knowledge.

There are many ways to promote this kind of knowledge-sharing, which is fundamental to innovation and a collaborative culture.

Brown-bags

At my current company, we hold regular brown-bag lunches—everyone brings their own lunch to eat while a colleague gives an informal talk on a topic that they’re interested in. Brown-bags often spawn interesting discussions among participants: I can recall a few occasions where a technical feature or procedure has made its way into our formal processes following a fervent brown-bag.

Scott Hanselman at Microsoft suggests that companies “host technical brown-bags at least twice a month and encourage everyone to present at least every year.” It’s a good opportunity to encourage a healthy debate among colleagues with whom you don’t necessarily collaborate on a regular basis.

Guilds

In his article “Scaling Agile at Spotify with Tribes, Squads, Chapters and Guilds” (PDF), Henrik Kniberg defines a guild as “a group of people that want to share knowledge, tools, code, and practices.” Spotify uses guilds to bridge gaps between teams across the organization. For example, a developer is likely to encounter a problem that another developer in the organization has already solved. Where’s the sense in duplicating work?

Forming a guild allows common solutions to be communicated. It’s an opportunity to share experiences among teams.

At my current company, each team has at least one tester; the testers also belong to a separate QA guild, which allows them to pool their knowledge. It has been a big success: testing procedures have been standardized across the teams, and technologies like Selenium have been introduced into the test stack.

Internal open-source models

Limit the perception of ownership by introducing internal open-source models. Give everyone the ability to contribute to your source code or designs by replacing ticket-based systems with a model similar to GitHub’s pull requests. If you’re competent and comfortable making a change to a codebase that sits within another team’s “area,” then why shouldn’t you? The other team can act as curators of the project by reviewing any code submissions and feedback—but guess what? Now you’re collaborating!

Hack days

Are the projects you’re working on feeling a little stale? Try entering a competition as a company, or use a hack day to get ideas moving again:

• Arrange a company-wide Ludum Dare, where the best game at the end of the hack day wins.
• You don’t even need to restrict it to a day. Spotify holds regular hack weeks. You might even end up with something you can present to the business or a client.
• The National Health Service holds annual hack days in the UK, which local digital professionals are encouraged to attend. They work to solve the problem presented by NHS doctors and staff with whatever technology they have at hand. It’s incredibly empowering, and an amazing opportunity to give back to such an important organization.

Hack days don’t have to be IT-related; encourage people outside of the development team to take part by following the NHS model. Hack days allow people to work with colleagues they wouldn’t normally work with, in a situation where fresh ideas are encouraged and innovation is rewarded.

Go forth and collaborate

Strong collaboration is crucial to building a successful team—and collaboration is fostered by breaking down barriers. Make good use of your specialists by integrating them with your generalists and positioning them to guide, teach, and instill passion in your teams.

Read the full article

Source: A List Apart

To develop empathy, you need to understand a person’s mind at a deeper level than is usual in your work. Since there are no telepathy servers yet, the only way to explore a person’s mind is to hear about it. Words are required. A person’s inner thoughts must be communicated, either spoken aloud or written down. You can achieve this in a number of formats and scenarios.

Whether it is written or spoken, you are after the inner monologue. A recounting of a few example scenarios or experiences will work fine. You can get right down to the details, not of the events, but of what ran through this person’s mind during the events. In both written and spoken formats, you can ask questions about parts of the story that aren’t clear yet. Certainly, the person might forget some parts of her thinking process from these events, but she will remember the parts that are important to her.

A person’s inner thought process consists of the whys and wherefores, decision-making and indecision, reactions and causation. These are the deeper currents that guide a person’s behavior. The surface level explanations of how things work, and the surface opinions and preferences, are created by the environment in which the person operates—like the waves on the surface of a lake. You’re not after these explanations, nor preferences or opinions. You’re interested in plumbing the depths to understand the currents flowing in her mind.

To develop empathy, you’re also not after how a person would change the tools and services she uses if she had the chance. You’re not looking for feedback about your organization or your work. You’re not letting yourself ponder how something the person said can improve the way you achieve goals—yet. That comes later. For developing empathy, you are only interested in the driving forces of this other human. These driving forces are the evergreen things that have been driving humans for millennia. These underlying forces are what enable you to develop empathy with this person—to be able to think like her and see from her perspective.

This chapter is about learning how to listen intently. While the word “listen” does not strictly apply to the written word, all the advice in this chapter applies to both spoken and written formats.

This is a different kind of listening

In everyday interactions with people, typical conversation does not go deep enough for empathy. You generally stay at the level where meanings are inferred and preferences and opinions are taken at face value. In some cultures, opinions aren’t even considered polite. So, in everyday conversation, there’s not a lot to go on to understand another person deeply. To develop empathy, you need additional listening skills. Primarily, you need to be able to keep your attention on what the person is saying and not get distracted by your own thoughts or responses. Additionally, you want to help the speaker feel safe enough to trust you with her inner thoughts and reasoning.

There’s virtually no preparation you can do to understand this person in advance. There are no prewritten questions. You have no idea where a person will lead you in conversation—and this is good. You want to be shown new and interesting perspectives.

You start off the listening session with a statement about an intention or purpose the person has been involved with. In formal listening sessions, you define a scope for the session—something broader than your organization’s offerings, defined by the purpose a person has. For example, if you’re an insurance company, you don’t define the scope to be about life insurance. Instead, you make it about life events, such as a death in the family.¹ Your initial statement would be something like, “I’m interested in everything that went through your mind during this recent event.” For listening sessions that are not premeditated, you can ask about something you notice about the person. If it’s a colleague, you can ask about what’s on her mind about a current project.

Fall into the Mindset

How often do you give the person you’re listening to your complete attention? According to Kevin Brooks, normally you listen for an opening in the conversation, so you can tell the other person what came up for you, or you listen for points in the other person’s story that you can match, add to, joke about, or trump.²

It feels different to be a true listener. You fall into a different brain state—calmer, because you have no stray thoughts blooming in your head—but intensely alert to what the other person is saying. You lose track of time because you are actively following the point the other person has brought up, trying to comprehend what she means and if it relates to other points she’s brought up. Your brain may jump to conclusions, but you’re continually recognizing when that happens, letting it go, and getting a better grip on what the speaker really intends to communicate. You’re in “flow,” the state of mind described by Mihaly Csikszentmihalyi.³ You are completely engaged in a demanding and satisfying pursuit.

It’s a different frame of mind. You don’t want to be this focused on someone else all the time—you have to do your own thinking and problem-solving most of the time. But when needed, when helpful, you can drop into this focused mindset.

Explore the Intent

Developing empathy is about understanding another human, not understanding how well something or someone at work supports that person. Set aside this second goal for a bit later. For the time being, shift your approach to include a farther horizon—one that examines the larger purposes a person is attempting to fulfill.

The key is to find out the point of what the person is doing—why, the reason, not the steps of how she does it. Not the tools or service she uses. You’re after the direction she is heading and all her inner reasoning about that direction. You’re after overarching intentions, internal debates, indecision, emotion, trade-offs, etc. You want the deeper level processes going through her mind and heart—the things that all humans think and feel, no matter if they are old or young, or you are conducting the session 500 years ago or 500 years in the future. These are the details that will allow you to develop empathy. Collecting a shallow layer of explanation or preferences does not reveal much about how this person reasons.

To remind the speaker that you’re interested in answers explaining what is going on in her mind and heart, ask questions like:

• “What were you thinking when you made that decision?”
• “Tell me your thinking there.”
• “What was going through your head?”
• “What was on your mind?”

If you suspect there might be an emotional reaction involved in her story that she hasn’t mentioned yet, ask: “How did you react?” Some people ask, “How did that make you feel,” but this question can introduce some awkwardness because it can sound too much like a therapist. Additionally, some people or industries eschew talking about “feelings.” Choose the word that seems appropriate for your context.

Avoid asking about any solutions. A listening session is not the place for contemplating how to change something. Don’t ask, “Can you think of any suggestions…?” If the speaker brings up your organization’s offering, that’s fine—because it’s her session. It’s her time to speak, not yours. But don’t expand upon this vein. When she is finished, guide her back to describing her thinking during a past occurrence.

Make Sure You Understand

It is all too easy to make assumptions about what the speaker means. You have your own life experience and point of view that constantly influence the way you make sense of things. You have to consciously check yourself and be ready to automatically ask the speaker:

• “What do you mean?”
• “I don’t understand. Can you explain your thinking to me?”

Keep in mind that you don’t have the speaker’s context or life experience. You can’t know what something means to her, so ask. It takes practice to recognize when your understanding is based on something personal or on a convention.

Sometimes, you will probe for more detail about the scene, but there’s nothing more to say, really. These kinds of dead-ends will come up, but they’re not a problem. Go ahead and ask this kind of “please explain what you mean” question a lot, because more often than not, this kind of question results in some rich detail.

You don’t need to hurry through a listening session. There’s no time limit. It ends when you think you’ve gotten the deeper reasoning behind each of the things the speaker said. All the things the speaker thinks are important will surface. You don’t need to “move the conversation along.” Instead, your purpose is to dwell on the details. Find out as much as you can about what’s being said. Ignore the impulse to change topics. That’s not your job.

Alternatively, you might suspect the speaker is heading in a certain direction in the conversation, and that direction is something you’re excited about and have been hoping she’d bring up. If you keep your mind open, if you ask her to explain herself, you might be surprised that she says something different than what you expected.

It’s often hard to concede you don’t understand something basic. You’ve spent your life proving yourself to your teachers, parents, coworkers, friends, and bosses. You might also be used to an interviewer portraying the role of an expert with brilliant questions. An empathy listening session is completely different. You don’t want to overshadow the speaker at all. You want to do the opposite: demonstrate to her that you don’t know anything about her thinking. It’s her mind, and you’re the tourist.

Sometimes it’s not a matter of assumptions, but that the speaker has said something truly mystifying. Don’t skip over it. Reflect the mystifying phrase back to the speaker. Ask until it becomes clearer. Don’t stop at your assumption. Teach yourself to recognize when you’ve imagined what the speaker meant. Train a reflexive response in yourself to dig deeper. You can’t really stop yourself from having assumptions, but you can identify them and then remember to explore further.

Another way to explain this is that you don’t want to read between the lines. Your keen sense of intuition about what the speaker is saying will tempt you to leave certain things unexplored. Resist doing that. Instead, practice recognizing when the speaker has alluded to something with a common, casual phrase, such as “I knew he meant business” or “I looked them up.” You have a notion what these common phrases mean, but that’s just where you will run into trouble.

If you don’t ask about the phrases, you will miss the actual thinking that was going through that person’s mind when it occurred. Your preconceived notions are good road signs indicating that you should dwell on the phrase a little longer, to let the speaker explain her thought process behind it.

Footnotes

• 1. If you’re a researcher, it helps to know that listening sessions are a form of generative research that is person-focused rather than solution-focused. Thus, it’s easy to remember to keep them from dwelling on how solutions might work for people.
• 2. This was my epiphany from the UX Week 2008 workshop (PDF) by Kevin Brooks, PhD. Sadly, Kevin passed away from pancreatic cancer in 2014.
• 3. Mihaly Csikszentmihalyi, widely referenced psychologist and author, Flow: The Psychology of Optimal Experience, New York: Harper Collins, 1991, and Finding Flow: The Psychology of Engagement with Everyday Life, New York: Harper Collins, 1997, plus four other book titles on Flow. Also see his TED Talk and YouTube presentations.

Read the full article

Source: A List Apart

Thanks to Harvest for sponsoring A List Apart this week! Check out their tools to help you spend less time tracking and more time doing.

Read the full article

Source: A List Apart

Most web content projects have both structural and editorial aspects: for example, the information needs to be structured to support the new responsive design, and the current copy needs an update so it adheres to messaging and brand guidelines.

I’m often asked which is the best order to approach the work: structure first and then rewrites, or the reverse? I didn’t used to have a strong opinion, because it seemed to me like a chicken-and-egg problem. If the project starts with structure, I’m building content models off of bad information. If, instead, we start with rewrites, the writers don’t know what pieces we need to fill the models, because the models don’t exist yet. It felt like both directions were equally fraught, and I didn’t have any strong reasons to recommend one over the other.

(Note that I’m not talking about starting without the editorial foundations of a project: understanding the business goals, establishing a message architecture, and knowing what the work is supposed to accomplish are core pieces of any project. I’m talking instead about rewriting poor content—editing and creating new copy based on those foundations.)

Structure the content first, then do rewrites

I recently finished up the second phase of a project that we organized to focus on structure first, and reasons to stick with this approach piled up in my lap like turkeys going to roost. I think that a structure-first approach does make sense for the majority of my projects, and here’s why.

Content models are based on what content is for, not what it says

On this particular project, the existing copy was horrible. Jargony, clichéd, and almost stubbornly unhelpful. How could I build a useful content model off of bad content?

As I was working, I realized that the quality of the copy–even if it’s terrible–doesn’t really affect the models. I don’t build models off of the exact words in the content, but instead I build off of what purpose that copy serves. I don’t actually care if the restaurant description reads like teen poetry (sorry teens, sorry poets): it’s the restaurant description, and we need a short, teaser version and a long, full version. The banquet facilities should include well-lit photos taken within the last decade, and the captions should use the appropriate brand voice to describe how the rooms can be used. I don’t actually need to see decent photos or strong captions to build space for them into the models.

Structure decisions influence development and design direction

A complex content model will help inform all kinds of site decisions, from CMS choice to data formatting. Developers can make better architecture decisions when they have a sense of what kinds of relationships exist between content types, and designers can organize a pattern library that matches the granularity of the content model. The earlier the structure work is done, the easier it is to build integrated design and development plans.

Cramming bad content into strong models is an incredibly compelling argument for editorial intervention

When projects are focused on the structural aspects of the work—we want to recombine content for different channels, or make a clever responsive experience using structured fields—people often start out convinced that the current content is decent enough to do the job. “Sure, it could probably use some spiffing up, but that’s just not in the cards right now.”

I have never seen a more effective argument for the importance of editorial work than taking existing copy and seeing how inadequately it fills a model that we’ve already agreed meets our business goals.

A model I built recently had a content type for holding gushy snippets about the business’s amazing customer service. When we went to move the existing content into the new models, the only copy we could find to migrate amounted to “free ice water” and “polite employees.” We had already agreed that telling the story of the brand experience was a key job of the new website, and seeing how thoroughly their current content failed to do that was the kick in the pants they needed to find budget for an editorial assist.

Content models are easy to iterate

Waterfall isn’t a great match for content development any more than it is for design and code, so editorial rewrites often trigger adjustments to the content models. I may split one large field into two smaller ones, or the writers will find a place where I left out an important piece of content altogether. Refining the models is an expected part of the process.

On projects where editorial rewriting has been done first, though, I often end up with copy that, although now written beautifully, has no place in the model. In the course of structuring the information, we combined two pages into one, or are reusing the same description in three places, and so the editorial effort that went into fixing that copy is thrown out before it ever sees the light of day. That’s discouraging, and can lead to content creators feeling like I don’t value their time or their work.

What works for you?

It’s nice to have some strong reasoning behind my structure-first leaning, but of course my experiences may not translate to your project needs at all.

If you’ve worked on a project that organized structure work first, what advantages or drawbacks did that process uncover? From a design and development perspective, are there pros or cons to either direction that aren’t covered here?

If you’re a writer, does creating copy within a content model free or stifle your best work? If you prefer to start with editorial rewrites, what are the hidden benefits for the structural side of the project?

I believe there are real benefits to taking a structure-first approach to organizing content activities, and I’d love to hear how and if that works for your projects as well.

Read the full article