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.

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

Some of us work for in-house UX groups and others work for agencies. Having been both an “innie” and an “outie,” I can vouch for the fact that I learned a lot more during my experience working for an agency. Here are the pros and cons.

Pros:

1) The variety of projects makes the work interesting and keeps you on your toes. You never work on one project at one time. You juggle multiple. You learn the nuances of many different kinds of technology and use models.

2) You sharpen your ability to think strategically in your design approach as well as selling your ideas. Since you are presenting your work to new stakeholders on a regular basis, you must justify design decisions with usability goals, business objectives, and/or metric indicators. Everything you put out there has to be polished and your best work. It’s like being a new employee every couple week and you have to prove yourself to a new set of bosses.

3) You learn to work and adapt with many different organizations and teams. Every organization has a different working style and organizational structure. That affects communication and approvals. This requires that you are quick on your feet, since you’ll be constantly drilled by clients. Even when they love what you do, they still drill you.

4) You become a walking encyclopedia of the best on the web. Because of the variety of projects you are exposed to, regular research and analysis are part of the job, even when you are not on the job.

5) Shorter time lines means quicker decisions and launches. After working at an agency, I get impatient at how slow decisions are made and how long it takes in-house groups to develop.

Cons:

1) Lots of pressure to always deliver the best work. When large companies pay tens and hundreds of thousands of dollars, they expect you to bring your A game and think outside the box EVERYTIME, so the pressure is intense.

2) A shorter time line and finite budget creates pressure to be extremely efficient. Agencies make their money by being billable, therefore most of your time should be billable. There’s little down time to try out different ideas. Also, when companies hire an agency, they need it done yesterday, so you’re expected to be super creative at breakneck speed.

3) Pay is not as good as working for a large corporation with an in-house group.
I no longer work for an agency, because now I can charge more working for myself. However, I think the experience is valuable. I’m so glad that I did it. Best learning experience I ever had.

MOSS projects for a number of reasons, and it’s usually not the tool. (And only know this because with proper planning and design, our clients have raved about what a good product it is.) SharePoint can do great things when it’s used for what it’s designed for i.e. if you want to nail a nail, use a hammer, not a screwdriver. It’ll be ineffective if you use it like using that screwdriver.

CleverWorkarounds has a good article about it, comparing it to a drinking game which I think is classic. Again, it’s not the tool. They also have another article about selling MOSS that’s pretty “interesting”.

A few years ago, I worked at a company that had recently adopted Extreme Programming. After slogging through a few books about how XP worked, I refused to do the putting requirements on 3″ x 5″ cards, falling back to what I was comfortable with — wireframes. The wireframes were never really complete and detailed, but for six months, we ran an Agile development framework that ran on rails — so smooth, in fact, that we rarely pulled features.

That was a pretty small team. In larger teams, Thinking and Making talks about a change to their development process that successfully handled managing the requirements gathering process in an Agile environment. Read on…