This post is about how looking at the context your product is targeted for can explain your organization’s support, or lack of support, for user experience concerns.

Software development and plastics

I remember something Tim Lister said in a talk at a conference a couple years ago now – and I know I’ll paraphrase this slightly wrong – but Tim said something to the effect of:

I hope you get his point – no matter how badly I’ve likely mangled his original quote. Lately I get his point – too often for my tastes.

User experience practice varies wildly by product type

I’ve worked as a consultant for a while. This means I get the opportunity to spend time in a variety of companies. I’ve spent time working in banking, stock portfolio management, medical records, brick and mortar retail, on-line retail, aircraft parts wholesaling, dot-com-search-engine-companies-that-now-do-everything, digital asset management… there’s more, but that’s more than enough to make my point. I’m lucky enough to be involved with all those folks because I know a little about planning, designing, and constructing software in an Agile context. When I appear at an organization, most folks are looking for some answers – better ways to do things.

Because I’ve developed some expertise in user experience practice and Agile development, that’s the particular area I’m often asked to help out in. But, it’s when I talk about user experience design practice that the difference between software development organizations and the products they develop really becomes obvious. Within a few minutes I usually find myself reaching for a whiteboard marker, index card, or sticky note to draw this model:

It’s one of those often overused Gartner magic quadrant diagram. I suspect we can correlate about any two concepts using one of these things – and it may be done a bit too often. It’s important you don’t think about them too hard. I know I don’t. It’s the concept behind them that’s important.

So, let me explain this model.

Look at the source of value for the software

 

Business value is a big deal in agile development. Sometimes I wish agile practitioners would stop chanting it and start asking where it’s actually coming from. In many companies they seem to value the amount of software built – as if we were selling this stuff by the pound. The real value comes after the software is delivered and/or sold or put into use. Using the software is often the source of the value. – which is an interesting insight I’ll come back to later.

On the bottom axis – the x-axis – is the way we earn return on software after it’s delivered.

To the left is software where we build it for our company’s use – where we as employees of the company are our own customer. We usually build software to make out work more efficient – to save money, to afford us more time to do other more profitable things. That’s where the value comes from.

To the right is software we build to earn money. This includes packaged shrink-wrapped software where consumers buy our software off the shelf, off a website, at big tradeshows with smiling salesmen in logo-ed golf shirts, or from smooth businessmen talking to c-level execs on golf courses. Basically, people pay money for the software. The more they buy, the more our company earns.

Also included here is software that does our selling – such as eCommerce websites where the website sells our products, or even information websites that include advertising where we earn money by bringing eyes to ads and motivating click-throughs.

And finally, I’ll include here consumer facing websites or applications that although they may not be sold commercially, they have direct effect on the brand perception of the organization that created them. I’ll nudge them slightly left towards the middle on the x-axis.

The more direct the connection between your company’s revenue and the software product, the farther right you’ll find the product.

Look at the user adoption model

The vertical axis – the y-axis – is for the user adoption model. Basically do I, as a user, have a choice to use the software or not? Do I have other options?

On the top of this axis I’ll put software products where the user has lots of choice. Something like on-line shopping sites or the software we use to map directions on the internet. I as a consumer have got lots of choices. If I find myself frustrated, I can quickly surf to another url and try something different. And, in practice, many consumers often do try multiple options. For example, if I’m not happy with Google Maps today, I’ll try Yahoo Maps.

Also in the top, but possibly a bit lower are some shrink wrapped consumer products. I get to choose if I want to buy Microsoft Money or Quicken. But, suppose I buy it, take it home, install it, and start doing my home accounting – then decide I don’t like it… now I may have a difficult choice to make. Do I uninstall it? Re-do all this work? Or do I just put up with the things that annoy me? Unmaking my buying decision is a bit tougher than surfing to a different url.

More freedom of choice for the user of the product places them closer to the top of the y-axis.

 

On the bottom of this axis I’ll put software where use is compelled… where it’s part of my job – something necessary. Around the middle of this axis, possibly a bit below, are things like Microsoft Office. Face it, if you’re in business you don’t have much of a choice. Even tried-and-true Mac users working in business still need to edit and exchange Word, Excel, and PowerPoint files. Bill’s got us.

Lower on the y-axis are the things we use as mandatory parts of our jobs. The point of sale software baristas type orders into at Starbucks, the accounting system our company uses, or the hideous time tracking software many of us are forced to use.

I think you can start to see the shape of things here. So, I’ll bring the user experience thread back in.

User experience practice thrives in commercial software where users have options

 

It’s not hard to imagine why the user experience practice is relevant here. If your company fails at user experience too often here, it’ll be out of business – especially it it’s got competition.

If you’re a user experience person, and you’re choosing a company you’d like to work for – one that really values user experience, you know where to go: high and to the right. As Guy Kawasaki says, “in one of these charts you wanna be like George Bush – high and to the right.” (Please remember it’s not me who says that… I’d never say such a thing.) But, what I mean here is that UX people working in one of these companies will likely have peers, co-workers with the same job title – maybe a whole user experience department! The development process the organization uses will factor in UX. There will likely be a fair bit of user research done. There will likely be a fair bit of iteration on design and testing before we release to users – and then we’ll likely be pretty responsive to user feedback. We know that if we don’t, we’ll be in big trouble. We know that if people don’t really love our product, we’ll all be out of a job.

User experience practice struggles for those building internal compelled use products

 

Contrast those working “high and to the right” with those working on products in the low and left side of this chart.

This is traditional IT where an internal development organization builds or contracts for the construction of products used internally by the company. If there is a user experience person working here, they’re presence is likely sponsored by some well meaning exec who wants things to be a bit better. But, UX people here are lonely, often unheard, often frustrated. The development process they’re involved in likely doesn’t listen to them when they give guidance up front, then calls them in late after the software is done and ugly. They then ask “can you make this look better?” This is commonly referred to as “lipsticking the pig.” Some of you might find this humorous – unless of course you’re the UX person in your internal IT department.

 

This is why when we look at off-the-shelf Agile development practice, there’s often little or no guidance for including user experience practice. Of course, Agile development has spread to be used in all quadrants of this model. But, if you look closely at the user experience practice in Agile organizations building products in those other quadrants, you’ll see user experience practitioners who’ve adapted their process in some innovative ways. (Note salesforce.com’s amped up application of the RITE method.)

UX gets moderate attention where user adoption and/or revenue is at stake

 

The other two quadrants can go either way. Sometimes products that fit into these quadrants get reasonable attention, and sometimes they struggle.

High and left finds us still in IT – internal development – but working on software where the people working for us aren’t forced to use the software. I see this with company web portals. At my previous employer I could expect a lot more time and effort to be put into the user experience of the company information repository – the one we hoped everyone would use – as apposed to the company time tracking system where I’ll meet Satan ice-skating before I see that thing get serious attention. Of course I’m exaggerating… I suspect the devil ice skates often.

I’ve worked with organizations where their employees are busy high paid executive consultants or agents for athletes, authors, and rockstars. They’ve had to place importance on user experience, or their temperamental employees will storm out taking their valuable clientele with them. These companies have a process that reflects this concern by including user experience people.

Low and right finds us in commercial software – but in the big package stuff. The products where those making the buying decisions likely don’t use the software. Some of them could have been in on the multi-million dollar buying decision… but I suspect the frustrated employee in accounts payable can’t throw up her hands and say “I’m sick of Oracle Financials, I’m off to Staples to pick up a copy of SAP!”

No one expects an identical process to work everywhere

My point with all this explanation is that the process we adopt for requirements, design, development, testing, and end-user validation all reflects the risks involved.

Sadly, internal IT projects with poor user experience aren’t seen as failures. Now if their late and over-budget – that’s failure.

On the flip side, in the commercial world, failure is measured in dollars – and often felt fairly quickly.

I was at a workshop recently at [[CHI] where we discussed user centered design practice in Agile development. At the workshop was Heather, a UX person working in an Agile environment. She talked about an early project were user experience research was not done, but then said “We now do research with every project.” “Why”” someone asked. “That product didn’t sell” Heather said.

Of course you know that this four quadrant model only tells a bit of the story. The domain we’re in will have huge impact on our process as well. Developing medical software is very different than developing software for stock traders, or on-line shoppers, or teenage game players. Recently I ranted about this misuse of the term “potentially shippable software” in the standard Scrum model. In many – if not most – software development environments, it’s unrealistic to ship software after one development time-box – one scrum sprint. It takes time and iteration. Rooting around for a Scrum model slide recently I found Mike Cohn’s deck describing Scrum for game development where the term “potentially shippable software” was replaced by “incrementally improved game.” I suspect you can’t sell the idea to some game companies that they could “potentially” ship a new version of Half Life after a 2-4 week sprint. Imagine a game where quality of user experience wasn’t critical? Not since Zork have we been able to pay minimal attention to UX in our games.

Best to market trumps time to market only when there is a market

 

I’ve heard Alan Cooper chant the mantra “best to market trumps time to market” and he’s right, but that only works when there is a market. A large amount of software being created doesn’t really have a market – at least not one that serves users.

Those of you who work inside an organization that values user experience reflect for a moment on your internal systems, your time tracking system, your internal knowledge portals, you internal accounting systems, expense tracking systems… would these be the products you’d buy if you had a choice?

In organizations where there’s a large development effort focused on internal IT support, I’ll often find a traditional requirements gathering process installed and little involvement from user experience design. But, if I walk across the building to the group that maintains the company website, I’ll usually find a designer.

Alternatively, if I walk into an organization that builds high quality commercial software, it won’t take much probing to elicit complaints about the quality of their internal systems. If I walk over to their IT department that builds those systems I likely won’t find user experience staff.

My point here is that we often know exactly what it takes to build high quality software – high quality from a user experience prospective anyway. But, we often don’t do it even when we clearly know better – when our revenue isn’t at stake, when we know people will use the stuff no matter how crappy it is. Often it’s a “cobbler’s children have no shoes” sort of situation.

One size fits one

Lately when I visit companies I spend a lot of time explaining to them why they’re unique – and they are. They all need a process tailored for them – one that’s sensitive to their culture, and their product risks, and benefits. I’ll still go out on a limb as say that it’s crazy-talk to not include some elements of user experience practice even if you are in a traditional IT world. It’ll save you a lot of time and money thrashing over “bad requirements.” And, the poor folks using your crappy time tracking software deserve a break.

Postscript: yes this is a retread

I first drew this model in an old blog post describing the difference between buyers and users. Actually I drew it a bit different, but if you squint a bit and think about, you’ll see it’s roughly the same idea. Read the essay since it points out something slightly different – that is the thought process we go through when buying and how it’s different than the thought process we go through when using. Those of you in an Agile customer or product owner role, remember when you’re prioritizing a backlog that you’re a buyer. Your instincts are suspect when you’re in buying mode vs. using mode.

I’m also pulling back thinking on process and the necessity to take into account your context when putting together a process – which is also a stolen idea from my friend Jared Spool who finally picked up the subject again in his battle against dogma in his recent IA Summit keynote. Take a look at that too.

Shameless self promotion

I’ve been a real live independent consultant since January. I’m thankful that I’ve been consistently busy. But, I’m on a crusade to improve software for the people on the lower left quadrant of my model above. To support that I’ve got a buffet of course offerings that allow you to tailor a class to improve your requirements and design practice.

I work on the right side of the model to help UX people working in Agile development adapt. As I mentioned above, Agile development came from the lower left, and doesn’t have much guidance off the shelf to help these folks. I’m happy to charge a high daily rate to be a shoulder to cry on. Wait, that sounds insensitive. There are actually ways to adapt traditional UX practice to be a better fit, as well as ways to help enthusiastic Agile practitioners understand what UX practice is and why it’s important. This blog article is one of the models I use to explain it to evangelistic Agilistas.

If you’re a UX person struggling with Agile, please visit me at UPA 2008 in June, or at Jared Spool’s UI13 in October.

If you’re an Agile person interested in user experience please visit me and the dozens of fabulous agile-savvy UX people at Agile 2008. I’m really looking forward to learning from the fabulous lineup of UX people presenting light weight collaborative UX practice suitable for Agile environments, and any other environment for that matter.