I’ve struggled to communicate exactly what a User Experience Designer does.  User Experience is a relatively new field.  It borrows a lot of techniques from various long-established disciplines, but I don’t think there is any strong consensus on what a User Experience professional does, how they interact with other established parts of an organization and how to know if you’re a good one.  In this post, I synthesize some of the current thinking on what UX Designers are supposed to do (UXMatters.com), how they go about doing it (userfocus.co.uk), how they might be evaluated (Jared Spool, uie.com) , and present a framework for thinking about your User Experience practice.

The Bottom Line:  UX Designers/Developers need skills in 3 areas: Core UX Skills (User Research, Visual Design, Interaction Design, Implementation, Evaluation), Enterprise/Business Skills, and Foundational Skills.

UX Designer/Developer Core Competencies

User Experience Definition

Search for ‘user experience definition’ and you’ll get a lot of different answers.  You could do worse than the ISO 9241-11 definition:

‘…we define [user experience] as all aspects of the user’s experience when interacting with the product, service, environment or facility’ and we point out that ‘it is a consequence of the presentation, functionality, system performance, interactive behaviour, and assistive capabilities of the interactive system.

It includes all aspects of usability and desirability of a product, system or service from the user’s perspective’.

That’s a tall order for one person to fill.  In a company of any size, it is unlikely that one UX Designer will have complete influence over all aspects of the user experience.

UX Honeycomb. Peter Morville

So while I hold this definition as an ideal, and try to communicate it to others in my organization, I tend to focus my view and efforts to the electronic, web systems that I design and have direct influence over.

There are a couple pictures that I think sum up this view rather well.  The UX Honeycomb describes 7 facets of a good web user experience.

Dan’s visualization of UX at KickerStudio encapsulates the notion that UX is the space/cytoplasm that connects the various disciplines into a single organism.

User Experience Artifacts/Deliverables

What are user experience designers supposed to do?  I like the idea that UX designers bring compassion and empathy into product design.  They use structured methods to turn empathy into a design process that result in improved user experience.  David Travis breaks UX work into four categories: Analyze the Opportunity, Build the Context for Use, Create the User Experience, and Track Real-World Usage and Continuously Improve the Product (graphic).

A Model for User Experience. David Travis

What deliverables they bring to the table?  We use tools like stories, wireframes, tasks analysis, and prototypes Peter Morville gives a nice overivew of the UX Deliverables (along with an excellent graphical UX Deliverables Treasure Map).

With Agile development methods leading to shorter and shorter developmet cycles, some have suggested that UX Designers also need some development skills.  Being able to express designs with the same language and tools as used by the ‘backend’ development team certainly makes easier for the UX designer to integrate their work with the development team.  I agree with this view, to a certain extent.  I started my career as a developer, and I still do some coding.  I think this helps me communicate with my full-time developer colleagues.  But I also think that focusing on development can taint your design thinking.  When you’re in the weeds of writing code, and under a delivery deadline, it’s easy to cut corners on the design and say “this works…this is good enough.”

User Experience Core Competencies

In his Agile2009 Keynote, Jared Spool had a nice graphic of all the different disciplines the UX Designer/Developer dabbles in (I’m surprised the slides from this aren’t available anywhere).  I combined some of these ideas, some from Steve Psomas in UX Matters (linked above), and my own thoughts/experiences.

I would tend to group UX Competencies into three categories.  Let’s look at the picture again:

UX Designer/Developer Core Competencies

CORE UX SKILLS

This is your ability to turn your compassion and empathy into design artifacts and deliverables.  This is what people hire you to do.  I think this breaks down into 5 areas:

• User Research
• Visual Design
• Interaction Design
• Implementation
• Evaluation and Testing

The graphic gives some examples of the types of artifacts deliver and skills required in each of these areas.  These are obviously not complete lists.  In particular, take a look at the Implementation box.  To be a UX developer these days, you need to know something about the front end presentation (HTML, CSS), the ability to make the screens sing and dance (javascript, AJAX, or maybe Flash, Flex, or Silverlight).  You need to be able to persist the data, whether in a local database, key-value store or remote system.  You need to be able to glue those two together, either through some lower level server side programming with straight PHP, or some framework like Ruby on Rails, Django, or CodeIgniter.

ENTERPRISE/BUSINESS SKILLS

Enterprise and Business skills enable you to map your Core UX Skills onto the needs of your organization in order to deliver business value.  As Jared Spool explains:

User experience extends beyond the on-screen interactions to all touch points with the user. Special skills are needed to ensure the team interacts with the rest of the organization in a productive manner. While the teams don’t need to know how to do the jobs of others in the organizations, they need to know how those other roles will influence the design.

I organized some of these Enterprise/Business skills differently than Jared…more in a way that fits my experience I guess.  Where the Core UX Skills live almost exclusively in the UX World, the Enterprise/Business skills are about the connections, interfaces, and links between the UX practitioner and the organization.

FOUNDATIONAL SKILLS

The Foundational Skills are the theory, tools, and practices that help you critically evaluate new technologies, tools, or methodologies.  Design and Development practices seem to come and go almost daily.  Today we’re all talking about guerilla usability testing, paper prototyping, user stories.  A few years ago talking about Usability Engineering, Outside In Design and looking at UI UML modeling.  Before that, we were talking about User Centered Design and the need for full blown usability labs.  Tomorrow, we’ll be talking about something else.  It’s your Foundational Skills that help you step back and see the relationships between all these things.  Foundational Skills enhance your ability to ‘pick up’ the latest thing because you can relate it to something you already know.

Foundational Skills would grow both through formal academic training in fields like Ethnography, Psychology, Human Factors, Computer Science, Engineering.  Foundational Skills would also grow through real-world experience with people, organizations, technology, and systems.

User Experience Core Competencies Use Cases

Assessing Your Own Strengths/Weaknesses

A designer/developer might rate themselves on some scale, say 1-5, in each of the 7 areas, to clearly communicate the skills they bring to the team.  I could imagine some color coded version of this graphic, or even a treemap that emphasizes where one’s skillset lies.

Assessing Your Teams Strengths/Weaknesses

A UX team manager might assess their teams strengths along these dimensions, in order to identify team strengths, weaknesses, opportunities to pair people and do cross-traning, and guide hiring decisions.  This leads to…

Evaluating Job Candidates

Given that you’ve identified areas where you need additional skills, you can rate prospective hires in the 7 areas (or ask them to rate themselves).  You can give each area a weight in order to emphasize the balance of skills you’re looking for, and build a table that calculates a weighted score for each of the candidates.

Conclusion

There are many misconceptions about UX.  In many organizations I’ve worked or consulted for, UX design is treated like some magical black box — sprinkle some pixie dust on our servers and *poof* out comes a great UX.  Maybe this type of framework can help remove some of the mystery, and help us communicate generally what we do and how we do it.  It may also help you communicate your own strengths, skills, and contributions to the product team.

I showed this visualization to my boss at my performance evaluation this year, and said, “this is how I think about UX and the types of things I should be doing…here are the areas where I’m strong, and here are the areas where I’m looking to grow.”  I noticed he only marked up the areas where I’m weak.  =)  That’s ok, because 1) we have others on our team that are really good in areas that I’m weak, 2) we agreed on where I need to get more practice, and 3) it lets me be proactive in defining the UX world, and the value a UX Designer/Developer in general (and me specifically) brings to the team, and what things I should be doing.

I certainly welcome thoughts from the community.  Is this helpful?

I enjoyed reading  Sway: The Irresitable Pull of Irrational Behavior (Amazon , nice review).  There are many cognitive biases that affect how we think.  The authors did a nice job of distilling the research on cognitive bias into an accessible popular science book.  The book made me think about how I approach web design and evaluation.

Traditional usability testing has its roots in psychology research methods.  You spend lots of time designing the study — randomizing participants into experimental groups, ensuring you don’t ask leading or prompting questions, calculating statistical significance or confidence intervals of findings, etc — so that these cognitive biases are minimized or factored out.

Agile development typically feature 1-3 week sprints, forcing UX designers to shorten traditional evaluation methods, use guerrilla usability testing, or do whatever they can to get SOME user feedback in the time allotted.  UX designers have been actively discussing how to integrate UX design into agile development teams (or search for “agile ux“). But in speeding up design testing/evaluation, we may become more susceptible to allowing cognitive biases to creep into and taint our study results.

There are two biases in particular I think we need to watch out for.

Confirmation Bias

Confirmation bias is the tendency is a tendency to search for or interpret information in a way that confirms one’s preconceptions (Sciencedaily, or Nickerson 1998 if you’re more psychology-paper inclined).

Give me an example!

You’ve spent the last couple days iterating on an information architecture for a new site.  You’re doing a quick evaluation of a paper prototype with three users in three separate sessions, to determine if the latest iteration is the best.  You’re watching the users interact with the prototype, asking them to think out loud and asking open-ended questions to encourage them to talk.  However, you’ve invested time and effort in this latest prototype: the stakeholders have approved it, and you either really like it or are sick of it and want to move on to the next thing.  Confirmation bias might lead you to focus your questioning on behaviors that you expected to see, that confirm or validate your design, or discount some of the negative comments you hear.

Diagnosis Bias

Diagnosis bias is the tendency to label things based on our initial impressions, and our difficulty or inability to change our minds after that initial impression is made.

Give me an example!

You’re got some ideas for the next web2.0/cloud/service/mashup/[buzzword]*, and you’re doing user research to prioritize new feature development.  A study participant comes in and says, “I don’t know what browser I use…I just fire up AOL to get on the internet.”  Ouch, you think to yourself, how am I going to get any useful info from this yokel?  This diagnosis bias might make you miss that while they don’t do much at home, their online activity at work makes them a perfect candidate.

How do we avoid biases in Agile UX?

The Sway authors take a small stab at answering this question in the Epilogue of their book, but their answers are a bit simplistic.  I guess this is understandable.  Humans developed these biases because they help us solve problems related to surviving in an unstable outdoor environment, and to do so in nearly constant motion (Brain Rules).  Sometimes you need to make quick, simplifying judgments in order to survive or gain an advantage.  So clearly there is no turnkey, 3-step process for overcoming them.

Obviously there is a need to find an appropriate balance between experimental design rigor and doing the least amount of work to get the most value.

1. Be Aware of Cognitive Biases.
   You can’t do anything about it if you don’t know about them.  And you just read this post, so check this one off your list.
2. Make a List of Your Assumptions; Reevaluate Assumptions Across Sprints
   This is basically just trying to externalize your assumptions and biases.  If you can put them out there, and make plans to revisit them over time, it might be easier to catch when they have clouded your judgment.  Also, if you publicize your working assumptions it gives others a chance to critique them, or see if many people would draw the same conclusions.
3. Think About How to Disprove Your Assumptions, Rather Than How to Prove Them
   This goes back to your Research Methods class…it is difficult to objectively critique something if it is not falsifiable.  I’m not saying you have to set up your null hypothesis tests.  But you can change you design evaluation thinking from “how would I know this is good” to “how would I know if this is bad.”  Try to identify 3-4 ways that would indicate something is wrong.  If none of those things are evident, you’re more confident that you’re on the right track.

I really wish I had seen this before I collected 500 survey responses about our ordering system WITHOUT being able to connect them to an order number.  It turns out you can pass a custom value into the URL of a SurveyMonkey survey:

SurveyMonkey Help Center – Answers

To customize them, create a unique ID ending for each respondent by adding “&c=” at the end of the link followed by the ID number.

EX: &c=00001

http://www.surveymonkey.com/s.aspx?sm=v8MbvURxoHkWfvud7Or3Cg_3d_3d&c=00001

I had planned liveblog the Agile2009 sessions I attended, but ran into a couple roadblocks*.  You can see the Agile2009 sessions I DID blog.  Also, Jackson Fox went ahead and wrote a great recap from a UX perspective.  It might be more interesting for me to talk about how well I accomplished my goals for attending.

I had three goals for attending Agile2009:

1. Learn methods, tools, and best practices for improving my user experience (UX) research and design,
2. Help my department to adopt Agile practices in order to respond to increasingly demanding projects and shorter deadlines, and
3. Learn ways to more effectively team with colleagues in other parts of our organization to develop and deliver outstanding UX on our enterprise tools.

I was a blend of several of the conference personas: obviously Deanna the UI Designer, but I also felt some affinity for Carlos the Internal Coach, Peter the Programmer, Alex the Architect and David the Developer, even Tara the Tester.

Agile UX Research and Design

I’ve already blogged about some of the UX sessions I attended.  I would say that there were two broad categories of UX sessions (at least, that I attended): Agile UX methods and processes (guerilla user research, persona development, task analysis grids or storyboards) and experience reports (how do we do UX on an agile time schedule, with an agile development team).  The method and process talks were very high level — almost introductory, and I felt didn’t really have enough time to get into any kind of real discussion on how to really use these UX methods in real life, anymore than reading about the techniques on the web .  I did appreciate the 3 hr tutorials from Jeff Patton on Personas and Mike Cohn on User Stories.  Coming out of those, I felt like I got a bit of ‘meat,’ which I could chew on — they gave a good framework for how to think about using these tools, instead of just a technique.

From the experience reports, the main message I got was, “here’s what sort of worked for us…we had to be agile and learn, and this is what happened in our shop…good luck with yours.”  I had a hard time seeing how some of these were generalizable, or how I might use some of the lessons learned.  Clearly, everyone is feeling the time pressure for faster deliverables within Scrum sprits.  This means that UX practicioners have to be UX generalists: skilled in visual design, info architecture, interaction design, even development.  I think the best takeaway was just networking with the people giving and attending the sessions, and finding a community of people I could talk to about approaches I’m thinking about taking.

I was a bit saddened and disillusioned at the perceptible distance between the UX and Agile Development community.  The developers are still saying, “I’ve gotta get this code feature out the door, I’ll let you know when I need to talk to a designer), and the UX people are still asking, “how do I get the working respect and integration with the development team.”  One concrete example of this: Todd Warfel and others did a set of three sessions on the whole ‘Agile UX process: Performing User Research, Distilling and Communicating Research Results (mainly via personas, and finally developing wireframes.  I noted that the user research sesssion was sparsely attended and almost solely by UX people, the session on personas had a few more, and the session on wireframing was jam-packed.  I think this is another example of developers trying to see how to get straight to the design, even though designers know there’s a process involved in getting to the design.  Not sure how this dichotomy will play out.  I don’t think anyone does yet.

Overall, definitely a positive experience, though.  I was really impressed with the LiveAid stage…several UX designers did some agileux methods (guerilla user research, personas, wireframes), then teamed with several agile developers at the conference to create an iPhone app for a non-profit: http://www.manoamano.org.  In addition to raising nearly $5000 for the charity at the closing banquet, the exercise of doing UX research and design, development and shipping a live app in 3 days was inspiring.

Agile in our Department

At my company the webteam is undergoing a bit of an evolution, where are roles are changing from simply maintaining the public static websites to designing and developing some mission-critical web applications.  Our internal clients are asking our team to provide new (to our company) types of online interactivity and functionality, and the demand for us to be a mini-IT department are increasing.  What agile tools/options should we look at in order to keep with the demand and still deliver outstanding webapps?

One way I think we can improve is to better integrate unit testing, acceptance testing and continuous integration into our team workflow.  I went to a couple talks on CI – I think mostly by CI software vendors.

I went to a couple agile coaching sessions to get a sense for how to ramp up teams, and get people started doing things an ‘agile way.’  I was impressed by some of the coaching start up team strategies shared Lyssa Adkins. The session on user stories from Mike Cohn was again a great example of how to collect/gather/uncover requirements.  In the OpenJam, I poked my head in on some people review Kanban project management.

One takeaway here is that ‘agile software development’ is more of a mindset change.  It’s a set of principles, from which several methods, tools, and best practices have been developed.  But as warned on numerous occasions, just adopting some or all of the methods without understanding the principles often leads to poor results.  I think the key here is to focus on the core principles, and adopt the set of practices that make sense for your team wherever they’re at.  I like the idea of the Scrum style — setting a sprint timebox for a delivery of something of business value, and then meeting afterwards for a retrospecting and planning of the next sprint.  I’m planning on experimenting with a WIP board for a short sprint on a project this week.

Another takeaway is that, at the end of the day, all these agile documentation and project management methods and tools (user stories, personas, work in progress boards, pair programming, Scrum, Kanban, Blitz Planning) aren’t really rocket science.  They all center around creating externalized, shared visualizations of the problem and solution spaces.  The goal, it seems, is to extract the implicit knowledged wrapped up in each team members’ head as simply as possible, put them in a shared accessible place as simply as possible.  This allows the whole team to see the whole picture, and allows communication and ideas to flow as quickly as possible.  That’s why agile emphasizes small, co-located teams over large distributed teams — fewer barriers to communication.  That’s why agile emphasizes user stories on index cards, simple personas, and face to face communication over documentation — its easier to exchange ideas and information, to re-arrange and update the knowledge-base.  Agile emphasizes working code as documentation because the working code is a clear concrete thing that the entire team can gather around and say, “yes, this is right” or “no, it should be some other way.”

Agile in our Enterprise

I’m going to hold this for a future blog post…this one is long enough as it is.

Other Conference Observations

• I thought I’d be hearing lots of people at this conference saying, “do it in Rails” or “Django” or <name your new-fangled web framework>; I was surprised at all the java and .NET technical talks.
• I loved the Musick Masti sessions over lunches and at night.  I got to go down a jam on a sax they had there, as well as play various percussion and other instruments.  That was a lot of fun.  That seemed to be a theme the conference organizers were going for…things should be fun!  The Monday night social/networking event was a good example — various wiis and other games were strewn about the vendor hall providing opportunities to interact with other people through games.
• SO…MUCH…SWAG.  Wow…I brought home almost a whole suitcase full of free books, balls, silly putty, race cars, planning poker cards, t-shirts.

* 1) dodgy conference wi-fi access.  You’d think ubiquitous wi-fi access would be a given at a techy-geek conference like this.  It was great in the Open Jam area where people could congregate and talk about whatever, but it wasn’t as good elsewhere, 2) my Airport wireless card has been giving out for the last few weeks, and finally died at the conference.  Luckily, the Chicago Apple Store is not far from the conference venue — they sent it in and fixed it for free, even though my AppleCare expired in April (I love Apple’s customer service, and the fact they know that I’m pro

by Jeff Patton

Pragmatic personas can be fast, based on user research, but can also draw on your own experiences (according to Don Norman)

Identify User Types or Roles

• Different kinds of people are user types (student, professional)
• User Role describes the relationship a person has with your product (thing-doer, eg late night pizza buyer, daytime lunch seeker)

Profile User Types

Personify User Types to Create an Example User

Consider Product Design Impact

Mike Cohn – (slides)

Software requirements are a communication problem; balance is critical.  If business side dominates, functionality and dates mandated with little regard for constraints.  If tech dominates, we make them speak technical jargon and we lose the business need, drivers.

We cannot perfectly predict a software schedule.

So…we make decisions based on the information we have, but do it often

We spread decision-making across the project, rather than making one set of decisions…

Stories

Stories are (Three C’s, Ron Jeffries)

• Card (Note card) – Most visible part
• Conversation – Promise from dev team to product owner: “We will come talk to you before we start”
• Confirmation – Acceptance criteria

Short story about a system feature told from the perspective of a user.

As a …<user> I want to…<goal> so that…<reason>

Sometimes, you need more detail about a story.  You can:

• Create new, smaller, more specific stories.
• Define ‘conditions of satisfaction,’ which are really acceptance tests.  “What does the product owner need to see so that we can know this story is done?”  This basically becomes the ’script’ for the Sprint review.

User Roles

Broaden scope from looking at one user

• Allow users to vary by:
• What they use the software for
• Hwy they use software

This is different than a persona, where personas are about a specific user (based on research), designed to induce empathy in the design team.  User roles are more broad, describe types of users.

Can do user role brainstorming to identify different roles:

Thinking about your product, everyone writes a role on an index card.

• Brainstorming, no judgement on what the roles are
• Put related roles near each other
• Combine, consolidate, remove

Advantages of using roles

Avoid saying “The user”.

Can also have system and programmer users.  “As a payment verification system, I want all transactions to be well-formed XML…”

Stories, Themes, Epics

User Story – Description of desired functionality told from user perspective
Theme – Collection of related user stories
Epic – Large User Story

Themes, Epics don’t really imply size…Themes aren’t necessarily bigger or small than Epics.  They’re just labels.

Russ Unger, Todd Zaki Warfel

Traditional barriers to UX research: Time and Money; customer/stakeholder perceived value, and the attidude that “We don’t have time and money to do this.”

Argue, “We don’t have time and money to NOT do this…”  Spend a few hours doing some research, in order to allow you to make data driven design decisions

Each methods have strengths and weaknesses.  It’s good to combine multiple methods

The Burrito Lunch

• Send out an email, if you fit a profile, come do this, and we’ll give you lunch
• Chocolate snacks are a helpful way to get people to fill out surveys

Crowd Sourcing

• Using social media, other tools to get people to give feedback.  E.G.  Twitter, Facebook
• Coupled with web analytic data

Man on the Street

• Simply just going out and asking people, note trends.

User Research: “You never ask the question you really want answered.  If you ask the question you want answered, you’ll miss all kinds of rich information.”

User Research…one of the benefits of the agile UX methods is that you can bring prototypes to user research sessions: gives you access to users, do validation of current design, and research for future sessions.

Designing the Box

• Get people together, some Sharpies, paper, ask people to design the box the product, tool, service would come in.

If this was a COTS product, what are the key features that need to be front and center.  As a UX designer, gives you insight into the thought processes involved in prioritizing features, etc.

Guidelines for asking better research questions

• Provide context: “Did you have coffee yesterday?  How much coffee did you have yesterday?  Was that a normal day?  How about the day before that?”  It’s our job as researchers to ask questions and identify trends, amounts, etc, rather than asking them directly?
• Helpful to start with a most recent or most memorable experience.
• Start broad and open ended
• Funnel and narrow questions

People want to tell you about their lives.  If you can facilitate in a way that allows them to tell their own stories, people are willing to talk.  Another way to help people talk: “I’ll share a story about me, then you share a story about you.”

A story on Userfocus today, Usability ROI: 2 measures that will justify any design change, recommends two techniques for convincing management to pursue user experience deliverables in their projects.  Both involve quantifying, in dollars, the value of the change.  For example, a redesign of our eCommerce site improves sales by 5%, which results in X dollars, or we shave 15 seconds off a common task performed by employees on an intranet, which results in Y dollars of savings.

I haven’t found this to be universally true.  I did something like this with a client.  “Look…if we redesign your call center application like this, we should shave 10 seconds of each call, which will result in $6 million/year savings.”  I thought it would be a slam dunk.  Not so.  They said, “Thank you very much for that insightful analysis, ” and nothing ever changed.  I was stunned.

Looking back, I think there are two reasons why my argument didn’t fly, and why you might be cautious with the advice in the previous article.  First, those ROI figures sound unbelievably large.  I know the math is solid…so do you.  But I think Senior management hears those types of numbers and think, “yeah right…there’s no way moving this field from the left to the right will double my sales.”  Second, the user experience of the product is rarely the only consideration in a project, and even more rarely the most imporant consideration.  Managing a large web project is hard, with lots of people, teams, resources, stakeholders, and some inflexible and unreasonable deadline.  There may be absurd-but-nonetheless-real reasons why the manager can’t act on your recommendation: the technology platform has already been selected, the CIO said it has to be a certain way, the project plan has already been set, etc.  Plus you’re telling some grizzled project manager who’s learned to rush through requirements to maximize development time that you’re going to delay development while we extend the design process.  Tough sell.  (Yes, I know we would suggest we do agile/iterative development instead of waterfall…I’m just saying not everyone in every company is there yet)

I think Jim Nieters and Laurie Pattison said it well in UXMatters:

A senior VP once said that the cumulative savings all the teams proposed, telling him how much he could save by implementing their ideas, would add up to more than the revenue his company earns, which is clearly not reasonable! You can’t save more than you earn. Senior leaders frequently consider ROI arguments funny money. The issue of value really comes down to personal accountability. Remember, that trust thing: If leaders trust you, they’ll listen. If not, they won’t.

It’s not that ROI arguments never work. In fact, it’s useful to have some of the best ones in your back pocket to pull out if someone asks. It’s just that usually when someone asks What’s the ROI for user experience?, what they’re really asking is Can you give me examples of what you’ve done in the past? If you can generate a portfolio of your UX group’s wins, you’ll be in a strong position, because your arguments are no longer theoretical. And that’s the main issue. If you can show what you’ve actually done, executives can see practical value and extrapolate how you can help them, too. Don’t talk about what others have done. Show what you have done.

I don’t think you can rely on ROI arguments to sway everyone to your point of view.  You need to think more in terms of a seige than a single strike/snipper shot.  I think first, you have to establish your credibility in the organization.  To that, you have to show them some actual results that you have achieved within that organization…none of this, “it worked well when I was at my old job.”  Second, you have to be extra transparant on your work — how you do it, how long it takes, and when you’ll be done.  Don’t wait for someone to come and ask how you’re doing…be proactive in your communication to the project team.

I think UXMatters has a number of good articles on promoting and evangelizing UX:

• Selling UX
• In Search of Strategic Relevance for UX Teams
• How to Succeed As a First-Time UX Manager

Today we launched a new version of our National Career Readiness Certificate website (I think it looks great, even though I didn’t work on it so I can’t take any credit for it).

In the final minutes before launch, we received a request to remove one of the main links from the front page — I’m guessing there was a desire to remove words from the page, reduce clutter, etc. The problem was, our design team thought the link was important…it provided key information we thought the users would find helpful.  This type of discussion is difficult to resolve because you’ve got paying clients saying, “we want this,” and you need to find some way to say, “no, I don’t think you really do” without offending anyone’s sense of ownership.

It helps to have some objective metrics or measures that helps move people from an opinion-based discussion to data-driven decision making.  We happened to have one. About a month ago, I used CrazyEgg to generate a clickmap of the page. Of the 1000 clicks we recorded, 23% were on the link in question — twice the number of clicks as the second most popular link.  That makes a strong case for the fact that the link is something the users are looking for and attracted to when they visit the site, and that it should probably survive the redesign.  The client agreed, and the link survived.  (We’re planning another set of clickmap measurements to confirm that its still important to have on the new site).

We were able to back up our UX design intuition with some hard numbers and some effective visualizations (clickmaps make pretty pictures that make an immediate impact on clients and stakeholders), to help the team make data-driven decisions about the site user experience.   This is something I hope to continue to do in our organization.

Customer-centric focus can be a bit of a culture change in organizations that are not used to it, so it requires a concentrated and sustained effort to educate decision makers and project stakeholders on what exactly is user experience design, and how to design for, achieve, and measure good user experience.

We’ve had some success communicating the need for user experience design work in our company, but it seems we need to be more clear on the fact that its not something that can be tacked on at the end.  I still hear people saying things like, “We’ll get the requirements, build the back end, and then you can come in and put a good user experience on it.“

UX practitioners see the problems with that kind of thinking:  1) User Experience is not something you can ‘tack on’ at the end of a project.  Rather, it requires a focused, coordinated effort between the UX team, development team, and business stakeholders to ensure product features meet user needs and expectations, 2) User Experience is not a discrete part of a product that you assemble together.  We can distinguish the user interface of a product, the part of a product that users can see and feel, but that’s only part of the user experience.  Rather, user experience is the quality of experience that a person has with a particular design, so it includes the user interface, as well as database performance, information architecture, business processes and site metaphors, delivery mechanism.

I’ve been trying to think of some type of analogy that encapsulates why we can’t come in and put a good user experience on a project.  Here’s the best thing I’ve come up with so far:

Let’s say I’ve got a busted up, rusty, 1973 El Camino.  I can paint it cherry red, put in leather seats, and paint a horse on the front.  I’m not going to have the same experience — speed, handling, prestige — as if I were driving a Ferrari.  To get the Ferrari experience, all the parts are designed to work together to deliver the speed, handling, and prestige that its customers expect.  Similarly, our development, UX, and client stakeholders have to coordinate to understand and deliver the experience that our customers expect.

Do you think that a valid analogy?