Rubifying the Language

My favorite Scrum Master used the word "uniqify" in a sprint planning call today, as in "Could you uniqify that expression?" I poked him through the instant message tool we have because he had recently taken me to task for using the word "epistemology" in a design session.

It turns out that this is a fairly common pattern in Ruby, as in stringify, uniquify, htmlify, etc.

The rule seems to be that the verb [term]ify means to take the ensuing object of the verb and give it the qualities of the [term].

Of course, this has instances in our day-to-day language, that's where all these types of linguistic manipulations have their origin. To "liquify" is to to make the object like liquid. Its opposite is "solidify." It's very similar to putting "ize" at the end of a term to make a verb--but I sense a subtle difference I haven't yet quite distilled.

As an amateur linguist, I LOVE when a language can do this. Arabic does it on steroids, having a very complex set of patterns that decomposes just about every word down to a tri-literal root. Verb forms take their nuances from the root, as do noun patterns for the doer, the done-to, and the where-done.

English doesn't do it nearly enough. Sure, add and "er" to the end of a verb to get the doer, as in writer, rider, sleeper. Sometimes an "ee" to get the done-to, as in payee. Do we even have a pattern for deriving the noun for where-done from the verb? For example, the Arabic word for school, madresa, comes from a pattern that makes it "the place where studying is made to happen."

HTMLify is my favorite so far. "Can you express this in HTML?" becomes "HTMLify it."

Tonight I'm going to mealify some leftovers. Anyone who thinks that means "reheat" has never seen what I can do for leftovers.

Knowledge Life Cycle and Social Media

I usually try to keep work and blog separate, but I gotta say I really like working for IBM and especially the IBM Security Services group. Why? I get paid to have some really interesting conversations.

Last week I was in a meeting where we were discussing the right way to use Lotus Connections in our work team--versus a department Wiki we already have.

Lotus Connections is social network app that has forums, file uploads, activities, wiki, yadda yadda. BTW, it's pretty good. But the discussion was "When do we use that tool versus our more formal department Wiki--where we keep departmental procedures and such?"

The conclusion was actually quite elegant in its simplicity: We will use Lotus Connections to hold the conversation; we will use the Wiki to curate the answer. I'm sure that's not original--but we got there on our own, nonetheless.

I think this is a pattern that has lots of applications where social media has started to get traction. Online user doc vs. user forums, for example. STC SIGs and its Body of Knowledge is another example that I think about a lot and that seems to apply here.

I think this is a field that needs a lot of discussion and open dialogue, specifically, how to manage the life cycle of knowledge from ideation and churn, through vetted "this is how it is," and eventually to "this is last week's dead fish."

Of course, my traditional mistake is to impose formal process and control on what should be left open and organic, but still, I feel that some sort of process or guidelines would be useful. Here's my laundry list of questions. More questions, answers, general trouble-making--all are welcome:

• What are the stages of knowledge or what are the categories of maturity/credibility, whatever?
• What other dimensions should go into "whatever" in the question above?
• Where does knowledge live during these stages?
• Who moves its classification during its lifecycle?
• At what point is someone liable for the consequences if knowledge is acted on and proves wrong?
• When can knowledge be branded as intellectual property in an evolutionary model like this, and who gets to own it?

And I apologize if this is all naive and the solution is fully developed by now. I was very involved with Knowledge Management before social media had the kind of impact it has today.

Mixed message

Reminds me of the Steven Wright joke where he named his dog "Stay" just to confuse him when he called him.

The Software Development Death Cycle

Does this look like your development cycle?

All is joy and celebration on the product management side when the project begins. Then comes the iterations as the marketing requirements document is passed back and forth with engineering. (BTW, is it just me or does it seem we lose about 1/3 of the project's useful development time in this phase?) Then engineering goes to work and produces something they send to QA. The product manager sees it and goes postal. Well, been there!

I worked at a place where there was a product manager--let's call him Dave--that kept stirring the pot in QA when he got a glimpse of the UI coming out of development. The design and development team wanted to take out a contract on him. "How do we keep Dave out of the process that late in the game? He's creating too much churn."

I saw the problem differently--why were we disappointing Dave, the guy who brought us the work to begin with? I could understand if we were disappointing the customer, after all , they hadn't written the requirements, Dave had. I could understand if we were disappointing our partners, after all , they hadn't written the requirements, Dave had. But how was it that we were disappointing Dave?

I concluded it was the requirements process itself that was failing. It relied on words, and words were screwing the deal. As a technical communicator, that was a harsh realization, but I have come to learn the following:

• Gopen and Swan are right when they say "We cannot succeed in making even a single sentence mean one and only one thing; we can only increase the odds that a large majority of readers will tend to interpret our discourse according to our intentions. "
  
• Words, then, create the illusion of agreement.
  
• And my own realization is that any time words are a problem, more words are never the solution.

So we decided to quit trying to solve the requirements problem by writing better requirements. Instead we moved UI design to the front of the design process and made it a collaborative conversation among the product manager, the UX designers, and the developers. I've since had the opportunity to play with this model and improve it. More importantly, I keep re-validating that it works.

OK, here's how it works.

1. Start with a list of the requirements, doesn't have to be pretty or even very good. It's a conversation starter.
2. Sit in a room with a product manager, UX designer, and a developer and start creating a scenario that illustrates a requirement. Make it an explicit example. Who is the user, what's the problem he's trying to solve, imagine how our product would fit in. Tell the story and draw pictures (wireframes).
3. Do that for all the requirements or at least for the most important.
4. Have the developers size the solutions.
5. Let Product Management select from the solutions as much as the development bandwidth will allow.
6. Go forth and code.

That model can be iterated down to as small a granularity as you want. For example, do it for the top two "we know we gotta have this" and get the dev team coding while you sort through the rest of the requirements.

Here's why this works:

• The value that project managers bring is that they understand the problem space. Detailed requirements documents tend to end up being solution oriented--takes them out of their sweet spot.
  
• Developers design better solutions when you clue them in up front what the problem space is. Treat them like architects and not like carpenters.
  
• UX folks can model a product's behavior and validate it with stake holders and users with little to no code (that equates to fast and cheap).
  

I work in an Agile group now, and if we have a particularly snarky problem, we will put it in a design spike. That is a dev cycle in which we don't put a bunch of engineers on it. We iterate the concepts until product management, development, and UX come to consensus on an approach that is saleable, buildable, and usable.

No big magic, but the core ingredients are not substitutable:

• Early in the process
  
• Collaborative among product management, development, and UX
  

This can only mean one thing...

A while back I blogged that a website I use had been redesigned--seemingly to reach an audience younger than me. Here is what that design looked like:



Well, I went back today and it looks like this:



What made them change? Two theories. One is that they read my blog. Seeing as how I did not make the list of most influential bloggers in Tech Comm I am summarily dismissing that theory.

That leaves the most common reason UIs undergo abrupt and dramatic changes: The president's spouse or parents tried to use the site and complained.

Happens every time.

Good, Better, Best

Someone corrected my use of personas the other day and pointed out that the plural is personae.

File under reason 42.b of "Why people hate technical communicators."

It reminds me of "data."

A good sentence says "The data is clear on this."

The better sentence says "The data are clear on this" because we know that the singular is datum and data is the plural.

The best sentence says "The data is clear on this" because that's how real people talk.

Miller Williams, a former poet laureate, said he wanted to write poetry that cats and dogs could understand.

I don't know about you, but I never met a dog that could relate to personae--not even the ones named Rex.

In defense of my [pejorative] self

Some descriptions seem to carry negative baggage and get thrown at me from time to time. The only problem is that not only do I find these terms NOT pejorative, in fact, I have worked hard to earn them.

One is "writer." I remember sitting in a meeting and having someone voice her concern that several people in the room had referred to themselves as "technical writers." (I was one.) I know the history of this. The Bureau of Labor Statistics (BLS) has a rather outdated definition for technical writer. This person was advocating the title "technical communicator" to differentiate what we do from this outdated definition.

I grew up wanting to be a writer. When asked what I would most like to be, I never answered "a communicator." I think that the role technical writer is a legitimate subset of the profession known as technical communication. Technical writers focus on communicating with words. The problem with the BLS definition was not the term "writer," they just seriously understated what goes into technical writing.

I don't want to undermine a campaign to get technical writers more respect and more pay; I just don't want to have to apologize for what I do, and in fact am pleased to do, i.e., being a technical writer. Sometimes I'm something else; in my current job, for example, I am a user experience architect, another role in the field of technical communication. But when I take on the task of writing user assistance, I'm OK telling folks I'm a technical writer.

Another pejorative is "academic." In its negative sense, it means "irrelevant to real world applicability." In its positive sense, it can mean well studied in the research that has been done in a field and capable of generating valid, reliable knowledge by conducting original research.

I've worked real hard to try to qualify for that latter meaning, so I chafe a little when my desire to apply rigor is branded "academic" and meant to imply "irrelevant."

BTW, I'm sometimes branded pedantic--and that one I deserve and should try to be less of.

Phrases to Avoid

A tweet sent me to a web site that lists phrases to avoid in technical writing. Personally, I find their list to be pretty mild. Things like:

a majority of -- most

a sufficient amount of -- enough

according to our data -- we find

I'd like to add MY list of phrases that should not show up in your documentation:

• Hey, dick head, ...
  
• After you put out the fire...
• Your browser is as lame as you are.
• If you figure out what this feature does, let our tech writers know.
• Some side effects might include...
• In our defense...
  

The bandwidth discussion continued

Yesterday's blog about bandwidth and information attracted some very insightful comments and got me to thinking more about the issue of "Do videos take advantage of their bandwidth?" In other words, are they proportionally better given how much more information they convey?

The ensuing discussion brought a couple of things to mind. I remember from one of my technical communication courses that line drawings are often preferred in a manual (over photographs) because photos have too much detail. Drawings help focus the reader on the detail you want to draw attention to. I find the same principle with low fidelity wire frames over screen prototypes. I think the same can be said sometimes of video--is the fidelity a value-add or a distraction?

Another interesting paradox I noticed is that we tend to assume that videos are good for the neophyte. And Ken Hilburn makes an interesting point about how we instinctively filter out the unnecessary detail of a video. But that is more true for the experienced user than the neophyte. For example, I once tried to teach my mother-in-law how to use Yahoo email. She had a hard time getting through the browser because she thought everything was important. I was constantly saying things like "that's a banner ad, ignore it," or "that's the disclaimer text." We forget how media literate experienced users are, and how adept their filters are.

Where all of this has led me is not to dismiss video, but to approach it with a designer's eye much the way Tufte would have us look at a chart, namely, is each byte of information worth the bandwidth. Another way phrasing the question is "Am I taking advantage of the bandwidth?"

Let's revisit the example of the dobro video. If the purpose were to instruct, then maybe a good design would be to have a synchronized split screen of closeups on the picking hand and the slide hand. That way the bandwidth would be more fully invested in the information of value.

(BTW, please don't take this as being critical of those generous musicians who share on YouTube--I am so grateful for what they do for absolutely free.)

So if you are thinking of doing video, ask what is the information of interest and plan the video to put its bandwidth on that information. Eliminate spurious mouse movements, focus on fields of interest, shade out non-relevant areas of the UI, etc. When we do traditional video, we point and focus the camera. Same mindset for screen captures--don't just sit the "camera" on a tripod and shoot the whole landscape.

Wow, makes me want to wear my director's beret. Hoping for cooler weather soon.

Bandwidth and Information

I decided recently that I had "stopped growing musically." You have to be a Catholic flower child from the 60s to inflict that kind of guilt and deprecation on yourself over what is meant to be a hobby--something you do for fun.

(not from the 60s, but you get the picture)

So I hit upon a plan. I found this great dobro player, Martin Gross, who has a terrific YouTube channel. So my plan is to learn one song of his every month. OK, all happy again now that I am "working" at having fun.

As I've been working on "Blues Stay Away from Me" I've made a couple of observations.

The old way of learning a song was to play it on the record player and keep hacking away at it until you figured out how the person was playing it. Essentially, not much has changed except that with YouTube you get the video channel as well as the audio. And honestly, that makes it easier, but not in proportion to the orders of magnitude increase in information that the video makes available. Anyone who's worked on televisions is well aware of the difference in bandwidth between the video signal and the audio. There's just a lot more information in the video signal, and Mother Nature is an exacting accountant (the cost for transmitting information is bandwidth--the more information you are hauling, the wider the highway has to be).

Seriously, if you had to choose between learning a song by just listening to it without seeing the video, or watching it without hearing the audio, you'd be much better off just listening.

Kind of ironic seeing that the video has a ton more information in it. So what gives?

Well, most of the visual information is irrelevant. The color of the guitar, the spacing between the strings, the freckles on Martin's hand, etc. The most important information is what fret he is putting the slide on and what strings he is plucking. Since this is not a split-screen video, those two pieces of information are at opposite ends of the display and it takes a bit of replay sometimes to figure out what he's doing.

It might be true that a picture is worth a thousand words, but apparently a K of sound is worth a Meg of video.

About this time you're checking the header of this blog, thinking it was supposed to be about user experience and user assistance stuff. Well, it made me think about screen cam versus written procedures. Does the same thing apply here?

I think it does. I've felt for a long time that if the only thing we have to say is click this and type that, then a video is not the way to go (and a LOT of software videos are of that variety). Lot of bandwidth for just a little information. I wonder if Tufte's concept of chart junk and data to ink ratio can be applied to useful info/bandwidth analysis. Things like tone and physical manipulation in motion seem to justify the kind of bandwidth that video carries. I don't think of this is as a transmission efficiency issue, no more than Tufte was trying to save ink costs. The human bandwidth and ability to focus is more at issue here.

Plus, it's easier to scan a written procedure to get to that snippet of information I need than it is with a video.

So the point is twofold:

• Written words are still an incredibly efficient channel for conveying information. Quit beating yourself (or others) up if you consider yourself a writer and that to be your primary channel. "I am technical writer, hear me roar."
• If you can afford to throw a video or two into the user assistance, do something worthy with that bandwidth.
  

First Eyes and Last Eyes

Anyone who is a technical communicator gets involved in reviews, either doing them or getting them. There is an enormous difference in the appropriate level of feedback to give depending on whether you are being asked to look at an initial version (first eyes) or the almost ready for prime time version (last eyes).

Quick example, if I am doing a first eyes review and the document contains the word "utilize" I recommend that the writer say "use." If I am in a last eyes review and the document contains the word "utilize" I make sure it is spelled correctly, or appropriately for British vs US audience.

That example is a bit simplistic, but you get the point. First eyes reviews should look at larger issues and should invite new perspectives, as in "Have you considered taking this other approach?" Last eyes don't add a lot of value with suggestions that essentially would change the scope or direction of a document or user interface right before launch.

In a similar vein, when I submit academic research articles for peer review, I'm always amused by the peer reviewer who suggests that I use a different sampling method or change my interview protocol. Thanks, I'll just hop in my time machine and redo the study. Reviews that suggest different ways to analyze or interpret the data are much more useful. The ones I love most are the ones who help me articulate my points more clearly. Now if I were in a conference room with these folks planning my research, I would have entirely different expectations.

I'm currently wrapping up a project at work where I have been taking a manual written by a partner and basically rebranding and modifying content to reflect how we have implemented their product in our solution. This is very close to a last eyes review (given project time and resource constraints) and I have to be careful not to get out of scope and start rewriting one author's (and company's) style to match mine. It's not always easy. I can make small changes, such as changing "wish" to "want" (translates a LOT differently in certain languages) but I have to ignore some annoying rhetorical differences in how they treat procedures and how we do. (Can you say "doubles the scope?")

Some technical writers balk at this and say it's a question of quality: "I just can't lower my standards." I don't think these writers understand the business of writing, nor are they particularly skilled at critical thinking. By critical thinking I mean being able to discriminate between what is important and what isn't. Running to the high ground of quality sometimes just puts our heads in the clouds.

When asked to review a document or a user interface, we should ask ourselves are we in a first eyes review or a last eyes review. If first eyes, then our review should be critical and ask questions that challenge what could be wrong assumptions ingrained in the entire approach, a la "Is this really the optimal workflow for adding a new user?" Last eyes should assume for better or worse the work represents what the author or designer is trying to do and just make sure that distracting glitches are caught and removed, a la "Password is misspelled."

BTW, the more you treat last eyes reviews like first eyes reviews, the less likely it becomes that you will be invited to do first eyes reviews. Ironic but true.

Sexy vs. Usable

Whenever I get stumped on a UI, I ask is it a design issue or am I just being stupid? And as I have publicly pointed out in this blog, sometimes I'm just stupid. Got stumped on this one for awhile this morning:


BTW, very pretty dialog box. But the install button was disabled and I couldn't figure out why. Thought something might still be loading in the background so I waited. Finally figured out it was waiting on me...to accept the terms of the license agreement.

I don't think I was stupid on this one. I wasn't seeing the gray box to accept the terms, nor did its label catch my attention alerting me I had an action to complete.

If I could redesign this, I would make the check box white (nothing says empty as well as white) and I'd add a tad of space between the box/label and the paragraph above it.

And I mean it, it is a pretty dialog box, and I should know, I stared at it for thirty seconds.

User Adoption: A War with Two Fronts

I know, I ride Rogers' old horse beyond its intended range, but it just stays a useful model for a lot of what I do.

We can identify a point in an acceptance life-cycle with a vertical bar perpendicular to the x axis and somewhere along it. Then essentially we can say that we've got the population to the left of that line on board, and the ones to the right are the resistors we are still trying to win over. So the traditional model in my mind has been "resistance lines up on the right."

But I'm becoming increasingly aware of a negative image to that model, where resistance lines up on the left. Innovators and early adopters will resist efforts to lower the entry threshhold to a technology, preferring to keep the club exclusive. "We had to learn it the hard way, so should they." Or "If you make it too easy, then anyone will be able to [do my job][look as smart as me]."

There are so many examples that I am embarrassed it took me this long to notice it to where I could articulate it. Linux/Unix "We don't need no stinkin' GUI" VCR vs. film, digital camera vs. film, sites like this one vs. hard coding HTML.

This means any user adoption campaign is essentially a war waged on two fronts: Trying to entice the later adopters to come on board while battling resistance from the early adopters to anything that makes it easy for them.

I suspect this problem is most pronounced in non-profit and governmental organizations that are not as driven by the economics of user adoption as commercial enterprises are. I also suspect it is higher in technology communities. No data, just hunches.

Sounds like a good conversation for over beers after your next professional association meeting. Do me a favor and save the napkins for me.

New Menu Idea

Just helped a coworker figure out how to reopen his style and formatting palette in Word. He had shut it down because it was getting in his way, and then he needed it back.

That happens to me a lot. It's gotten to the point that I am so reluctant to turn anything off because I'm afraid I'll never figure out how to reactivate it. Well, every problem is the seed for an innovation!



Hey, I want credit if Microsoft uses this!

Yes, Virginia, there are stupid users.

I just didn't think my wife was sounding diligent enough about looking out for the UPS delivery guy, so I decided to work from home this afternoon so I knew someone would be here to accept delivery of the new guitar.

As I was working in my loft, I periodically checked the UPS tracking site to see if the status changed to indicate it had actually been dispatched. The current status message was a bit vague.

I hit refresh (for the 30th time in 30 minutes) and sure enough the status changed--to Delivered!! That got me a bit anxious, as in "TO WHOM--NOT ME!!!" It said "Garage."

I panicked. They delivered my Mike Auldridge guitar to a garage!!! Then I wondered something, so I went downstairs and opened the door to my garage.

What do you know. A guitar. So much for Mr. Eagle Eye.

I am like so old school

You might remember a blog I did last year about how not to update your look and feel. Essentially it says not to let old people (moi) design anything you want to appeal to the up and coming set of users.

I navigated to one of my old familiar sites and it has gone through a revamping by someone who certainly took my advice:


If you are over 60 (doh! moi again) give yourself about 5 minutes to figure out where to log in. Yes I know it says in BIG letters LOGIN and has a BIGASS button that says LOG IN.

It also has smudges for input fields.

I'm not complaining, "Brave new world that has such creatures in it" and all-- just saying I'm feeling like I'm a kazillion years old.

Maybe it needs a Help file that says "Type your password in the Password smudge." That would help geezers like me.

Mother and baby doing fine

I feel like I'm sending out a birth notice. This afternoon, Mike Auldridge inspected the latest batch of his MA-6 resophonic guitars (his signature guitar made by Paul Beard Guitars). I'm buying one directly through Mike. After checking them out (he still personally inspects all of his signature guitars) I'm told he said, "This one sounds just like mine," and then he set it aside for me.

Wow!

UPS says it will be here Thursday. Someone's not sleeping for the next couple of nights.

Put Personas to Work

Read my column this month in UXmatters; Personas as User Assistance and Navigation.

Requirements vs. Constraints

I love "x" graphs, you know, the ones that show one domain diminishing while another is increasing. They form an x, and the point of intersection represents a sweet spot or break-even point. These days, I feel like I'm living the one shown below:

The more feature-rich a particular design approach is, the more it delights product management. Of course, that starts to overload available engineering resources which drives their delight down. Being a UX designer puts one in this position a lot. On the one hand, you want the product or service to be a differentiator in the market place, one that carries a lot of delight to the customer. On the other hand, it has to be build-able within the constraints of the organization's resources.

So you look for that acceptable area of compromise, somewhere close to the intersection of the two lines. Something achievable that represents enough delight to be a package you can take to market. You end up playing devil's advocate at times, pushing back on product management and goading engineering to stretch. You need to be sensitive to when to back off and say, "OK, I hear you, let me see how I can make the design accommodate that."

In the end, you have to have both sides at the table at the same time, otherwise you find yourself in a series of no-win situations where you are the bearer of the bad news (the areas shown in gray). It also helps the spirit of compromise if each side can be connected to the other's point of pain. Engineering is more willing to bend when they deal with Product Management directly, and Product Management is more willing to compromise when Engineering says "Our schema can't accommodate that kind of a query." Also, each side can hammer out alternatives a lot more efficiently when talking to one another. I'm always impressed how creative engineers can be if you share the problem with them instead of insisting on a particular solution.

This could be one of the most important skill sets a UX designer develops, the arbiter of user requirements and product constraints.

Thanks to TTU

I spent last Thursday immersed with the students and faculty of Texas Tech's online Technical Communication and Rhetoric (TCR) PhD program. Actually, it all started on Wednesday evening with a delightful dinner at Dr. Tommy Barker's home. Tommy is head of STC's Academic SIG and Director of Technical Communication at TTU. Texas-style, nothing was done small or half way. Tommy had even procured a Dobro for me to use so we could do some bluegrass/rock-a-billy picking after dinner. Tommy played a mean acustic guitar and fellow faculty member Ken Baake joined us on banjo. For those in need of a scary thought to haunt you through the day, I have two words: PhDs yodeling.

Thursday morning I listened to doctoral students talk about their research projects, and I gave a keynote talk during lunch on the role of PhDs as practitioners. I spent the afternoon with Dr. Joyce Locke Carter, the Director of Graduate Studies in TCR, sitting in her usability class and touring their usability and multimedia facilities. That evening the students invited me to a barbecue.

I feel like I have seen the future of technical communication, and we are in good hands. The students were engaged in exciting research projects and projected more energy than I have encountered in a long time. The quality of the program is impressive, from the faculty--which reads like a list of academic Who's Who in technical communication--to the caliber of the graduate students (the TCR program accepts only 20% of its applicants).

The students work online most of the year, but spend two weeks working through an intensive "boot-camp" style program every summer. What I find most impressive about the program is the community of scholars this is developing for our field. TTU has worked out an effective formula for combining distance learning with face-to-face networking. And because these students have become accustomed to collaborating online, they will stay connected and influencing each other for the rest of their careers.

Congratulations to TTU for an excellent program, and thanks for the hospitality. That, and a hearty i-e-o-d-lady-hoo.