The survey is specifically for in-house UX professionals, or for those in staff-augmentation positions.

I have also been talking with consultants and recruiters who specialize in filling UX roles, but they typically have more influence in defining the role, so this survey is not for them.

Take the survey

Still wondering if you should take the survey?

Do you have one of these job titles, or something similar?

• UX Researcher
• UI Designer
• UX Designer
• UX Architect
• Information Architect
• Information Designer
• Technical Communicator
• Usability Specialist
• Content Strategist
• Interaction Designer

Then go ahead. And thanks.

Usually I research the people and organizations when I’m going to have a meeting, but this time I didn’t. I’d looked at their website briefly, weeks earlier, when my colleague invited me to attend with her. See? Inconsistent.

So, it took me about a half hour of listening to people introduce each other and allude to what they’ve been working on together for me to understand what the i.c. stars program was. Then I wondered if we were applying. Was this a big group interview? I didn’t figure out until nearly the end that my colleague and I were the featured guests.

I don’t feel particularly worthy of providing wisdom, right now.

I’ve been slogging through a slow-motion breakup and a job hunt (ahem, I’m business-building) for what feels like forever. If you wanted to be a negative jerk, you could use the words “effectively unemployed” and “wildly inconsistent” to describe my state of being on and off for six months, now.

So for about two minutes, finding myself on the spot as a mentor made me supremely uncomfortable. But then autopilot took over. I’ve been working on positioning myself in the job market for months now, so I’ve gotten comfortable describing myself and what I do. And this group was so sincere and so positive, I found myself saying some things about what I hope to accomplish in my work that I didn’t even know until I was saying them. If any of y’all are reading, you have something amazing in that program. I’m grateful to have met you.

A man named Rasheed asked me how writing can help us deal with our fears.

“It helps me deal with fear by helping me articulate to myself what I am afraid of,” I said, instantly. I compared it to making a list when you are overwhelmed. That’s glib, though, of course.

Sometimes the awful feeling is so big that giving it a name doesn’t make it any less the boss.

Sometimes we’re still going to get knocked to the ground and not be able to get back up for a long, long time. The truth is, I’ve been so down this past six weeks that not even writing has helped me. I mostly can’t even write.

At the beginning of last year, I was engaged. By summer, we weren’t engaged, but we were still committed. By the end of the year, all of that had descended into the dark six month period that preceded the breakup, which happened, you may be guessing, six weeks ago.

Sometimes the only benefit I get from being a writer is a log of the ship going down. Sometimes there is only cold, naked information, and no comfort.

No one got abused. Everything that happened was perfectly ordinary.

Except it is my story, so to me it is extraordinary and sacred. That might seem melodramatic. I couldn’t care less.

I take risks. I change my mind.

I’ve moved twelve times in eleven years. I sold my car and took the bus for six months to save for my sister’s destination wedding. I dragged my true love to a new city and risked our relationship to re-up on a better career. I started grad school, learned so much, performed inconsistently, and cashed in that semester’s worth of skill-building to get back to my own business. I went from making double what I’d ever made in my life to being effectively unemployed because I was bored with tech writing.

Yet, during all of that, I managed to lose a lot of time (and the most important relationship of my life) trying to learn the rules, playing dress up with different facades, and being ashamed of the things that kept me from being “successful.” I want to figure out how to not do that anymore.

Consistency is overrated.

There are more important things. I’ve learned and changed more than anyone I know these past two years. I’ve lost my most important person, but I wouldn’t have known he was so important if every single thing that happened hadn’t happened. I’m driven. I take risks. This means that when I fall, I fall hard. As Tom Robbins says, “Every big front has a big back. ” It’s time for me to own that, in that sense, it IS a big front. I’ve lost big, but I don’t think I’ve been wrong about myself. I’m not better off being steady and cautious. I’m not.

I get better all the time at making room in my life to fall down without letting people down. But sometimes the big, bad boss fucks me up. My right to lie here and bleed for a little while trumps anyone’s right to have me be consistent.

Learning about ourselves hurts, usually. Discovering too late what is important is a shitty lesson. Shoving that down inside me until later in favor of writing volunteer blog posts, smiling enough at networking events, and keeping a perfect attendance record at work? No. I see clearly when something cannot be postponed, and I choose accordingly. But most things can.

What does this have to do with writing?

Afterwards, I made sure to clarify for Rasheed that writing is a discipline. By sitting down and doing it every day, you learn to listen inside yourself for what you are afraid of, and what you want, and what is happening around you. You can’t just sit down one day to write a list of your fears and expect it to do for you what it does for someone who writes regularly. It’s a practice. Like yoga, or meditation, or religion, or running. It’s a muscle that gets stronger.

Have one thing that you’re consistent about, and it will eventually save your ass.

It won’t keep you from getting creamed, but when you have something like writing, eventually you’ll get up and do it in spite of yourself. Even if you’re a tearful, snotty zombie sitting in front of the keyboard. Even if it doesn’t solve anything. Even if it doesn’t make you feel better.

I’ve got this one thing, and I declare it to be enough.

By “in a vacuum,” I mean without having discussed the objectives and success criteria. What are the metrics? How will the results be used?

Without this information, receiving feedback can be like going to a meeting without an agenda. Painful.

If you have requested feedback, be clear about what is helpful.

UX architect Mike Hughes has written about “first eyes” and “last eyes” when it comes to critique. Is the piece a first draft, or is it due tomorrow? Have you ever asked for input at an early stage and gotten feedback that focused on low-level details? It can also be overwhelming to ask for a proofreading and receive copious suggestions on content and organization. I tend to be a high-level thinker, and so have been guilty of the latter. Save everyone’s time and aggravation by asking what kind of comments would be helpful.

Sometimes we’re asked to solicit opinions and it’s not clear why. I’ve been asked to have surprise stakeholders weigh in at late stages in the development process. If you’re in the habit of clarifying expectations for reviews, it can help you manage expectations about what you’ll do with the input. If I explain up front that I’ll schedule all non-emergency edits for the next release, everyone understands why they don’t see their edits incorporated immediately.

Explain known issues, architecture, and choices made.

If you haven’t done the final proofread or formatting, and you’re sending something for, say, a technical review, you may want to mention there may be issues. If there were tradeoffs made in the design, you can mention those and other design decisions.

Marta Presents Her Final Project by Peter Alfred Hess, on Flickr

How do you communicate design decisions for a review and still be brief enough to make the information palatable? How do you avoid the feeling of being in a tennis or boxing match; responding with your rationale, blow by blow, to the volley of things the reviewer doesn’t love?

One way is by breaking review into smaller chunks. Another way is by meeting prior to the review to explain the overall architecture and priorities of the design. I also like to meet after I’ve incorporated the reviewer’s edits to demo the changes inspired by his or her input. That’s a good time to discuss the edits I chose to defer or decline.

Know who has the final say.

Who are the stakeholders? Who needs to review, and when? Who owns which decisions? Talk to each of them (together, if possible) and agree on a review schedule.

To document this, you may be able to send out this agreement in an email, or put up a quick flow chart in the war room (hello, Agile folk). But if you have a team of writers or designers who move from project to project, dealing with some product owners infrequently, it can be useful to be able to point back to some more formal guidelines. For example, if your team uses templates or structured authoring, you may want to explain the process and consequences for deviating from those structures (or that you don’t). These guidelines can live in your SOPs or style guides.

At the very least, it’s good to confirm with your boss that you know which stakeholders decide about what.

If the review was not your idea, clarify expectations.

When someone announced they are going to review your work, it can be stressful. Performance reviews come to mind. It’s reasonable for you to ask for more information. Your questions can be helpful for the reviewer, too, and improve the quality of the review.

What questions will be asked? What criteria are used? What is the effect of the results? What response will be required by you if something is found to be lacking? What are the consequences? What is the timeline? How much preparation will you have?

I’ve got a new resolution to practice.

I don’t go to meetings without agendas, and I don’t go to critiques without agendas, either.

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?

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!

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.

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.

Have you read the Dear Sugar column on The Rumpus?

The Rumpus is a literary blog, and Dear Sugar is an advice column by an established author writing anonymously as “Sugar.” On Feb. 14, Sugar will reveal her identity. Whoever she is, Sugar is a writer’s writer.

In the world where she is a known author, one of Sugar’s genres is memoir.

It’s one of her sharpest tools as an advice columnist, too. In most of her columns, she tells a story from her life that somehow ties into her response.

She is not a therapist. The Dear Sugar gig is unpaid. Sugar holds herself up (past sex escapades and drug use, abuse she experienced as a child, messy finances) as a work-in-progess for all to learn from.

But when she teaches about memoir to writing students, Sugar doesn’t let her students get away with simply transcribing their experiences, though that is part of the process.

“You get no points for the living . . . It isn’t enough to have had an interesting or hilarious or tragic life . . . For what happened in the story to transcend the limits of the personal, it must be driven by the engine of what the story means.”

Sugar’s other main technique is to send the letter writer back to their own words for meaning.

The above quote is her from her response to a father who is worried about living too far away from his daughter.

“There’s a sentence in your letter that matters more than all the other sentences: I don’t want to be like my father. . . I don’t want to be like my father is a story I know. It’s code for a father who failed. It’s what your story is about.”

This past year, I have done more journaling than ever in my life.

This was mostly a result of my involvement in Havi Brooks’s Kitchen Table course (the course is closed, now).

This journaling has guided me through some major decisions: starting graduate school, moving, leaving graduate school, and my current job search, to name a few.

Using various writing techniques that Brooks teaches (though I don’t think I’ve ever seen her refer to them as “writing” techniques), I was able to move beyond reacting to these situations to finding the thread of my own story.

Prototyping is a way of learning from experience, and writing is a prototyping tool.

By first transcribing my experiences, and then asking myself what I saw in them and in the words that I chose to describe them, I derived meaning from this year, and I learned things that helped me decide what to do next.

I made a kind of prototype for my life.

Sugar observes that her letter-writers are very often looking for permission; permission to feel the way they feel, or to be what they want to be. Sometimes her mini-memoirs illustrate that she believes that they can grant themselves any permission that might be needed, and sometimes the theme is reaching, pushing, transcending.

Sugar holds up her story next to the letter writer’s own words, and the answer is written there between the two.

I’m starting with a lofty example because it’s the most important thing writing has done for me.

But there are so many little ways that writing is like prototyping. More on that another time.

PS. This post was sitting in draft and then someone posted a link to Seth Godin’s piece about writing like we talk: without being so afraid of messing up. Learning from the process. Hello, prototyping.

I’m talking about having some sort of online communication with readers, customers, or users. Being able to find books by that person, or websites geared towards selling his or her products, or links to academic articles published by other content providers, does not address this need for me.

A biography helps, but I’d like to have some writing or insight into the person’s current projects and thought processes. I’m disappointed when there is no blog, Twitter stream, or Facebook page for me to follow or link to. I want to discuss that person’s ideas with my colleagues and friends.

I don’t just want to see the finished product for sale. There are so many books I could buy, so many courses I could take, so many sources of information and products that I want to know something deeper that differentiates and draws me in.

The examples that are currently relevant to me are reporters and professors.

I’m linking up my learning, gathering, curating it. I want to know about the sources of my information, and if I admire that source, I love being able to follow them in a more continuous way.

Do you agree, or is this less important to you? What other jobs fall into this category for you?

I will be going full time, which very much limits the amount of time I will be able to work. My decision to commit to this program started out intuitively (as most important things in my life do) and progressed rapidly to anxiety as I lined up the logistics, and now, after orientation, I am back to feeling confident about it.

McCormick Tribune Campus Center on Main Campus

About ID

The professors gave a seminar during orientation to provide an overview of how they field the field of design and IIT’s position within that field, and they described some projects they have been working on. Our dean is Patrick Whitney, a well-known design consultant . He keynoted the STC annual conference in 2005, by the way.

Here’s a quick list of other professors and their amazing projects, the likes of which I’ll soon be helping with:

• Anijo Mathew, an interaction designer who worked on Zero Zero, Art Loop
• Patrick Whitney working on projects in interest-based education
• Stan Ruecker designing for the future of reading.

I can’t wait to have better questions to ask these professors. I can’t wait to have a job where I’m actually expected to have ideas like this.

Why would I do such a thing?

All of my reservations about this decision can be boiled down to two worries, and I have answers to them:

1. I feel like I should be able to take just the time and get the knowledge myself. But content is not free, and this program is first-rate content. This is one of the best design schools. This is the delivery method that these top designers are choosing for their knowledge.
2. Grad school at a private school is so expensive. Penelope Trunk calls it an “extreme investment;” risky because the job market changes so much. But I have chosen a field, design strategy, that integrates those changes, and hopefully drives them. I’m going to learn methodology that is versatile enough to be applied to any field, from the people who are inventing it.

I checked in with myself repeatedly to make sure wasn’t choosing school as an escape hatch (another P. Trunk dis of people who choose grad school). But I’ve failed at two businesses, successfully launched one, and have another in the works. I’m kind of addicted to a lack of certainty and comfort. And the idea of school right now is not comfortable or safe. So that’s not what I’m doing.

Still, I want to keep looking at the arguments against grad school as I progress, and see how my experience is measuring up.

Reflection vs. sleeplessness

So, I’m facing 100+-hour weeks, and will have a legit reason not to blog.

Ha.

I’d like to make time for blogging, actually, because having time to reflect. Patrick Whitney mentioned the role of reflection in learning while discussing research he’s doing on interest-based education. I realized that’s what blogging does for me: it helps me reflect on what I’ve learned at work. Much of what I’ll learn may not belong in a blog about technical communication, but some of it will. I hope I make time for that reflection.