Most clients think they know their business and when they approach User Experience professionals, they’re anxious to get wireframes cranked out. How do we get clients to take a step back and engage in strategic type activites to optimize their technology solutions?

For me, this didn’t happen overnight. I stopped obssessing about whiz-bang interfaces and took an active interest in helping clients think about design in terms of return on investment. Because I always spoke my mind and articulate ideas in terms of how they drive the bottom line, clients began to include me in strategic meetings. Below are some of ways I incorporate strategy focused activities into my process.

Propose the Value Proposition

When I first consult with new clients about a project, I let them know that analysis and research are an integral part of my process. It allows me, the UX designer/Business Analyst/IA Minion to understand their business from the inside out. I explain that analysis, interpreting metrics, product roadmapping, etc. can optimize return on investment. By interpreting indicators on usage patterns, we can pinpoint what’s not working and leverage winning features. The result is a cohesive product vision that differentiate the client from their competitors.

Speak About the Project in Business Terms Not Usability Goals

Articulating your design in business terms is a great marketing strategy. Before my first formal meeting with the client, sometimes even before the contract is signed, I always conduct a quick site audit. This gives me a fresh perspective before I know anything about the project and clients love a fresh perspective. I record my impression on branding, business objectives, and how well the design and implementation drive the business objectives. I always think in terms of return on investment. This gives me fodder to speak about the project in business terms as opposed to design terms. Incidentally, if I get the contract, I bid the hours I spent back into the job. If I don’t get the contract, then it’s good PR.

Request for Quantitative and Qualitative Data

Request for reports at the first meeting. Be prepared to explain what trends and patterns you hope to discover or why you want look at data for specific feature sets. If you don’t yet have an idea which reports you need, tell the client that you will email a list of reports that you want pulled. This lets the client know that research is an integral part of your process. It the project is a start-up, conduct topic and keyword research to define search volume. For qualitative analysis, inquire to see whether any surveys or focus group testing have been conducted and what the findings were.  Finally, ask the client how or if the business has responded to the results from analytics and surveys.

Prioritizing Requirements and Use Cases

Don’t Be a gatherer of requirements. Be an expert. When conducting interviews with stakeholders, don’t just gather requirements. Work with clients to prioritize requirements and use cases based on business objectives and the research that you’ve conducted. You may propose new requirements to refine and simplify workflows.  Always couch your input based on business objectives and the bottom line.

Use Business Objectives, Usability Goals/Strategies as the Measuring Stick for Your Design

I always preface wireframe review meetings with business objectives and usability goals. Clients gets sick of this after subsequent meetings, but they learn quickly to evaluate wireframes based on the real business goals. This is also helpful when your wireframes are circulated to other team members, because the business objectives and usability goals is a reminder of the foundations of the project.

My job is changing.

I can already feel it.

It started last year when I began getting interested in analytics, but it’s really transforming. now. I’m not a web analyst, nowhere near. But more and more clients are hiring me to help with product roadmapping. More and more, I’m looking at product design and marketing strategy from a chicken and the egg perspective.

Recently, for several projects, I’ve started with the analytics, the traffic, the market research, search volume, then work backwards to define the solution, the return on investment. So I have the egg, I have to figure what kind of chicken lays that egg.

Usually, clients will build a solution, then develop campaigns to drive traffic to it, but lately, I’ve been getting projects that are reverse. It’s not, “If you build it, they will come.” It’s more like, “They’re here. Now build something that they need.” I’m not just designing some test feature. I’m designing actual new sites with little more than a domain name as a requirement.

My role initially, is to conduct excersises with my client to clearly define the following:

1. Market sector
2. Value proposition
3. Business Objectives
4. Strategy and brand for the user experience
5. Marketing Strategy

After this excersise, my goal is to have a mission for the user experience, because a deep user experience will brand the solution. At heart, I’m still an interactive designer. It’s what I love to do. But building a sound business foundation for your design is critical to its success. If you don’t do this, then if you build it, they will not come.

The hardest lesson I had to learn early on in my career as UX designer is to be willing to take risks and start all over again. I think this is baggage from my days of working with the waterfall process and designing products that will be “set in stone” (products that ran on Playstation and CD-ROM). You get the sense that once they are done, that’s it. You have no chance of ever changing them again, so it’s too risky to veer off in a new direction.

I spent my evening at Barnes & Noble yesterday, reading “The Last Lecture” by Randy Pausch. It is a dying man’s guide on how to live your life. Randy Pausch was a computer science professor, and in his Building Virtual Worlds class, he gave out “The First Penguine Award.” The title of the award came from the notion that although the water is cold and there might be predators in it, someone’s got to to be the first penguine to jump in. The award celebrated “glorious failures” and encouraged “out-of-the-box” thinking.

I think every designer has that moment when you know that something is not quite right in the design, but you can’t put quite put your finger on it. Over the years, I’ve learned to trust this instinct as a sign that better ideas congealing in the back of my mind and I must be willing to scrap everything and just start over. Sometimes the risk pays off and I would come up with a completely new design paradigm. Other times, the excersise would provide additional insight and new strategies for tackling the design problem. Fortunately or unfortunately, I’m not an egomaniac designer who ignores budgets, so sometimes I would eat the extra hours just to produce something great.

I am always about learning and process first, and money second. Besides, there’s always something about being the first penguine that energizes you. And THAT is priceless.

I like designing web sites, because they’re more visible and by that standard, more glamorous. However, I like designing business process applications better, because applications are more function focused. The success of an application is dependent on how well I’ve thought out the workflow and functionality. It is not clouded by marketing.

Here’s a road map on how to design strategically for a business process application:

1. Design strategically for maximum productivity. When you’re designing a web site, you want to maximize clicks and time spent on a page. When you’re designing a business process app, you want the user to complete each task as quickly as possible. The less time spent on a task, the higher the productivity.
2. Prioritize features for roles by frequency of use.
3. Design for maximum scalability and flexibility as businesses can shift direction to respond to market conditions.
4. Differentiate between usability problems and workflow problems. Sometimes what is perceived as a usability issue is really a company’s production and/or red tape problem.
5. Identify and provide solutions for current online and offline workarounds.
6. Don’t just document and design for the current workflow. Look for ways to streamline the company’s current online and offline workflows.
7. Identify other systems (i.e. ERPs or legacy systems) that your application will have to hook into.
8. Flowchart primary and exception use cases to catch functionality loopholes.
9. Templatize functionality/behaviors as much as possible to optimize learnability, user adoption, and minimize development time.
10. Gather users’ input often throughout the process by conducting quick-and-dirty prototyping.
11. Work closely with the training department to address usability and user adoption issues. When a company has been using a legacy system a long time, it is a cultural shift to move to a new system.

I don’t know about you, but every time I’ve done the “hey, lets do the requirements gathering in a waterfall process,” by the time we get to the bottom of the waterfall, we’re nowhere close to where we started. That’s one of the reasons why I’m a huge fan of agile requirements gathering and software development.

Horse Pig Cow has a great post on the waterfall vs. the washing machine. It’s done in a presentation (I’m going to include it below).

| View | Upload your own

One of the struggles that we’ve had where I work at even after a year was how we document SharePoint sites. This is the first in the series (and I’ll eventually make a full blown page to send out to other blogs) — Content Type Matrix. It’s a really simple Excel spreadsheet, but contains just enough information for an agile environment to document the content types without getting too wrapped up in the details.

The document covers the following fields:

• Content Type
• MOSS Default
• Inherits From
• Meta Data
• Type (List or Content Type)
• Page Types
• Purpose / Drivers
• Outcomes

Download file:

• Content Type Matrix

How many of us have conceptualize our designs this way? How many chicken scratches and doodles actually grow up to become a real product? Here are the paper sketches that were the beginnings of Twitter from Jack Dorsey’s Flickr.

On one of the mailing lists I read, this post came across:

I would like to hear experience and suggestions on how to work with non-creative management and/or clients, and how to design without requirement document, and how to work with someone who don’t know or don’t want to follow creative process due to time and budget restraint or lack of understanding of the importance of following the process.

Good question. Usually, I say “run”. One of the readers referred to this post, which is really good.

They list questions you should ask as such:

1. Will I or my team be allowed to bring our best work to the final result?
2. Is the client prepared to engage in the project appropriately?
3. Is the client prepared to begin this project?
4. Is the client prepared to invest trust in my or my team’s ideas?
5. Am I or is my team prepared to fulfill or exceed the project requirements?

If you can’t get to those five with the client, it’s not going to be a fun project.

Usually the clients like this fall into two camps:

• Clients with money
• Clients without a lot of money, or don’t want to spend money

The clients with money track is easier, because at least you can educate them and get paid for your time. I’ve worked in environments where the client just wanted to build something, anything, and didn’t really have a concrete idea of what they were building.

It’s difficult because at some point there has to be an established finish line, but that doesn’t happen overnight. But if they are willing to pay for it, you can eventually narrow down the requirements to where all parties are happy if the client allows themselves to be managed.

The reality? In this situation, a bad client is sometimes better than a good client for the pocketbook, because the project is guaranteed to go over budget because the requirements aren’t defined well or in a buildable fashion, or the project isn’t scoped correctly. The other reality is that working with that client will damage all relationships, and that client will never be a good reference.

The clients without money? Don’t even bother. Those clients are more difficult, because they don’t want to pay for anything — requirements, wireframes, design. They usually figure the developer should be able to do all those roles, and whatever doesn’t fall under development should be a pre-sales exercise in their mind.

How to be A Good Product Manager (which is a phenomenal blog, by the way, and wish I had written most of the content) has this excellent post about requirements, and it applies requirements gathering. One of the traps that we fall into as consultants is that with certain clients, we go into the mode of just gathering requirements and not advising what the requirements should be (read: let’s design the Pontiac Aztec, quite possibly the ugliest car on the road).

Just gathering requirements is a bad idea. Advising on requirements is a better idea, because that’s how you add value.

Sure it’s like herding cats, but the reason many consultants are valuable is there’s some wonderful insight that they may have, however small it may seem, that adds phenominal value for the client. That’s why they are paying consultants what they do.

How so? We start the conversation about what the direction should be, even if it’s the wrong direction at the start. One of the essential points that the article makes is that in many cases, the customer has no idea what they want (a car), and what they may get may be anything from a Hummer or a Prius.

Our job is to ask questions that will lead to developing a better product, and not necessarily questions that lead to what we think the product should be. Many scenarios, it’s impossible to satisfy all parties, because they may ask for a car that is great for the environment (the Prius) and can run over people (the Hummer), because the requirements are conflicting. Our job is to find the best solution, not the solution that meets the needs of everyone.

Or what do they say — trying to make everyone happy will make no one happy?

You probably thought that it was going to stop at one part.

Clever Workarounds has published parts 2, 3 and 4 on their blog, and I’m sure it’s going to continue for some time. My favorite of the Part 4 is the square peg, round hole illustration.

Here’s the complete list:

• Part 1
• Part 2
• Part 3
• Part 4