Energy in; energy out

OK, be prepared for Dante's 6th inner ring of metaphor Hell.

I broke down and took a by-gawd Dobro lesson this week. I figure it's time to get serious about my music so I paid this guy $100 for a three-hour Vulcan mind-meld of Musical Theory 101. Never touched my guitar. (He got interrupted, though, so I did get to play his $5000 Dobro for about 20 minutes while he handled a domestic emergency.)

So I go home with his two-sided yellow legal page on which he had scribbled the sacred code that explained the chromatic scale, all of the keys, and the how to construct every major, minor, and dominant chord. I was overwhelmed and stunned. Had I just gotten the deal of a lifetime or did I just flush five Andrew Jacksons down the toilet?

The next day I pick up my Dobro and start experimenting with the different patterns of the chromatic scale notes on the fretboard and playing around with the chord construction schemes he had taught me. It got interesting when I started playing around with a G9, one of the dominants. It was a different sound and I started putting a bit of a riff around it and pretty soon was playing a jaunty little latin-sounding thing I ended up calling "Tijuana Roller Coaster" because it had an unbalanced feel caused by the G9 and then resolved nicely to a slide up into the 1st inversion of the root chord (C) with a pause and then a final C note on the bass-most string.

OK, a little of that intro is just me showing off the new stuff I learned--but heck, I paid a hundred bucks to be able to write that paragraph, and it's my blog so humor me.

But it reminded me of the importance of grounding the energy out of a system. I used to be an electronics technician, and one of the electrical components we dealt with was the capacitor. A capacitor stores energy, and after you take one out of a circuit it can still give you a bit of a shock if you don't short the two terminals and get rid of the charge. If it has a big charge stored, you might have to do that a couple of times.

I've noticed that a lot of music does a similar thing. Notice how many symphonies end with a big chord that the orchestra repeats a couple of times? Ta Dah!.. dah...dah. Well, it's like the symphony has the musicians and the audience all worked up and the composer is trying to ground them at the end. Leave them someplace comfortable. And as much as I hate the practice of rock musicians trashing their instruments and amps at the end of a performance, I understand that they are trying to ground all of that energy so the performance leaves them and the audience back at sea level and not soaring up in the clouds.

So my slide to the root chord was to ground the listener, get him or her back to a safe place. But a 1st inversion chord is still a tad unsettling. A root chord is like having three singers harmonizing with the notes do, mi, sol, respectively. The first inversion would have them sing mi, sol, do with do being sung as the highest note. Still safe and stable, just a wee bit top heavy because the root note is on top instead of at the bottom. So that's why I throw in the root C on the bass-most string at the end, sort of like the second touching of the capacitor to fully discharge the energy. It kind of simulates what happens when a roller coaster stops; it leaves you leaning slightly forward in your seat from your forward momentum for a second, and then you settle back comfortably into the seat. Ta dah! ...dah.

Working with teams has a similar requirement, every now and then you have to ground the energy and bring everybody back into a safe comfort zone. Steven Wright has the line, "You know how you feel when you're leaning back in a chair and then you start to tip backwards? I feel that way all the time." Team work involves a lot of energy as new questions disrupt old, comfortable theories, agendas collide, etc. Periodically you need to ground the team--nobody wants to feel like they're tipping backwards in the chair all the time.

So how do you ground team energy?

In music we emphasize root chords and root notes. Playing in the key of C? End on C, E, G. Safe, predictable, comfortable. Working on a team? Get back to basic assumptions around which the team members can feel safe and comfortable. Weekly summaries are great grounders. Here's what we did this week and what we learned. Chronological descriptions of what happened or what happens are great grounders. Can we all agree that we saw A happen and then B? This is one of the reasons usability tests are great team builders, the team has equal access to the same data: what they saw the users do. As a test facilitator, when teams would start getting edgy over a point and I wanted to ground them, I would get consensus on the sequence of events. "Did the user click Add first or did he type the variable name first?" Direct observations are a safe common ground around which a team can safely discuss and agree on basics.

Other grounders are getting team members to agree again on the high level goals of the project or restating the criteria by which we accept or reject design decisions. C, E, G.

But... There is always a big but...sometimes you need to put energy into the team. The whole reason I like Tijuana Roller Coaster is that it starts on a G9, the musical equivalent to leaning back in your chair right at the tipping point. You energize a team by pulling them out of their safe, comfortable places. As you could well imagine, there are good ways to do this and bad.

When dealing with conflicts (the ultimate energizers), avoid dis-chord, i.e., out and out wrong notes being put together. Emphasize constructive tension. (A G9 introduces constructive tension into a song in the key of C.) Look at the differences in these statements in terms of dis-chord vs constructive tension:

• You're wrong.
• I disagree with you.
• I have a different perspective.

The last one is the rhetorical equivalent to a G9. It gets the tune going and you sure can't leave it there, but it's a pleasant enough tension. The first statement is fingernails on a chalk board.

Enough. The point I wanted to explore is the creative management of energy, when to infuse it and when to dissipate it. I can't wait to see what my next Dobro lesson brings.

Talk Your Walk

I know the title of today's blog seems backwards, but that's the point I want to make. It is not at all unusual to find situations where a person says one thing and does another. In Action Science, that is called a gap between a person's stated beliefs and their theories in use. In common practice we say that someone isn't "walking the talk" with the implication that the problem is in the walk.

Sometimes that's true, but often the reverse could be true, we're walking a particular walk because it works for us and it is the talk that is out of place. Action Science recognizes that and spends as much energy trying to align the message with the reality as it does on adjusting the practice to the preaching.

For example, if you ask writers how to write, they often say, "I start by making an outline." I taught technical writing and I often said "I start by making an outline." Most writers don't actually do that and if you corner them they will say things like, "I really should but..." Maybe, but the alternative is to just quit saying "I start by making an outline." In my case, for instance, I often just start writing. That's my way of exploring the content space. My friend and mentor, Carol Barnum, often says "Writing is thinking." So I start by writing, which gets me thinking about content, theme, and sequence. Interestingly, when I'm about a third of the way into an article, I turn on Outline view in Word and view only headings 1, 2, and 3. It lets me see where the flow is wrong or the appropriate ideas are not getting grouped.

I'm not saying that's the right way to write, but I have been successful with it so I need to quit telling people "I start by making an outline." I need to say, "I just dive in initially as a way of dumping what I already know and getting a feel for the content."

We confuse people when there is a disconnect between our stated beliefs and our theories in use. When managers say they demand teamwork but evaluate employees based on individual accomplishments, they do a disservice to the person who puts the team's overall needs ahead of his or her specific goals. That person gets punished for believing what the boss said and acting on it. The same applies to spouses, kids, friends, and all.

But don't be so quick to blame the disconnect on your behavior--It could be you are reciting scripts that describe what you think you should do. Actions speak loudly, and we are getting something that works for us from our behaviors or else we would have abandoned them (compulsive behavior aside).

So there is absolutely nothing wrong with the following talk:

• I start writing by just letting the firing of every synapse go to my fingers and then I organize and clean it up later.
• Although I value teamwork, I will evaluate each employee on his or her individual achievements first. It's my job as manager to make sure that your individual goals add up to a team achievement.
• We are not all equal here, I am more mindful of engineers' time than writers' time. That's just the reality of it.
• I'm going to ask if these jeans look good on me because I'm feeling fat, but I'm just fishing for some positive stroking.

It's kind of like using turn signals when you drive. It's easier for others to avoid hitting you if you share where you're going.

Moron Holes

My buddy, Miranda, is a gamer, and she showed me a new one that allows the participant to shoot a hole into a wall that sort of bypasses normal space and time limits and lets the player emerge, for example, on the the other side of an otherwise uncrossable chasm. Cool.

I think a similar device explains how some people can jump from assumption A to a logically inaccessible conclusion B--they're traveling through moron holes.

Classical logicians were unfamiliar with quantum concepts such as wormholes, so they had to explain such leaps from A to B with phrases such as non-sequitor or post hoc ergo propter hoc, without any explanation about how the speaker had accomplished such a feat.

No longer. We now have a scientific explanation: The speaker fell through a moron hole.

So at your next meeting when the project manager suggests that the doc can be ready on the same day coding the UI is done, you can glibly reply, "What moron hole did you fall through?"

Uh, bring cookies to the status meeting.

Screen Shots in Documentation

Sometimes someone gives me documentation that "so and so" put together for his IT group that tells them how to install our product. Generally, the purpose is to show me how "real users" want to see documentation. Invariably it is a 32-step procedure with a screen shot in every step.

Well, obviously, the writer in not familiar with Robert Horn or the demands for accessibility and globalization that I must deal with, so I have dismissed it.

But it just keeps coming back, so I'm going to ask myself, "What if they're right?"

First, so I can be more open to new thinking, let me purge myself of all the reasons I have traditionally rejected screen shots in documentation:

1. Every time the UI gets modified, screen shots must get updated.
2. Every time the UI gets translated, new screen shots must be generated in the new language and coordinated into the translated text.
3. Information in the screen shot (like button selection or entries) must be documented in the steps anyway so the information can be rendered by adaptive technologies like screen readers.
4. Many screen shots just show the reader what the user is already seeing.
5. Users may be overly attracted to the visual and miss important points in the explanatory text.
6. It makes the document bigger.

Now let me changes hats a bit a take a critical look at my traditional positions.

Objection 1 (updating screen shots) seems writer-centric. Essentially it is saying "It makes my job harder." Well if it does make the user's job easier, it would make sense that it makes my job harder--nothing's free. OK, Objection 1 is bad.

Objection 2 (translation) is just an instantiation of Objection 1. Therefore, Objection 2 is bad.

Hmmmm, I don't like how this is going so far :-(

Objection 3 (information still has to exist in words) has some substance. Information in a screen shot cannot be used to substitute for information in the steps. Unless of course, you're not worried about accessibility. Now that's an entirely different blog!

Objection 4 (what good is a picture of what the user can clearly see) has always resonated with me. Here is an example:

This example is particularly problematic for me since the UI text is actually pretty explanatory.

It also can get fairly tedious. consider the next steps that follow the example above:


But it seems that this by-the-numbers, picture-by-picture aspect is the attraction for this type of documentation. As in "So easy a..." well you get the picture.


So am I hearing from users who want this type of documentation, or am I hearing from technicians who think users need this level of hand-holding?


Objection 5 (visually distracts from useful text) has merit. Although it's true that a picture is worth a thousand words, it did take seven words to express that concept, and I'm not sure how you would get that across as well in a picture. Also, I think it is easier to wrap context around an example if the example is in words. For example, in the following shot, is the value 10240 an example or is it the value the user should enter?


And in the next example, the screen shot visually contradicts the step.


Objection 6 (document size) should be evaluated based on the merit of the document. If the screen shots make the document better, no one will care about bigger.

So where does this leave me?

I am going to be more open to including screen shots where they do the following:

• Help reassure the user that where they are in the UI is the right place to be
• Help call attention to a specific area of a complex UI
• Support an example that is hard to visualize otherwise, e.g., setting up a desktop configuration
  

So where they add value, I'll be more willing to tackle those aspects that make my job harder (e.g., documentation maintenance). But just as I would with words, I'll cut out the obvious and whatever does not add value. I prefer an additive approach (put it in only when the words seem inadequate) over a subtractive approach (take it out if it seems superfluous). In other words, I'll be more open to screen shots in the future, but they have to work themselves into the document, not just be their by entitlement until expelled.

State of the Ark (part 2)

As I said in an earlier blog, "state of the ark" is my phrase for when I think I am on the leading edge of technology when in fact I'm back among the late majority or laggards.

One of the problems with playing a Dobro all by yourself is that the instrument is really suited to provide accents and solo snippets. But I'd look a bit stupid standing in my den tapping my foot doing nothing then occasionally playing a "twinky twang."

So I thought I should get some bluegrass CDs so I could get used to playing in the context of a band. If you need a visualization, see this classic Andy Kaufmann bit from SNL.

I decided to go to Amazon.com to look at what was available. I thought to myself, "Wouldn't it be cool if when you bought albums online, you could actually hear bits of each track?" What a great, innovative idea. I could get RICH!!!!!


So, how long has Amazon been doing that, and why haven't I taken advantage of it before?

We probably don't think of music clips as user assistance, but this feature helped me make an informed choice (Patty Loveless, Mountain Soul II), and that's the ultimate goal of UA.

Job well done, Amazon.

New Media: Transparency vs TMI

A couple of interesting web sites hit my radar today:

This one is an article about some thrashing at the New York Times and the Washington Post about what staffers can appropriately blog and tweet about:
http://www.niemanlab.org/2009/09/is-transparency-the-new-objectivity-2-visions-of-journos-on-social-media/

This site links to 100 organizational policies on social media:
http://socialmediagovernance.com/policies.php

As a blogger and tweeter, I worry a bit about if I ever cross the line of "what happens at work stays at work" (or my other life--STC--where we have a strong code of "the board speaks with one voice").

I often blog about projects at work or insights I have gained from my interactions with fellow workers. And recently, I blogged about the internal debate I have had with myself over some STC issues.

The issue is when does transparency become TMI (too much information)?

On one side, I am a trained and committed Action Scientist who holds that ideas and assertions get better and more accurate when subjected to public scrutiny. In short, thinking stupid thoughts in private won't make you any smarter, but sharing those stupid thoughts lets you benefit from feedback--and you thereby get smarter. (Apologies to Chris Argyris for that over-simplification)

On the other side, companies need to keep proprietary discussions private, and colleagues need to be able to express themselves frankly without fear of having their personal positions show up in someone's blog.

Lacking a well thought out philosophy, I have jotted down the following principles for myself.

• Never put anything in a tweet/blog that could strengthen your company's competitors.
• Never put anything in a tweet/blog that would embarrass a colleague.

I also stay mindful of the following hierarchy of risk (from lowest to highest):

1. Reporting facts--The main risk in reporting facts is that you must make sure the facts have been released for public consumption. For example, it is low risk for me to say in a blog that STC has a task force looking at certification. However, it would be risky to talk about a decision we have made but have not communicated.
   
2. Illuminating the issues (identifying pros and cons)--I think this is the safest and most responsible space for thought leaders. Using the certification example again, it would be useful to articulate what are the issues around certification, helping readers make more informed decisions on their own.
   
3. Advocating a position--Advocating a position has higher risks in so far as you might be in public disagreement with a standing policy or with another colleague. That's not necessarily bad. Action Science holds that we worry too much about avoiding conflict rather that opening up the deliberation for public scrutiny and feedback. Still, it needs to be handled with tact and respect for others' positions.
   
4. Attacking a position --Same caveats as above, and this one carries higher political risk if you are attacking an official position of your company or association. For example, if I started a series of blogs and articles attacking DITA, I would soon run afoul of IBM's goal to promote DITA. (I'm a big fan of DITA, by the way, but it provides a good example.)
   
5. Attacking a person--Always a bad idea. I've learned as a blogger and public speaker that if I need a butt for a joke, it needs to be me.
   

So in short, I think it is OK to openly discuss current topics that are still in the formative stage and it is OK to attack legacy positions whose founders are long forgotten. It's not so good to attack positions that have recently been made (if you have any association with the organization or person who has taken that position).

And when advocating a position, maintain enough public humility so that you can gracefully support the opposition should you lose the debate. By the way, a useful pattern is "Yes, I had concerns over certain issues, but I think so and so has addressed those concerns and will be sensitive to them should they arise."

The Deployment Project: Defining the Deliverables

I had the kickoff meeting yesterday with my multi-disciplinary team working on the Deployment project. As project leader, one of the first things I have tried to do is define the deliverables we will create as a result of this project. By the way, this is no small task, we have been wrestling with this as a UX department for some time now.

As preparation, I established a team Wiki in our Lotus Connections site. The thing to remember about a Wiki is "Build it and they will ho-hum." So you really need to hold meetings periodically where the Wiki is the visual tool. So I used the Wiki to collect my own thoughts, provide background info, and to present a table of the recommended deliverables. I then opened it up in edit mode during the meeting so we could incorporate team thoughts in real time. BTW, that is a trick I have learned from two colleagues who use it well (Miranda Bennett and Christie Davis), that is, use the work product and edit it in real time during the meeting. Two advantages come from this:

• You don't need to take detailed notes and then write them up after the meeting (not to mention the additional task of implementing them)
  
• You get immediate feedback about the change, as in, "Oh no, that's not what I meant."

Part of the preparation I did for the deliverables exercise was to review IBM's recommended design artifacts (from a couple of IBM sources), some of my own work on use cases, and the artifacts from a process ISS adopted about four years ago--Rapid Contextual Design. This background gave the team a box of tools so to speak to choose from.

At any rate, we have decided that we will produce the following artifacts as our design package:

• User roles and profiles
• Use case diagram
• Use cases
• Product vision (a visual/narrative representation of design ideas that emerge from our user interviews, interpretation sessions, and affinity analysis that are part of our Rapid Contextual Design process)
  
• Conceptual wire frames
• Scenarios (like use cases but more contextual and UI-specific)
  
• Deployment Guide
  
• Service Requirements Document (SRD)

The Deployment Guide will actually describe current state. This allows us to address a present gap in user documentation (I'm all about early wins that the internal client will value) while letting us hitch-hike on the user analysis and use case work the Information Developers will do as part of developing this document. It will also establish the infrastructure and information architecture that will support the future design.

The Service Requirements Document is a new deliverable we have not done before and one that was suggested during the kickoff meeting. (We have product requirement documents, but it has been my experience over several companies that PRDs come from product marketing and lack a user experience focus.) Since we have developers on the team, we can collectively define a document that puts our research and conceptual design recommendations into a format that can be easily consumed by those who must develop the design. We have long wrestled with how much detail should a design document have and how much leeway should the developers have as they work in "rubber meets the road" land. This aspect of the project could become the most exciting for me.

An interesting outcome of the meeting was the decision to remove the Due Date column from the project plan. Huh? I've argued for that for a long time--See my blog You Can't Handle the Truth. But as soon as I was made the project manager for this, wham, I was thinking dates. Part of the problem--as it was pointed out to me--was that the deliverbles would happen iteratively, for example, some use cases early, others later, etc. The other problem is that we are largely in discovery mode and must be open to follow the data when and where it takes us.

OK, no dates.

Instead, as we identify activities, I am assigning an owner and asking that person to start maintaining the Wiki page(s) that tracks activities and progress for that activity. We'll see how that goes.