jump to navigation

Help! I need somebody… March 8, 2012

Posted by dantemurphy in building a team.
add a comment

The Beatles "Help!" album

My company, Digitas Health, is looking for some help.

We need an entry-level Interaction Designer/IA/UX to work on a platform project for a key global client.  The successful candidate will be trained on iRise, a state-of-the-art prototyping and specification tool.  This is a great opportunity for an energetic, talented, and passionate designer.  Full job description below.  If you are interested in working in our Philadelphia office, contact me directly or leave a comment below.

JOB TITLE:  Interaction Designer

DEPARTMENT:  Creative Services


The Interaction Designer works closely with clients and agency team to intimately understand user needs, advocate these needs throughout the project development cycle. The methods and tools used to provide this support and advocacy include:

  • developing functional design documents and iRise prototypes (iRise visualization software training is provided with this position)
  • planning and performing user research
  • executing usability testing

Additionally, the Interaction Designer acts as a strategic partner within the agency, supporting ideation activities and creating infographics for projects and prospective new business.


  • Create and present user experience solutions to internal teams and clients through sitemaps, wireframes, iRise prototypes, flowcharts and functional specifications.
  • Identify user needs, values, and mental models and develop representative profiles or personas.
  • Quickly understand and refine client strategy and develop content and functionality that meets both client objectives and user goals.
  • Collaborate closely with copywriters, visual designers, and programmers to design the user interaction model, information architecture, and user interfaces.


  • Bachelor’s degree required; any of the following areas strongly preferred: HCI, Interaction Design, Industrial Design, Computer Science, Media Studies, and/or Graphic Design.
  • 1-3 years of experience developing interactive web sites and applications as information architect or interaction designer.
  • A good understanding of user-centered design principles. Must be able to demonstrate an understanding of interaction design process and skills.
  • Ability to provide interaction-design and usability insights on projects.
  • Experience on site development projects, developing sitemaps, wireframes, flowcharts and functional specifications.
  • Experience with user experience research, both to uncover user needs and to test interaction design solutions.
  • Experience interacting with marketing, research and technical clients.
  • Understand how to use and effectively incorporate interactive technologies.
  • Expert knowledge of MS Office and Visio or other design software.
  • Working understanding of interactive front-end technologies (i.e. HTML, JavaScript, Flash, CSS, DHTML), browser and platform constraints.
  • Good understanding of common back-end technologies and platforms.
  • Pharmaceutical and Healthcare industry experience a plus.
  • Prior experience in an integrated marketing communications agency desired.
  • Uncompromising attention to detail.

Note: This job specification should not be construed to imply that these requirements are the exclusive standards of the position. Performs other duties (or functions) as assigned.


Mosh Pit Memoirs October 10, 2011

Posted by dantemurphy in Uncategorized.
Tags: , , ,
add a comment

OK, it’s been a while since I’ve posted anything, and it will probably be a while longer before I get another article together. So, in the meantime, here’s the soundtrack for my presentation at the 2011 Internet User Expereince conference in Ann Arbor entitled “Mosh Pit Memoirs“.


0. “Death Valley ’69” – Sonic Youth
1. “Repeater” – Fugazi
2. “I’m So Bored With The U.S.A.” – The Clash
3. “Question of Life” – Fishbone
4. “Sheena Is A Punk Rocker” – The Ramones
5. “Mine” – The Cows
6. “School” – Nirvana
7. “In The Meantime” – Helmet
8. “Diplomat” – The Aquanettas
9. “Someday I Suppose” – Mighty Mighty Bosstones
10. “Baby Sitter” – Joykiller
11. “End Of The Universe” – Screaming Trees

If you’re in Michigan, come on by.

Be the “1” December 12, 2010

Posted by dantemurphy in building a team.
1 comment so far

I’ve always had an affinity for point guards.  You know, the guy on the basketball team who doesn’t look like he’s on the basketball team…short, wiry, quick.  And it’s not for the spectacular behind-the-back passes or the occasional three-point shot as time expires.  It’s because they represent the essence of the game; five guys, but only one ball.  Individual achievement is dependent on the contributions of the team…and it all starts with the “1”.

In basketball, each of the positions has both a number and a name.  The shooting guard is called the “2”. The power forward is the “4”, and the point guard is the “1”.  He’s the guy who handles the ball the most, not necessarily because he is the most proficient scorer, but because it’s his job to create opportunities for his teammates.  His accomplishments are measured in assists, when a pass from him results in a basket by a teammate.  It’s hard to do once.  The best do it 10 times a game.

So what does any of this have to do with UX? 


UX professionals, for the most part, are the darkly shaded area on a Venn diagram of technology, marketing, visual design, strategy, editorial, and research professionals.  Ours is the language of translation, enabling the capabilities of a technology to deliver meaningful content in an elegant presentation to the right audience in a way that drives revenue for the client.  On any given project, there might be eight or more disciplines contributing…and there’s still only one ball.  Somebody has to make it work.

There’s no formula to it, either.  Watch the great point guards of the game…Stockton, Magic, Nash, Kidd…they all had very different styles that were suited to the players around them.  And that’s the real point of this article; the way to be successful in a team environment is not to focus on the skills you have, but to use your skills to make the people around you successful.

Face it, the behind-the-back pass is no good if your teammate isn’t expecting it.  Some guys like to get the ball on their left, some prefer the right, some like to get a bounce pass while others prefer a lob.  In basketball, it’s all about knowing the skills and preferences of your team within the context of the play.

In the UX world, it’s less about the back-screen and the pick-and-roll than it is about understanding the way each collaborators skill contributes to the experience.  It’s important to use your skills and experience to make the technology meaningful, the content accessible, the campaign valuable…without impeding the progress of your teammates with stifling best practices and limiting design principles.  Too sharp a focus on the integrity and quality of your own work can work against you.

We talk a lot about things like mental models and influence maps, but we often do a poor job of abiding our own advice.  We argue with the creative director about whether a facebook page is what the customer really wants, or bicker with the copy supervisor about how many levels there are in the content hierarchy.  We may be right; we often are.  But it doesn’t matter, and it won’t make your project successful to alienate yourself and your practice from the other guys on the team.  Just like a point guard, you can only influence the play if you have the ball and your teammates know what you’re going to do with it.

When we look at the best teams, whether it’s on the basketball court or in the world of product and service design, it all seems to work so seamlessly that we often attribute the success to the role our discipline plays.  Ask someone in the biz what makes IDEO successful, and their answer will tell you a lot about what they do for a living; an industrial designer might say that the integration of form and prototyping into the design process is the key, while a technologist might say that including tech in discovery is the secret ingredient that makes the sauce.

The reality is that the secret ingredient isn’t much of a secret at all.  It’s the dedication of each person to the success of the team, the willingness to align with the unifying philosophy, do the grunt work, and most of all put the success of others ahead of your own.  And the easiest way to make it happen is to focus not on assignments, but on opportunities.

For a while, this might feel like compromise, but it’s really a process of learning how to make the most of overlapping and evolving capabilities.  As you dedicate your skills to the success of your teammate, not only do you build trust, you also teach her how to work with you.  When she faces a challenge for which she doesn’t have the answer, she’ll look to you for help and guidance.  This is your opportunity to exert more influence, or to try something new.  The good news, you won’t be going it alone.

Just this week one of my teammates thanked me for including him in a research project.  The fact is, there’s no way the project would have been successful without his input.  Even though I was in the leadership role, I owed my thanks to him for his execution and enthusiasm.  All I had to do was to call the play and pass him the ball.  So, for their role in making the project wildly successful…and for helping me to articulate this metaphor…I say thanks to my team.

Thanks Andrew and Keith and Chris and Michael.  Let’s run it again.  Who’s got winners?

By Any Other Name August 19, 2010

Posted by dantemurphy in building a team.

Oh, how I am sick of the “you’re not a designer” crapola.  It’s a poisonous debate, one that so often divides people who should feel unified along positional statements and anecdotal experiences.

So why am I feeding this beast?

Because it’s a windmill, and I’m feeling Quixotic.

Like many of you, I’ve gone by a wide variety of titles doing essentially the same thing.  My first job in UX wasn’t really a job in UX at all, that was just the way I approached it.  Back then, I called myself a programmer.

As time wore on I was writing fewer programs and doing more analysis of data and creation of reports.  I was an analyst…but not the kind with a couch in his office.

Then came the web.  Thanks to Al Gore, I now spent a lot of time writing code, but not the kind that did anything; this code just put stuff on a page where people could see it, and maybe click on a link.  Suddenly I was…a programmer again.

It was around this time that the “polar bear book” came out, and I realized that I was an information architect.  Who knew?  I asked my boss if I could write a new job description and create a new title to match.  It was a watershed moment.  Since that moment 12 years ago, I’ve never had a job description I didn’t write myself.

In the intervening years I’ve considerably honed my craft, adding a broader understanding of design principles and business objectives.  I’ve had the opportunity to manage others who did the same thing I do.  And I’ve added an important skillset; research.

In fact, these days I probably generate more revenue for my company as a result of my research methodologies and activities than I do from making wireframes and site maps.  And in the midst of yet another dust-up over “what is a designer”, this realization caused me to question whether I really am a designer…or something MORE.

That’s right, interaction designers, the world doesn’t begin and end with us.

The good news is that most of us realize that.  We know that there are others who contribute specialized skills to the problems we solve and the products we make.  Whether we’re working with a visual designer, a software engineer, or a marketing guru, we understand and respect the input of those disciplines.

The skills these specialists perform may even be part of our repertoire, but there’s a difference.  As interaction designers, our focus is on crafting interactions that will result in an optimized experience for the user of our product or service.  We may apply typography or coding skill or an understanding of the competitive landscape, but our framing is all about interactions.

When we think more about the domain than the skills, the Venn diagram of overlapping disciplines makes a lot more sense.  Visual designers are focused on aesthetic, creating beauty or evoking a specific mood, even if they might use the same design principles I do when I create a wireframe.

Nobody owns a skill.  If you want to take ballet classes to become a better football player, do it.  Just don’t call yourself a dancer if your job is to score touchdowns.  And more importantly, don’t tell the left tackle on the team that he’s not a football player because he doesn’t know how to plie

This is where we so often go off the rails, telling other people what they are or are not based upon the skills we use.  It’s like saying that a person born halfway around the world isn’t really a person at all because he doesn’t speak the same language.  A person who doesn’t sketch, doesn’t write code, and can’t moderate a usability test is still an interaction designer if that’s the problem space he works in.

This is not to say that you have to hire him to work on your team.  Matching skills is important within a team or company as a means of managing expectations and mapping capabilities to career paths.  There are some who believe they have the magic formula for the work they do, and if the results bear it out, that’s great.  But it’s not the only way to skin a cat.

My preference is to focus more on the kinds of problems my team can solve than on their preferred tools and methods.  If most of the team uses Visio to create documents but one designer uses InDesign, that’s fine with me…as long as that person can train the rest of us to be at least conversant in that tool.  By hiring and training for diversity of skills and approaches, the aggregate capabilities of my team are always growing.

As a result, we’ve gone beyond the title of “interaction designer”.  Our problem domain is “user experience”, and the broad disciplines we apply to that problem space are research, design, and development.  As a result, our titling structure has three elements:

  • Level: from Associate to SVP, this represents an individual’s overall level of skill and experience in the UX field
  • Domain: this part is the same for all of us, and it’s the name of our department—User Experience
  • Practice: this represents the disciplines in which the practitioner is most skilled—research, design, or development

So a person on my team might have the title: Director | User Experience | Research and Design.

The key to this structure is that anyone can have more than one discipline in his title, and there’s no need for permanence.  A designer now can be a researcher in the future, just as I went from being a programmer (twice!) to being a designer and researcher today.

There’s an additional skill, too.  I call it “leadership”.  It can be an expertise in a specific discipline, like a principal, it can map to people-management, or it can map to the expansion of opportunity through business development, evangelism, and advocacy.

On my team, we don’t have a 4-skill person.  Honestly, I don’t see the need.  The nature of our work allows us to collaborate, share, and grow; nobody needs to be the whole show.  There are limits to how far a person will go on just one or two skills, of course, but if you have a team of passionate and smart people (which I am fortunate to have) they will keep growing and learning, whether within the bounds of a skill or into new areas.  The key is to make sure that everyone has at least one pathway for growth.

So this is my affirmative statement of self.

I am a designer.

I am a researcher.

I am a leader.

What are you?

I Give Good Panel August 5, 2010

Posted by dantemurphy in facilitation, presentations, Uncategorized.
add a comment
Eye of the Storm eyetracking panel

Facilitating the panel at IUE '10

I’m just back from the 6th annual Internet User Experience conference in Ann Arbor.  It was a nice regional conference, and I gained some valuable insights, including this one about myself:

I give good panel.

Let me explain.


A couple months ago I participated in a panel on the use of eye-tracking in usability and user research at the UPA International Conference in Munich. Feedback on the panel was mixed; some of the presenters were very dry and academic, while others were exploring a niche so narrow that audience members struggled to relate. There was also a problem with the format of the panel. Each panelist gave a short presentation on their research, but because there were six of us, we had to rush like mad to describe our work in only seven minutes and we still took up more than half of the 90-minute panel with prepared slides. Questions were deferred until after the last presenter, by which time the topic of the first was mostly forgotten.

panelists at UPA

When the feedback forms were collected, I was very pleased that some of the most favorable comments related to my presentation and my interaction with the audience. I think this was because I described a methodology rather than a specific study, pitching the benefits but leaving room for debate and further explanation. It wasn’t much different from some of the participatory design workshops I’ve done, where a scenario and a solution are presented to a group of experts to solicit their reactions.

A-HA! I think I might be on to something….

SS,DD (Same Subject, Different Delivery)

Following the UPA panel, I was asked by the sponsor if I would moderate a similar panel at a regional conference. Despite some of the frustrations of the panel in Munich, I enjoyed being a part of the discussion, and this would be an opportunity to work with some of my fellow panelists again as well as some other experts on the subject. It would also be an opportunity to change the format from a series of talking heads to something more harmonious with my personality, something like a cross-breed of the Meet the Press and Coney Island.


The first and most obvious step was to eliminate the presentations. People attending a panel come with their own ideas and questions. Piling on a smorgasbord of slides is like bringing coals to Newcastle. Eliminating scripted presentations gives you a lot more time to work with, which means more people can participate and more topics can be explored.

Eliminating slide presentations opened the door for me to eliminate slides altogether. I considered allowing each panelist to create a single “introduction” slide, but then I thought about my favorite part of every conference I’ve ever attended…the parties, dinners, and receptions that happen after the projector bulbs go dark. Nobody brings a slide deck to introduce himself, and business cards don’t usually come out until a rapport is established. Instead of slides, I decided on a flip-chart where each panelist could put their twitter handle or email address. This way audience members could get to know each panelist not by what they say about themselves, but by what they say.


On the same flip-chart, I outlined the format for the discussion. The formula looked like this:


…which stands for:

Question+Answer+Argue+Digress+Pontificate+Argue some more…

Writing down the format or rules of engagement is helpful when a discussion begins to take on a life of its own…and not in a good way, sort of like Kiefer Sutherland in “The Lost Boys”.

“I’m sorry, Dave, but we’ve already pontificated. It’s time to argue some more.”
“You’re skipping ahead to digress, Karen. We haven’t argued yet.”

It sounds cheeky, but it works.


The next thing to do is to encourage the audience to participate. In Ann Arbor, I used ducks.

It doesn’t really matter what you use. The idea is to give audience members a tangible marker of their participation. When they see that others have something and they do not, even the most reticent wallflower will feel an increased urge to participate. There’s one more thing you’ll want to have on hand before you begin, and that’s a list of scripted questions to use in case discussion stalls. You can create this on your own based on an understanding of the subject, or you can solicit topics from your panelists. Just make sure that the questions or topics are provocative; too basic a question deflates the intensity of the session, and too specific a question alienates a lot of the audience.


Once the room is full and people have started to find their seats on their own, it’s time to start the session. Call the meeting to order using whatever attention-getting devices you have (flicking the lights, air horn, fan dance) and welcome the audience. Introduce the topic first, then yourself. Then introduce your panelists in the order they are seated; this will help audience members who may not know everyone to remember names. Addressing each other by name keeps the conversation fluid; nobody is struggling with recall or the formalized sentence structure that comes with not knowing that Steve is, well, “Steve”.

Now the fun begins.


No matter what kind of presentation I’m doing, I love to start with a quick bodystorm. I got the idea from the session on Agile Interaction Design at the first IxDA conference; it was a great way to get a sense of the attitudes and expertise of your audience, and it also creates a more “kinetic” environment. If your physical space allows for it, try to include the panel members; even though they are aligned on a topic, it is interesting to see how they rate in comparison to the audience. Once you get a read on the crowd, invite everyone to take their seats and start the discussion.

Opening bodystorm at the IUE panel

Opening bodystorm at the IUE panel


If your topic is fairly broad or you’re confident that your audience understands the problem space, jump right into taking questions from the audience. If the audience is a chorus of crickets, then go to your list; pick something juicy to get the ball rolling. Look for cues of interest or a desire to answer from your panelists, and invite one to respond by name. Try to make sure that you get at least two panelists to respond to any question or comment before turning back to the audience, but be cautious of letting the panelists get stale agreeing with each other or dividing on an issue. Once you have a couple of viable points of conversation, redirect to the audience.

When you cast your attention back to the audience, try to be specific about what you’re seeking response to. If there’s a divisive issue, take a straw poll or choose a person to ask their feedback. Refer to your notes (you are taking notes, aren’t you?) for points previously made that are relevant. In short, edit the story on the fly.

That’s what it really comes down to, in the end. People remember stories, not experiences, and the extent to which you can call upon your understanding of the subject and all your research-facilitation mojo to synthesize the experience in real time into a meaningful narrative, the more memorable and therefore valuable it will be.

Oh, and the ducks are a pretty good mnemonic too.

What has been your favorite…or least favorite…panel experience? Please share your comments.

Other People’s Underpants July 21, 2010

Posted by dantemurphy in tools and methods, Uncategorized.

To my sometimes peculiar way of thinking, User Experience documentation is a lot like underpants. You can create an application or website without it, just like you can “go commando” or do your best Jean Harlow impersonation. It’s faster (less to put on), cheaper (less to buy and launder), and there’s a certain “pioneer spirit” that you only get with an unfinished basement. And sometimes there’s a downside…which I won’t bother to describe, because nobody needs to spend the rest of their day thinking about THAT.

True as all that may be, this article isn’t really about underpants, or the risks of going native. It’s about what happens when you inherit someone else’s documentation.

So why does this make me think of underpants?

Recently I inherited a simple site map from someone who was just trying to get ahead of the game, not a UX professional but a smart cookie who did a respectable job of organizing and representing the content and linking strategy. She asked me to look it over, and even though it wasn’t done the way I would have done it, it didn’t really need to be changed much, so I kept my edits minimal.

I didn’t bother to put in a detailed title block.

If something wasn’t aligned to a grid, I left it alone.

And all the while, I felt like I was wearing someone else’s underpants.

At first I thought it might be because I don’t really do site maps that often; most of the work I’ve done over the last two years has either been research or large-scale strategy work.

Maybe I was just a little hurt that someone who wasn’t a UX professional had done a good job, marginalizing the talents of my team.

Of course, it could just be that I have an obsessive compulsive disorder when it comes to site maps.

The reality is that it was probably a combination of those things, plus one more. An important one, it turns out, as I reflect on the project and how it evolved.

For me, and many other UX professionals, the documentation we create becomes our medium of expression. The decisions we make about the radius of our corners, the pattern of our dashed lines, the font of our title block, those are neither uniform nor arbitrary. When we use color, we do so thoughtfully. Gradients and fill patterns are pondered, tried, rejected.

The project progressed, and in deference to a tight budget I continued to avoid non-critical changes to the site map. Until today.

At last, the scope of change was significant enough that I could justify a total re-do. It’s been ages since I felt so liberated, and it wasn’t until now that I felt truly connected to the project. Until today, it was someone else’s site; today it became mine.

Rectangles were grouped and aligned. Connection points became uniform. The garish gold was gone, the cross-links were given reduced emphasis, rules were used to convey line breaks. And as the ideas were translated into my visual language, the speed and engagement of my work increased exponentially. The mouse movements became more fluid and accurate. I was “in the zone”.

And I wasn’t wearing anyone else’s underpants.

The moral of the story is this: sometimes you have to take the time to make your work comfortable and personal to free your mind and hit your stride. Don’t let an artificial “efficiency” twist your knickers. Like Abraham Lincoln said, “Give me six hours to chop down a tree and I will spend the first four sharpening the axe.”

How about you? Spend any time in someone else’s underpants lately?

Embrace the Wrong April 19, 2010

Posted by dantemurphy in tools and methods.
add a comment

A UX Practitioner’s Guide to Satisficingembracing the wrong

Have you ever wondered why people do such stupid thing?  Why they ignore the obvious, cling to outmoded beliefs, and act contrary to their own best interest?  Maybe, as a way of coping with the inevitable tide of stupidity in our profession, you’ve developed a cheeky infographic that represents the various forms of stupidity you’ve battled.  I have, and it’s made me feel better…but only for a little while.

What I’ve learned, as my role has become more about partnerships and strategy, is that there’s a lot less stupid in the world than you think.  Consider the following:

  1. People are stupid 
  2. Sometimes smart people do stupid things
  3. People do things that I don’t completely understand

Now, I’m not going to try and convince you (or myself) that #1 is not true.  Some people are stupid.  But unless they’re also crazy, they usually do things for a reason.  Now, that reason might be stupid, but a lot of times the reason makes perfect sense based upon what the person knows or believes to be true.

Which brings us to #2.  Just so nobody feels like I’m picking on them, I’ll share something very stupid that I did to illustrate my point.  When I was in the 4th grade I started riding my bike to school.  My mom got me a padlock with a key and a chain so I could lock it up at the school.  As the weather got warmer I started wearing shorts to school, which had no pockets.  I didn’t want to lose the key to my bike lock…so I tied it to a string and tied the string to the bike.

It all made perfect sense.  I would never need the key except when I was at my bike, the string was tied on really well, and I didn’t have to fumble around in my backpack looking for the key under all of my books and lunch and other junk.

The good news is that whoever noticed the obvious flaw in my design only took the lock and key, and my lesson was learned.  Mom got me a combination lock, which solved all my problems.  (The combination was 3-1-4-1, or the first four digits of Pi.  I told you I wasn’t stupid!)

So what made my mom such a good designer?  She listened to my explanation of why I did what I did.  #3 was the key.

Admittedly, most of your clients and collaborators will be more than 9 years old, and the problems you’ll be asked to solve are probably more complex than how to lock up a bike when you don’t have any pockets.  But the tools for solving the problem are the same.

Assume that there is rational causality for all of the actions you observe.  Even when emotions are the root cause of an action, the resulting action is often based upon some logic.  The problem arises when your customer or collaborator is unable to articulate that logic.

There are a couple of things you can do about this.

The first is to determine whether educating your team is necessary.  Nobody likes a pedant, but it’s important for everyone on the team to have a shared baseline of understanding about both the problem and the proposed methods and tasks for solving it.  If your client doesn’t know what a card sort is, take the time to explain and demonstrate it in a way that is meaningful to them and to the project.

Demonstration is a great way to get buy-in on your ideas, whether they are solutions or methods for achieving them.  People believe what they see and experience for themselves because they are able to process and index the information in their own way.  When you only explain an idea or method, a translation between your mental model of the task and the listener’s is required…and often imperfectly captures the meaning.

Many times, you as the designer are not sure what is the right solution or methodology.  At least not right away.  But there you are, in front of your client, gobbling up budget while you try to figure out your next move.  Make the client part of your exploration.  It’s OK to not be sure of exactly what happens next; after all, that’s why the client hired you.  You just have to reassure your client that their time and money is well spent in learning and ideating.  As mentioned above, educate and demonstrate along the way, justifying your activities and theories as part of the design process.

A key element of each of these is the use of prototypes.  Knowing what to prototype and in what fidelity demonstrates tangible progress with an eye toward efficiency and speed.  Your prototypes doesn’t always have to be an element of your final product; in some cases, it makes sense to prototype a participatory design session to make sure you have the content, pacing, and staging right.

All of this presumes that you can “Right the Wrong” by being transparent, inclusive, and clear in your methods.  But the name of this article is “Embrace the Wrong”.  So let’s do that.

There are a handful of immovable wrongs that a designer will have to face in his career, and probably the most common is the client who asks you to design the wrong product.  They want an animated intro page when what they really need is a clear content strategy, or they want an iPhone app but they can’t tell you why.

If you have the luxury to walk away from this kind of work, do it.  There’s another designer out there who needs the work, and you don’t need the headache.  But few of us have that luxury.  Instead we need to do the best we can to help our clients achieve their business goals, even when the idea appears doomed from the start.

Once you realize that you can’t change you client’s mind about the product, stop trying.  Change your strategy from “no, but…” to “yes, and…”.  Make their idea the centerpiece of the project, but integrate the idea that is supported by your research, experience, and effort.  Use the animated intro to showcase the content strategy, or imbue that “me-too” iPhone app with an element of unexpected delight that differentiates it and makes it worth doing.

A related and nearly-as-common problem is the client who insists on a specific design or research methodology regardless of its appropriateness.  As long as they are committed to doing the activity, make the most of it…but no more.  Don’t try to learn everything you would have learned in a participatory design session when the client insists on doing focus groups; you’ll end up making assumptions instead of informed observations, and the product will likely suffer.

Instead, build certainty upon certainty.  Determine what you can learn from the activity and focus on learning it with maximum depth and clarity.  Everything you learn, you can use.  Achieve whatever economies you can, and see if you can divert any saved time and money into activities that bridge the gaps in knowledge left by the inappropriate methodology.  And if you can’t do that, take your best guess.

The last and most insipid wrong is the project aimed primarily at efficiency.  These projects are inherently wrong to the User Experience professional because they focus on cost reduction for the client rather than service to the customer.

The longshot in this race is to demonstrate a visionary concept that has a greater ROI than the projected cost savings of the efficiency-driven project.  Instead of cutting service to save operational costs during non-peak hours, a business might expand offerings that make the most of available infrastructure during non-peak hours, growing the overall business.  The reason this is a longshot is twofold; first, ideas that good don’t grow on trees, and second, many times the project is budgeted before the RFP goes out.

So let’s assume that we can’t change the wrong idea into the right one.  “Embrace the Wrong”, remember?  What you need to do is make sure that the efficiency-driven decisions your client is making are informed by indicative experiential KPIs.  If you can identify the key drivers of trial, satisfaction, and loyalty, defend and optimize those while letting what remains fall victim to the scythe.  Use competitive and heuristic analysis to determine service baselines and benchmarks.  Deconstruct the client’s service offering and let participatory design help you identify the elements that must be maintained or optimized.

Sometimes success is measured not by what you achieve, but by what you overcome.  When you can’t right the wrong, embrace it.

How to Get Hired March 10, 2010

Posted by dantemurphy in building a team.

I’ve been doing a fair amount of interviewing lately (business is good), and one thing I’ve observed is that many people do not do a very good job of selling themselves.  Since I would hate to miss out on a talented recruit, I’ve put together some simple things a candidate can do that I’ll remember…in a good way.  These aren’t the only things one should do to prepare for interview…with me or anyone else, for that matter…but I think they’re pretty essential.  I’d even dare to call them obvious…if more people did them, that is.

1. Take notes. And for God’s sake, bring your own paper and pen. (Bonus points if it’s a Livescribe.) Even if you have a photographic memory…or are wearing a wire…show me that you’re paying attention. This is especially relevant when you ask me a question, and I answer it. If you really cared what the answer was, wouldn’t you write it down?

2. Do your research. Tell me what you know about the company, the business, or the job. Unless a recruiter chloroformed you and brought you in with a bag over your head, you know the company and the job description, right? Tell me what it means to you, and why you’re interested. I promise to return the favor.

3. Converse. I don’t want a sales pitch, a stand-up routine, or 53 minutes of ass-kissing. I want to know who you are, what’s important and interesting and challenging to you. I want you to ask me “why”, to disagree with or challenge something I say…to have a PULSE. There’s a lot of work to do, and I would much rather do it with someone I like and respect than Billy Mays, Jerry Seinfeld, or Ed McMahon.

4. Draw something. Sure, your portfolio is fabulous (you did bring one, didn’t you?), but let’s see how you work. I don’t care what you draw, and there are no style points on a whiteboard. But until an idea is represented visually, it’s not tangible.

5. Follow up. A brief thanks is appreciated, but what really gets my attention is when someone says “I picked up that book you mentioned” or “here’s that article we talked about”. This is the kind of rapport I have with my colleagues…and you want to be one, don’t you?

Of course, you do still have to be smart, and passionate, and capable of doing the work…and if you are, these are the ways I’m going to get the whole picture…not by reading your resume. That only gets you in the door, it won’t be enough to keep you there.

Oh, and one last thing…which if you’re reading this blog, you already know. Stalk me. Not in the creepy park-a-van-across-the-street way, but online…check me out on LinkedIn, twitter, facebook, WordPress. If you got an interview, you can bet I did the same.

It’s In The Bag January 17, 2010

Posted by dantemurphy in design research, tools and methods.
1 comment so far

Over the last several months, I’ve done a lot of travel for work. I’m not quite in Jared Spool’s league yet, but recent assignments have taken me to Chicago, Atlanta, Los Angeles, Seattle, Sao Paulo (Brazil) and Tokyo (Japan). And the one constant on all those trips has been my bag.

My well-traveled bag, and a sampling of its contents

My well-traveled bag, and a sampling of its contents

It’s not so much the bag itself that I wan to talk about, although I am very fond of it, it’s more the idea of a designer’s bag having everything he needs in a simple, portable package, marrying the utility of Batman’s belt with the whimsy and magic of Felix the Cat’s bag of tricks.

Felix and his Bag of Tricks

Felix and his Bag of Tricks

The Cat and The Bat both always seem to pull out the one perfect tool for whatever their predicament, a clear sign of their fictitious roots. Today’s designer faces many challenges in his profession, often in a single day, so versatility and low weight are more valuable than bat-shaped grappling hooks.

The Batman Utility Belt

The Batman Utility Belt

First of all, I prefer a messenger-type bag to a backpack because it’s very easy to get stuff in and out even while you’re wearing it.  Mine has pouches and pockets a-plenty, great for keeping a camera, cell phone, note pad or umbrella at hand.  This is extremely important when doing ethnographic studies, especially covert ones, but it’s also helpful for those hallway conversation with a client that so often become the turning point of a project.

Whatever kind of bag you prefer, the most important thing is what’s in it when opportnuity and inspiration come calling.  Here’s what I carried on my travels, and a couple of quick notes about things I wish I had brought or left behind.

  • Netbook or other lightweight computer: Mine is an HP Mini, not a very powerful machine but since I mostly use a portable computer for writing and editing documents and presentations, I didn’t need to spend a lot of money (or weight) here.  I’m also more likely to bring it into “hostile environments” because it’s fairly easy to replace.  Wireless internet capability is essential, and you really need the laptop form-factor because not even the fastest thumb-typist in the world can effectively take notes on a mobile phone keypad.
  • USB thumb drives: I like to keep two, one that is the repository of all of my critical working documents, almost like a portable back-up memory for my hard-drive, and one that only has files on it I am wiling to share with a client.  This is really essential since my computer does not have a VGA port, so anytime I am unexpectedly pressed into presenting I am borrowing someone else’s machine.  (When I KNOW I am presenting, I bring a full-scale laptop.  And usually my own projector, power strip, and extension cord.  Semper paratus.)
  • Sketch book and notebook: I prefer to keep a separate sketch-book for drawings and quick compositions and use a steno pad for general notes and quick doodles.  The lined paper in the steno pad helps keep things orderly, but makes it hard to draw in perspective.  Whether you use two books or one, you’ll want to be able to do both notes and sketches.
  • Assorted, pens, pencils, and erasers: I’m old-school when it comes to pencils, prefering the variety of point profiles you can get with a wooden pencil over a mechanical one.  That means I have to carry a sharpener too.  And I like to bring a good eraser, whether to correct an errant line or just to clean up those inevitable smudges.  For pens, I always carry ball-point in blue, black, and red, plus a fine-point highlighter and a medium-point Sharpie.  The multiple colors are really helpful when you’re annotating a document, or when you have a variety of ideas that you want to group without re-copying the whole list.  And without sounding like too much of a shill, I’ve taken a Sharpie to hell and back and never had one leak or explode.
  • Livescribe pen: This gets its own line because it’s more than just a pen.  The built-in voice recorder is amazing, and the ability of the pen to synchronize your notes and sketches with the audio is very valuable when doing interviews or ethnography.  Add in the search functionality and the handwriting-to-text conversion, and you have a pocket-sized stenographer.  It means hauling around the proprietary notebook, but it’s worth every ounce.
  • Ruler or scale: If you’re doing product design, you may want to go for the scale, since physical dimensions in your sketches may need to be very precise.  But even for those who design in the digital medium, general scale and aspect ration are important.  And it never hurts to be able to draw a straight line when you need one.
  • Sticky notes: If I’m doing research, I always bring a variety of colors, usually as many as six, but for day-to-day use I generally just carry two pads, the standard 3″x3″ and the much-smaller, postage-stamp size that I generally use as bookmarks.
  • Camera: I like having a separate camera than the one in my phone for a couple reasons.  First, the image quality is much better.  Second, I find it is much easier to get images from my camera to a computer; for the phone, you either have to use e-mail, MMS, or the proprietary “desktop” software.  With the camera, it’s a cable and a click.  You can also deploy a camera much more quickly; on my phone, you have to unlock the device, then select the camera function, then wait while the software loads…it doesn’t sound like much, but five seconds is an ETERNITY in ethnography.
  • Business cards: Not only are these still an important tool for networking, but they are also helpful in establishing the legitimacy of on-site research.  Also, in some cultures, they are socially de rigeur.
  • Design book or magazine: Long ago I stopped counting the number of times a book or article I was reading became the key ingredient or turning point of a project.  Whatever you’re reading, bring it with you…a conversation will remind you of something, and you can quickly refer back and make your case with the supporting text and examples of the author.
  • Chargers and spare batteries: Day to day, you can get by with one or the other, but for long trips, bring both.  And make sure you have the right adapters for whatever country you are visiting.
  • The essentials: Of course you’ll also want to leave room for your mobile phone, tissues, clips, and pictures of your kids…you know, so you remember what they look like when you get back.  Because THAT would be embarassing!

I’ll never say I’ve lived a life without regret, and my bag is no exception.  Here are some things I wish I had, or could have easily done without.

  • Wireless card for laptop: I managed to get by on hotel wireless and the data plan for my phone, but it was a compromise.  One more promotion at work and I can get a company-sponsored card; until then, I’ll probably rough it.
  • Laptop with webcam: Mostly because I wanted to video chat with my kids, I hauled TWO laptops 26,000 miles, my HP Mini for its intergrated webcam and general portability and a larger machine for on-site design work.  Never again.
  • IDEO Method Cards: I didn’t bring them with me, but I wish I had.  Great value for their size, and even though I’ve probably done every method listed there’s no substitute for a well-organized library of tools.
  • Plastic bags: At the end of my travels my bag was a veritable ticker-tape parade of receipts mixed in with notes, business cards, tourist maps, and other bits of paper I can’t even identify.  Having a couple of empty freezer bags that I could easily label would have saved me a lot of sorting and guessing when I got home.  Also good for saving that half of a sandwich, in case you get hungry on the 13-hour flight from Hamburg to Tokyo.

I’m sure I’ll keep tinkering with the forumla, but that’s what’s in my design bag.

What’s in yours?

The Joy of Running (On) September 15, 2009

Posted by dantemurphy in tools and methods.
1 comment so far

When in the Course of human events, it becomes necessary for one people to dissolve the political bands which have connected them with another, and to assume among the powers of the earth, the separate and equal station to which the Laws of Nature and of Nature’s God entitle them, a decent respect to the opinions of mankind requires that they should declare the causes which impel them to the separation.

the joy of running_smallIn case you don’t recognize that, it’s the first sentence of the Declaration of Independence.  And it’s a WHOPPER.

Throughout our careers as professional communicators, we are consistently encouraged to be brief, concise, efficient.  But when you’re looking for a unifying statement to rally behind, whether as a mission statement of an enterprise strategy, nothing can top a well-crafted run-on.

Here’s an example, anonymized to protect the interests of the original client:

The proposed solution is…

…a common set of services and tools that provide services and information to customers in support of their business and patrons…
…and enhance their relationship with MANUCORP…
…available on each MANUCORP website focused on a specific product or category…

…accessible by mobile devices…
…whose content and services are organized according to their timeliness…
…supported by a customer profile which grows over time…

…informed by explicitly stated preferences, search terms entered and acted upon, and other online patterns of use…

…designed to provide increasingly personalized content and tools, based on the evolution of the customer profile…
…that may include information about the customer’s business, personal messages and alerts, and specified links to content and tools…

…which can be accessed through any participating product or category site.

OK, so you’d probably never say it out loud, and you would surely need cue cards if you tried.  But there were some very good reasons for cobbling together this grammatical Frankenstein, and the fact that these reasons keep coming up suggests that others might benefit from this insight.

So here you go.

A run-on sentence has a single subject.  Unlike a paragraph, which may dedicate a complete thought to each individual feature, or might speak on even terms about the research methodology, technology, and design, a run-on sentence speaks only of “it”…whatever “it” might be.  All of the detail in the run-on…and there’s quite a bit there, as you can see…is subservient to “it”.

Despite the presence of numerous verbs in subordinate clauses, a run-on sentence has only one predicate.  What this means is that the run-on has only one action, most often an assertive declaration that defines “it”.  Intransitive verbs work well, especially forms of “to be”, but you can also put together some pretty compelling active statements using verbs like “will prove”, “out-performs”, or “has requested”.

In a run-on sentence, there is only one tense.  No muddling the past and the future, there is only one focus.  When defining a problem or opportunity, the tense may be past or present; when describing a solution or strategy, present and future make the most sense.

Most importantly, a well-crafted run-on sentence (I can see the edges of my degree in English curl and fray as I write that) represents a quantized thought.  It may have many components or instantiations―in fact, it has to in order to earn its stripes as a run-on—but no piece can be taken out without impacting the integrity of the whole.  Its singularity confers cohesion; anyone who agrees with “part of that sentence” appears wishy-washy.  A run-on is the Texas Hold ‘Em of strategy statements; either you’re all in, or you’re out.

play like a champion_smallBy the time you present your run-on, you’ve carefully vetted each component and its contribution to the meaning or relevance of the whole.  Each direct object maps to an important feature or offering, and each indirect object represents a key audience or channel.  In fact, whether you present the run-on or not, it can unify your team .

Of course, not every run-on has to be a 129-word monstrosity.  Let’s call that, with a nod to Jared Spool, a run-on-and-on.  A simple run-on can be as short as this most recent example from my growing portfolio:

The vast supply of information tools and services does not meet the growing global demand, because the digital channel is underutilized and the content is not optimized for interaction and engagement.

More important than its length is the singularity of the run-on.  If you can represent your objective with a single, albeit complex, thought, then your path to resolution will be fast and direct.  And if your solution can be described with a single thought, consensus will prevail over the coalition-building that often hampers efforts that lack focus or suffer from competing agendas.

So next time you’re facing a large, complex problem—whether the source of that complexity is the size of the issue or the number of stakeholders —try piecing together your own run-on.    And if you do, please share it…maybe you’ll make the Run-On Hall of Fame!