Archive for the ‘Design’ Category

How UX can get anything they want

I’m a fan of the unconventional view that most people, most of the time, worry about the wrong things.

When it comes to the world of UX, designers, usability engineers, and the rest, they tend to complain about how little power they have, but spend little time doing skill development in how to gain influence and power.  The average designer or IA would be better served by going to a sales conference and learning sales and pitching skills, than going to yet another design event. They’re already good at design, but they’re probably not very good at pitching design ideas to non-designers.

One fallacy in how designers and HCI experts are trained is the lack of recognition that most of their careers will be spent working with people who know almost nothing about design or HCI. They are set up to be marginalized and kept in the corner of organizations, since they’re never shown that their success hinges not just on expertise, but the ability to translate that expertise into terms the people who they work with, and for, can understand. The biggest skill gap the UX world has are advocates, translators, and persuaders, people who are not afraid to sell and convince others on the value of their work.

Last year at UI14 I met Alastair Simpson, a UX manager who, in a former life, worked in sales.  I asked him to blog about how to apply his sales background to the challenges of working in UX, and finally he did.

Here’s an excerpt:

Each time I visit a conference I hear the same problems faced by UX professionals.  Not the never ending search for a perfect interface, the perfect user flow, or a usability test that passes without incident.  Most commonly it is “If I could only get the budget, my CEO just doesn’t listen to me in meetings, they seem to switch off and just don’t understand my point of view”.  In the majority of cases this is probably your problem, not theirs.  Successfully pitching your ideas and making your managers, and their managers buy into the UX problems on your site is essential in getting sign off for your projects.

Read the full post here.

I don’t think UX, or anyone, ever gets everything they want. But if you know how to sell, build trust, and choose wisely, you can often get any one thing that you want. And having the courage to do this is how respect, power and influence are earned.

Also see:

Don’t be original, just be good

As another way of making the arguments I made in Good beats innovative nearly every time, here’s design legend Paul Rand.

At about the 3:00 mark he says ‘don’t try to be original, just try to be good’

It’s also a fantastic introduction to visual design thinking: better than many textbooks I’ve seen.

TurboTax Design FAIL

I’m so hopeful when I install the new version of something. Everyone is. An upgrade, the payment of cash for the new version, is an extremely hopefully act. I imagine they’ve fixed some things, made some nice improvements, and most of all, have taken into account the things I did with the old version.

And thinking like a designer, the best time to make me feel I chose wisely in upgrading, instead of buying a competing product, is in the first few minutes of use, known in the lingo as the OOBE (out of box experience).

So here it is, in 2010, that Intuit TurboTax fails me again.

As an aside, Yes, I know, I have not be failed by TurboTax in the same way the folks in Haiti have been failed by the universe at large. I won’t lose a limb or a family member or even, with the recession in mind, a job. I know. But still there is a corporation and a business and teams of engineers behind this thing and it’s mystifying.

Back to the story: one thing I’d expect TurboTax to know is to notice I already had TurboTax and used it last year. You know, a returning customer. I’d just assume it would notice last year’s return sitting there and bring it into the new version for me. I was wrong.

The opening screen shows no evidence I’ve ever used the product before. It’s just a mostly blank, empty, sad little screen.

I wondered, for a moment, if this new install somehow deleted all of my old tax returns? This would be quite disappointing. I mean, if TurboTax can’t find other TurboTax returns, it should be safe to assume no one can and that they’re disappeared from the universe forever.

Ever hopeful, I press on. I click on the “Find a Tax File” link, in the lower right, and get this File Open Dialog.

To my sadness, there’s yet another blank screen. Blank Screens are bad. It says “you are on your own – good luck”.

Why is this blank? Simple. The little filter box at the bottom. It is set to default to look for 2009 tax returns only. And since I just installed, it’s improbable there could be anything here with this setting. My previous year returns, despite being in this folder, despite this being the first time I’ve ever used the 2009 version, do not show.

Eventually I figure it out, flip the filter, and alas my old return is there. Sigh of Relief.

But when I click on it, ha ha, the Turbo Tax programmers have another curve ball for me. This is apparently the wrong way to load my old returns.

Let me translate. What this dialog really says is this:

We, the programmers were too lazy, or are too poorly managed, to implement a good solution. Namely, to make the software, at least for the first 5 minutes, follow the natural flow of what returning users will do in this sequence of screens (e.g. start by loading last years file), or doing what’s smart for ourselves, and acknowledge you are a returning customer and reward you for it in some way. Instead we have put up a obnoxious clinical, poorly written dialog that, in the first paragraph, suggests you are completely hosed, only to explain in the second paragraph you are merely partially hosed. Fundamentally, this dialog is a testament to the fact we resolved this bug as fixed by simply putting up a sign, sweeping your lousy experience with our work under the virtual rug.

This product has been around for 15 years. What a shame. I suppose it doesn’t say much for the quality of its competitors. Perhaps this is the best there is.

Now I know the programmers themselves might not be to blame – but whoever prioritizes bugs, makes feature decisions, or decides which part of the user experience gets invested in, and which don’t, certainly is.

I hope you’ll forward this to any Intuit employees, or friends of Intuit employees, or friends of friends of neighbors of Intuit employees ex-girlfriend’s cousins, who might know anyone on the TurboTax team who hopefully, when they see this missive, will hang their head in shame? and perhaps promise to get some low hanging but very tasty fruit like this right next time?

Thanks.

Problem Solving & Kobayashi Maru

Over on my post Do constraints help problem solving, Aaron asked:

I’m currently completing a dissertation titled Development in Product Design is driven by a response to changing constraints rather than innovation for my 3rd year BA Product Design course. You have stated that constraints can be eliminated on purpose, I can understand how they can be created but not eliminated? have you got any example of this in practice?

The best attitude to have when trying to solve problems is that everything is negotiable. Just because someone says the car they want you to design must be red and ten feet tall, or done by Friday doesn’t mean it actually needs to be those things. Most constraints people give us are soft and vague: they haven’t been rigorously tested, pushed or probed to find the real boundaries.

Maybe instead of being ten feet tall, what they really want is a car they can fit comfortably in, given that the client is Cleavland Cavalier’s Shaquille Oneal.

And perhaps it’s not a red car they want, but just a car that looks cooler than their neighbors car.

Or instead of it all being done Friday, only one important part needs to be done, but the rest can be done by Monday.

People confuse being specific with being accurate. Having details and numbers doesn’t mean you understand why those things are the right choices.

The trick in creative work, especially with clients, is how to explore their constraints in such a way that you do not annoy them, but that you understand the problem sufficiently well that you get at core of the problems they need to solve. And then get them to happily acknowledge these are the true problems, rather than assuming their description of their problems is sufficiently well formed to be the true target. The reason why so many projects fail is the lack of this skill on all sides: clients, executives, designers, engineers and customers all stink at this process, and dismiss it as irrelevant.

The fancy word for this is requirements elicitation. But it really just means thinking hard and carefully about requirements, understanding they are a kind of design unto themselves. Someone has to diligently sort through those that contradict, that are poorly formed as well as those that are unnecessary. Prototyping and sketching helps sort this out, but that’s just part of the process.

The best book I’ve ever seen on this is Exploring Requirements, By Weinberg. It should be required reading for anyone who solves problems for anyone else.

But the big problem is, of the few phrases more boring in this world than project management, requirements gathering is definitely one of them. It needs a slicker name. I hate jargon but I’d be all for something snazzy that gets them to care more about this kind of thinking. (Require-magic? Constraint-O-Rama? Hmmm).

Sometimes you can find a way to make two different constraints reduce down to one, making the problem simpler to solve. A constraint (e.g. requirement) might not be eliminated, but can be bent, shifted, twisted, rephrased, or entirely manipulated (See Kobyiash Maru) to serve your purposes.

A favorite example: for decades the problem with bringing the internet into developing countries was the expense of digging tunnels to put in power, phone and cable lines. The advent of cell phones, where towers are built above ground and no wires are needed, eliminated the constraints around digging and cabling. For many people in the world today their first phones, and first web browsers, are cell phones. A constraint was entirely eliminated by design.

Good ideas can sometimes eliminate seemingly immovable constraints.

Good beats innovative nearly every time

My first article for BusinessWeek is up now:

Good beats innovative nearly every time

Why you should be a team of one

One of the best exercises a working person can do is this: spend some time doing the jobs of the people you work with. Every manager should be required to do this once a year, even if just for a few hours. Most of us, most of the time, work with blinders on. We naturally assume our work is harder and more important than the people we depend on, or who depend on us, and the only way to be reminded of this is to put yourself in their shoes now and then.

At the UI14 conference last year I caught an excellent talk by Leah Buley, an experience designer at Adaptive Path, called UX Team of One. The core idea is in many, but not all cases, one person can effectively do both analysis (usability engineering) and synthesis (design and prototyping of new ideas) if they have the right attitude, experience and perspective, which she described in detail in her talk (slides here).

This is not to suggest singular expertise in usability or interaction design is useless. Not at all. My point is in many cases the usability and design problems are relatively simple and the reason why things are bad is not a lack of expertise, but a lack of willingness among ‘experts’ to step out of their safe expert box and fight to effect change, or a failure to succeed at it. Someone with fewer pedigrees tends to see fewer boundaries, and that’s often what a team or culture or company needs for change to happen. Many projects need basic first aid, not brain surgery, and I suspect medics, who are generalists, do better first-aid than neurosurgeons, who are specialists. Of course if I have a brain tumor, I’ll wait for Mr. Neurosurgery, but otherwise he’s not my best bet.

There are many people with PhDs in cognitive psychology, or Masters degrees in design, working on projects with abysmal usability or interaction design. The problem isn’t lack of expertise, it’s a lack of awareness for how to convert that expertise into action. Their deep expertise can be a liability if it gets in the way of getting their hands dirty.

The intellectual exercise of trying to do a project alone, where you have to play the role of product planner, project manager, designer, engineer, tester, marketer (or whatever the list of roles is in your world), even if just for a day, forces you to rethink the assumptions about each and every contribution on a project. Maybe it’s harder than you think, or maybe it’s easier, who knows? You likely have no idea since you’ve never done any of those things. If you have clients, what do you really know about their world? Project and Middle Managers are notorious for having no real sense for how all the contributions by others that they get credit for, are actually done. This is an easy disease to cure: invest some time standing in other people’s shoes.

I believe there is a core set of skills, orthogonal to traditional ideas of expertise, that defines who is effective at work or not. Call it savvy, self-awareness, organizational agility, or just plain common sense, but it’s the real factor at play at why some experts have an impact and others don’t. Playing Team of One for a day is one easy way to start getting at those skills. It gives you a language and sensibility for thinking about the people you depend on, the absence of which contributes to why they’re ignoring or frustrating you.

Related Posts:

« Older Entries |

Scott's Bestselling Books
  • Confessions of a
    Public Speaker
  • Provocative and funny secrets from a veteran speaker, you'll laugh as you learn.
  • Buy now at Amazon Book Details
  • The Myths of Innovation
  • The classic bestseller on how amazing lessons from the past can help you innovate today.
  • Buy now at Amazon Book Details
  • Making Things Happen
  • The classic and bestselling handbook for any project leader, packed with tactics and stories.
  • Buy now at Amazon Book Details
Photos from Recent Events (view flickr stream)

You're reading Scott Berkun, All rights reserved unless noted. You can subscribe here Blog RSS Comments (RSS)