Archive for February, 2012

Some UXers might not really be designers

Feb
22

Adam Connor posted yesterday that he doesn’t believe in UX design. Steve Baty responded that much of UX design isn’t design, and pointed me to an article by Jonas Löwgren that contrasts what UX designers do and what “big-D” designers do.

I think I understand the contrasts that are being made between UX and “big-D” Design. Many UX roles actually focus on detailing the product without going through the design process that includes:

  1. an examination of the problem that is broad enough and abstract enough to consider solutions that seem very different from what currently exists
  2. a divergent ideation phase
  3. prototyping to explore and select solutions


The difference between your job title and what you’re expected to do all day

What if someone has those skills, but she is hired into a company or team that defines the role more narrowly? Or what if she goes into one of those narrow roles without a full grasp on the design process? I’m amazed at the carved up job titles I see at large companies. I’ve seen companies hoard the strategy and innovation within the jurisdiction of a few overworked, unavailable individuals. And advocating for best practices within an organization that hasn’t yet learned to value them can be a masochistic practice.

An example from tech comm

I have a technical communication background. Tech Comm degree programs and books by Joann Hackos and Ginny Redish will tell you that you technical writers approach documentation by creating a documentation plan, researching users, writing, testing, publishing, then repeating the process. Many, many technical writers don’t get to do all of that. By the time you do the work of advocating for the full process, breaking down silos, and making it happen for real in an organization, you’re pretty much a content strategist.

Some in the UX field use the methods above. I know UX designers who certainly do know how to design for multiple dimensions of the experience, and were hired for that ability. I know interaction designers who address more of the experience than smooth navigation through the UI. Here is a free HCI course by Scott Klemmer at Stanford that includes rapid prototyping and evaluation of multiple early ideas.

Is it mainly advanced practitioners (or those who went to great schools) who get hired to be designers proper?

Looking at Löwgren’s article, is it really true that UX designers would only observe users in order to improve current workflows? Or is it that a designer with more limited knowledge (or in a job where that is not expected from her, or on a project where exploring possible futures more fully is out of scope or budget) will glean less from fieldwork?

I agree that designers are well equipped to be architects of the big picture and communicators of the design vision. My experience is that breaking down silos is an advanced skillset, and hiring someone who has explicit responsibility for communicating the big picture, and having processes to support that, is a unusual thing that sets the top notch companies apart. I would like to know how that compares to the experiences of others.

But is it sensationalist to say that one doesn’t believe in UX design?

One of the commenters on Connor’s post said it was. I think it might be more accurate to say that some people with the job title are not actually UX designers. Either way, it’s got plenty of potential to be alienating.

I understand the need to discuss the differences between the roles and a standard for what we call design. From what I can see, the benefits of doing that are educating practitioners in order to elevate our work, helping us choose a focus and talk about our work, and helping organizations determine who they need for a given project.

But really, isn’t someone always going to rely on more than a label to know who to hire? Aren’t you always going to have to talk to someone for more than two minutes at a meetup or conference to really know what they do?

Share

Survey: project documentation needs

Feb
10

I want to learn more about how writing skills can best support the product development life cycle. I’m starting with this survey, which is intended for folks who do not provide technical communication or other writing services as their core offering or job responsibilities.

So, I’m hoping to hear from project and product managers, business analysts, designers, developers, etc.

Writers and technical communicators, I’ll be hitting you up soon. Promise!

Take the survey
Share

I tried to make a simple content strategy diagram

Feb
5

“Text instructs, guides, confirms, communicates, connects.”—Kristina Halvorson, Content Strategy for the Web

Content strategy isn’t just about web content for your customers.

It’s also about learning from your experiences to reduce process loss and plan your next iteration.

It was supposed to be simple.

I pictured three steps. I sketched a few versions, and ended up thinking about enterprise content in three phases. The first phase was experience: working on the project. The second phase was the content businesses use to communicate internally about the process. The third phase was shipping the product and publishing the content communicates about the product and the insights gained from the project.

I pictured three boxes with a list of activities and deliverables for each.

But wait, I wanted to show the relationship between the three as a cycle, with the published content informing the next project.

But some of the content deliverables fed back into the process before the publishing phase. And combining internal publishing with external publishing seemed problematic.

And there’s the problem that my three “phases” aren’t even semantically parallel.
So, this cake just isn’t done.

I think I need to make a list of project activities and content deliverables, think about how much I want to generalize about projects, decide whether I want to include content from supporting functions like human resources or IT, and try again.

Share

When is it time to hire the technical writer?

Feb
1

Often teams request documentation long after work has begun on the product, leaving just enough time to fill their order, whether or not it’s actually the best type of documentation for the users. This happens to in-house writing teams and outside consultants.

How do you avoid this? When is the right time in the project to bring the writer on board?

Some writers say that starting too early is a waste.

One view is that starting early is a waste of resources because when the product changes many times before release, they have to rewrite and rework graphics.

I have come on as a consultant and provided a draft help system for testing and review inside of a week.

But I can tell you that when there is time, I also rewrite plenty of things that have nothing to do with changed functionality. As the project progresses, I learn more about the users and the product. I can create a document structure and terminology that is recognizable to users. It takes time to translate that from the inside lingo that the product team is using. And I can get deeper product knowledge.

And? Brevity takes time.

I’ve seen it presented by Sharon Burton that you can give the writer the product use cases and she can scope the writing project. (I love this thread in which she breaks down how knowing the audience helps an experienced writer leverage a use case. For you buzzword snobs, I only said leverage to avoid saying “use” twice in the same sentence.)

Yes, providing clear use cases helps experienced writers learn the product. But it requires being able to hand off complete, clear, agreed-upon, up-to-date use cases. Go ahead and grab them; I’ll wait.

Don’t have them? Provide time for the writer to extract them from your project team and assemble them in a way that is recognizable to your users. Then add the time it takes to rewrite so that you don’t have bloated, wordy content. Revision increases the probability that when users read the help, they don’t hate you.

Better yet, have the writer write the use cases.

The process of clearly stating the objectives of your product benefits product development.

If your use cases, user stories, test cases, and requirements are not clearly stated, how likely is it that you don’t have consensus and shared understanding about those objectives across the project team. Even the process of fine-tuning grammar can have value in that it prompts you to get clear about who does what to whom and when. Useful stuff when it comes time to code. Technical writers are trained to dig for this information, and can facilitate the process.

If you’re doing agile development, and there is less documentation of these things, a writer can help you figure out how much is enough. As a bonus, she can use these materials as outlines for the help guides.

What about the interface text?

Buttons, labels, and tooltips are all text. Is that text consistent, spelled and capitalized correctly, and grammatically parallel? Why does it matter? (Think user experience, credibility, and translation cost.)

Do you want the writer to work with the product team on the logistics of the implementation? Starting early minimizes unpleasant surprises, and gives your writer the opportunity to help bridge any technical gaps.

If nothing else, if you bring the writer in toward the end of the project, how much time will your developers and product specialists have for demoing and explaining functionality? As a writer, I’ve had project and product managers sitting with me to do these things because they couldn’t spare their developers’ time. Immersing the writer in the product when the project is young can alleviate that urgency. And if you have the right writer, if you involve her early in the development process, she can contribute to the overall user experience.

But a lot of those things are product specialist/tester/developer/user experience responsibilities.

That’s very, very interesting, don’t you think? I think it illustrates that there are some transferable skills that are possibly undervalued.

So, when do you hire the writer?

Well, as they say, you get what you pay for.

Do you still have time to make the most of an top-notch, experienced writer?
Hire early, and give her as many of the text-related tasks as you can.

Do you need good content fast?
Hire a top-notch writer, and pay her accordingly.

Share