Happy Friday!

A couple of days ago, I read a great article by Jared Spool over at Johnny Holland titled “The Hands vs. The Brains”.  It hit a personal cord with me after my last full time position at an agency before becoming a full time consultant.

The gist of the article centers on distinguishing the differences between being a ‘hands-on’ contractor and a ‘brains-on’ consultant, so to speak.  Depending on the need of the organization and/or project, you do a lot of hands on work if your role is to deliver artifacts for team consumption.  Likewise, if folks need your confidence, experience and insight into users and best practices, and how that direction could influence great work, you’re role is more along the lines of leadership and management.

Where it gets interesting, and where I struggled (and assume others have as well) is making the transition from ‘hand work’ to ‘brain work’ in your career, or even trying to do both at the same time on the job.  Ultimately, Jared posits that you’ll always fall back to your ‘hand work’ over time, no matter what your role requires of your ‘brain work’:

Brainwork, on the other hand, is where your expertise and experience come into play. If the team doesn’t know what a wireframe is or how to decide what they should do, they’ll want someone who can give them solid advice. It they’re smart, they’ll be selective about who they hire, looking for someone with a track record of helping other teams in comparable situations, and they’ll pay top dollar for their help.

Maybe the team’s leadership is mistaken and they shouldn’t be doing wireframes at all? Well, someone hired to do brain work will have earned the respect and authority to say, “You know, there’s a better way to do this” and the team will listen. (Occasionally, they’ll even revise their plans, but that’s another column for another day.)

However, if that same person was hired to do handwork, there’s no way the leadership will pay attention. It’s wasted breath (or worse, seen as belligerence that may result in removal from the project). Handwork is hired for hands, not brains. Please keep your brains to yourself.

This has been my experience, especially if you’re looked as a ‘resource’… someone who is added to projects to provide deliverables rather than leadership.  If you’re positioned for your ‘brain work’, you’re at the project table from the very beginning, rather than at a project kickoff.

Part of this also deals with how your market yourself, and what activities you engage in both at work and outside of it.   For example, I may be the Director of Professional Development for the Usability Professionals Association, but I’ve been Project Managing our recent UPA Redesign effort since last year.  It’s been a hefty combination of communication management and producing documentation to help guide the process along (RFP’s, Resource Documents, etc.), and it’s been 90% ‘hand work’ and only minor ‘brain work’.

Dan Szuc, our VP, is on the opposite side of the coin.  He contributes strategic ideas and concepts, but doesn’t claim responsibility for the ‘how’, or ‘hand work’ to get it done.  His gifts are seeing the bigger picture and the paths to get to ‘there’.  On the web, he promotes himself vigorously in this regard.

I’m looking forward to the upcoming articles on Johnny Holland that go more into depth on the “Brains” versus the “Hands”.  I’m even more curious how others knew when they had finally made the transition from the latter to the former, and what tipped them off.

By the way, are you comfortable being a ‘Hands’ or ‘Brains’ person?  Do you have any desire to change?

I recently learned that our agency has been working on redoing their website for roughly two years.

That’s just insane.  No one works on something for two years… unless you’re a novelist, or managing a political campaign for the US House of Representatives.

Since we don’t write novels, or plan for running for office anytime soon, I think we’re insane.

Overall, the effort suffers from restarts in concepts, people heading the charge leaving or getting fired, and just a general lack of real ownership.  To give a proper background to the story, here’s what happened at the beginning of the year.

The creative concept chosen for the new website was one that had the backing of the execs (after a group creative session to vet out the entire creative teams’ ideas), and was quite simple.  A single sentence with hyperlinked words, each pointing to a different part of the site.

When the new project manager came on board in March, it was immediately taken to task.  The problem was, the project manager didn’t understand the associations between the hyperlink labels and the content underneath.  Because of this, an internal discussion was started and prolonged about how to best approach having a common, understandable nomenclature for the infrastructure.  Real work crept up, and the project was delayed.  A few months later, the project manager bolted for greener pastures.

At this point, I was fed up.  I had spent over two months doing a ton of discovery work on the project (competitive audit, two card sorts for the information architecture, two sitemaps, six versions of a prototype, and on and on..) back in December of last year, and nothing was leveraged by either the Creative team, or the project manager.  While that could certainly be my fault in retrospect for not educating others on its worth, there’s a work culture at the agency to put the blinders on, and crank something out to get it out the door.

Last week, I went to the CEO, and made the case that I should lead the charge.  If our Account Managers got a hold of this and tried to make an official project out of it, it was dead from the start.  The effort needed to live incognito, where effort could be managed between employees as a pet project I would have ownership of.

I set out having 15 minute ‘couch’ conversations with an art director, a copywriter, the original designer of the last concept, a developer and our Dev manager, on their thoughts to date about the corporate website project effort.  The important thing to do during this process was to do a lot of listening, and when appropriate, promoting the notion that the effort would be a collaborative effort with a project structure.

Fast forward to this afternoon, where I discovered that one of our Senior Art Directors also harbored the same frustration as I did.  Two hours of effort later, we worked out an alternative concept, a tentative sitemap, and updated our analytics code to better track our current website… all without a formal process.

That’s stealth.

Now, it’s messy, not as efficient, and might be politically problematic if some senior folks feel left out (i.e. the ego doesn’t get massaged appropriately), but it has to happen when something is taking TWO YEARS to get done.

I’ll post more as things transpire next week.  Until then, I’m off to celebrate Durga Puja. :)

- Robert

Today we had a client meeting with a fairly up-and-coming restaurant chain.  Our charge was to deliver wireframes and concepts, in an attempt to showcase our thinking and ideas, and to ultimately set direction on the project.

What ended up happening was an evisceration of the creative team by the client, because the concepts and deliverables didn’t match the ‘experience’ the client had in their head.  They weren’t so concerned about the functionality, assuming it would fall in-line with other restaurants in the same vertical.  What was missed was this unique experience they envisioned.

Two problems:

  1. The client and our account manager representive both espoused on the ‘experience’ and how ‘users’ would use the site.  While both have valid opinions, neither of them is versed enough in the discipline to speak to it with any authority beyond their own perspective.
  2. Expectations were clearly not set with the client.  The entire meeting felt like a meat-grinder, and now we’re up against a fairly un-realistic delivery schedule to turn over something that won’t meet that initial expectation.

What I wish would have happened:

  • Account management allowed UX to get involved early in the discovery AND interaction with the client.  There’s a very unhealthy notion that communication should be controlled by one group to the client for scales of efficiency.  The problem with that is clear… you hedge gaps in understanding and the risk that associates itself with that dynamic.
  • Wireframes were never introduced to the client.
  • We had a group exploratory exercise on the ‘experience’ they envisioned.  We wasted the hours of six creatives coming up with concepts that ultimately meant nothing, and at best could be Frankensteined for parts of inpsiration.

Very frustating to deal with PM’s try to dictate design, and not facilitate proper communication.

Per some very good advice, I’ll start keeping track of my activities in relation to starting up a volunteer chapter for the Usability Professionals Association in Seattle, Washington.

Here’s what’s been going on so far:

  • Started out trying to create a chapter in March, 2007.  I thought getting everyone in a room and starting a chapter would work, but people were looking for leadership, activities, events… basically a reason to join and get involved.
  • Took a hiatus and came back with an event called ‘Table-4-Eight’, taken from UPA Spain.  I’ll write about that in a different post.
  • Continued T48′s and held a UPA Workshop on user experience disciplines, with the original idea credited to Emma Rose from AnthroTech.
  • A poll on Doodle to figure out a time/date to have a UPA Chapter formation event.  So far it looks like two days, one in July and one in August, would work well.

Now, I just have to figure out how to promote this blog.  I haven’t done any promotion at all in the past.  If you do happen to stumble upon this blog, please post some pointers up.

My current stakeholders are fascinated and intrigued by adding features to their websites, without fully knowing whether or not they’ll be fully accepted by the audience we’re preparing them for.

It’s a calculated gamble.

If a competitor has an existing feature that our company wants to copy, the justification for doing so is that it exists, not whether the user needs or wants it.  But rather, to maintain a competitive advantage.

That’s when I thought of ‘feature depreciation’.  Everything that we purchase usually has a half-life to it, either in the usefulness or relevancy of the item we’ve purchased, or the value others put towards it.

In terms of web site features, there are some that depreciate to a great degree because users don’t care or never asked for the feature.  Other users will see the addition as a sort of ‘catching up’ item to common themes amongst online businesses in the same competitive space.  Whatever the outcome, it’s worth being mindful of this depreciation factor.

Think of the amount of time, manpower and resources a company puts towards a widget.  Smarter companies will take the time to invest in R&D to make sure they’re getting as close as possible to something that ultimately monitizes the bottom line and keeps the company going along.  Those that have the ‘belief’ that a widget will succeed because ‘everyone else is doing it’, or has limited research around the general concepts or execution of the widget, falls into a greater depreciation scale.

Unfortunately, it’s a lesson that isn’t easily learned, as post-analysis or retrospection is almost never given any weight.  The business focus is almost always on progress and growth, and never learning from the past as much as possible beyond tribal knowledge sharing.

What do you think?

Part of my job as a Lead Information Architect, though its more of an assumption on my part, is fostering communication.

My deliverables are dependent on other things besides requirements and process.  I need to know that all stakeholders, users, project team members and executives are heard and are being actively listened to.  Within all of those voices, different connections and parallels can be made on what aspects or goals are the most desirable for several different, though disparate groups.

The more ongoing dialog I have to foster ideas and maintain focus.  The better my own work will be in the long run.

Do you agree with this?

How to you ensure that your recommendations in a usability presentation or report are effective?

I just finished reading a Journal of Usability Studies paper by Molich, Jeffries and Dumas titled “Making Usability Recommendations Useful and Usable”.  The direct link to the PDF is here:

http://www.upassoc.org/upa_publications/jus/2007august/useful-usable.pdf

While some part of the article is lengthy and tiring to labor through, the final takeaways from their work distilled down to these recommendations:

  •  Communicate each recommendation clearly at the conceptual level.
  • Ensure that the recommendation improves the overall usability of the application.
  • Be aware of the business or technical constraints.
  • Show respect for the product team’s constraints.
  • Solve the whole problem, not just a special case.
  • Make recommendations specific and clear.
  • Avoid vagueness by including specific examples in your recommendations.

How many of you follow the above in your own work?  I’ve usually covered about half of these, since time and resource constraints don’t allow for expanded analysis that the article recommends.

I’ve been listening to a great podcast Luke Wroblewski, the Senior Principal of Product Ideation and Design at Yahoo, Inc., about ‘Getting Unstuck’, and moving past blocks in process and design work, whether political or practical.

The panel goes over a wide variety of topics, and offers a ton of advice on looking at the design process with different perspectives.  I highly encourage anyone interested inspired to learn about leveraging options when it comes to working out problems with executives, management, teams or individuals on a design project.

Landing page with explanation and audio download links:

http://www.lukew.com/ff/entry.asp?569

Enjoy!

This probably goes without saying, and I’m sure it’s been quoted many times in various books and research papers, but:

There must be a point in someone’s life where the race to make more money is trumped by the need to make better use of one’s time.

When you first join the workforce in whatever capacity you find or need, you’re usually trying to make as much money as possible.  Money gets you access to things you can play with, utilize, give to others, etc.  Once you accumulate enough experience and connections over time, and as responsibilities play a greater role in your life, the emphasis shifts.

The older you become, the more you try to make time count, perhaps even attempting to be more efficient at regular chores and responsibilities.   You might adopt a GTD (Getting Things Done) lifestyle, or start looking for ways to balance your work and home life for greater harmony.

Does this resonate with anyone?

How many of you regularly read (and by regular, I mean once or twice a week) research-related materials related to the user experience? Also, do you try and utilize some of the lessons learned in those materials to bring value to your work?

I feel alone in this regard. I usually continue to try and seek points of reference on my own UX work, and how others see the same problems I encounter on projects. Yet, I wonder if I’m in the minority, outside of those working on thesis papers or do research for a living.

If you’re a UX professional, do you spend part of your spare time attempting to learn more about your craft through trade publications like Forrester, E-Marketer, etc., or read related books on information architecture, usability, etc.?

Furthermore, do you see value in engaging in such activities?

Follow

Get every new post delivered to your Inbox.