Based on several articles I’ve read over the past months, and the session Eric Reiss gave at last years IA Summit on ‘ROI: Speaking the Language of Business‘, I wrote out this mind dump of how I think about selling User Experience. These ideas are fairly rough and are intended to see how closely my thought process aligns with that of my peers. Hope you enjoy!

Begin mind dump

They just don’t get it?

This is the wrong approach and leads to over discussing the variety of methods and techniques that exist in the world of user experience. Rather, we should be asking why we don’t get it? The people that have the ability to hire our services don’t care about paper prototyping, usability studies, or ethnographic interviews. They care about the value these activities can bring to their organization and how quickly they will be able to see that value manifest.

Defining the Value

Every project has a goal, and it’s that goal that determines what type of value needs to be provided by the project.

Examples of Project Goals (Reference):

• Insight into how the site/application users will think, act, and react when using the site/application
• Confidence that their site/application will function as a cohesive whole.
• Stakeholder consensus on what will be built and why it is being built.

The particular methods and techniques needed to discover, define, and provide the appropriate solution for any of these goals is dependent on context, environment, and culture. With this in mind, the sales process should be focused on defining what the client’s goal is for the project, and delivering a plan in which to accomplish that goal. Activities should be talked to at a high level until the project has been landed and the initial problem space explored.

Discovering Problem Space

The exact method in which a problem will be solved should never be defined until the problem space has been explored and defined. This can be accomplished either during the sales pursuit, or as a phase 0f a project. Defining the problem space is done by conducting internal stakeholder interviews, relying on past user research, or referring to research done by others. The outcome should be a detailed plan of user research, analysis and modeling, time to design, and validation. This can take the form of a follow up proposal, or as a set of recommendations for them to internalize and use as they see fit.

Yes, there is a danger of losing the project after this proposed initial phase, but the likelihood is low as the team will have established themselves as partners and give the client a clear understanding of how the end solution will deliver the value they are looking for. The pay off for this risk are longer and more in depth projects.

Planning UX Activities

There are a variety of possible activities that can be performed to design a solution for a given problem. Some activities are better than others however, given a particular context. In fact, the final set of activities should be laid out only after the team has a clear understanding of the client, user base, and problem space. There is no such thing as the silver bullet in User Experience, and it would be a mistake to act any other way.

When pitching proposed activities, the overall process and end deliverables shouldn’t be the topic of discussion. Rather, give a detailed explanation of the value each activity brings and how that value will assist with the next stage of the overall process. Speak the language of the client, industry, and user base when expressing the value. Don’t bog it down with professional jargon that needs to be explained.

End mind dump