Executives' requests for "design alternatives" has lead a lot of designers to engage in an elaborate ritual for the purpose of managing the executives. It works like this.
Execs make decisions. That's what they do. So rather than asking that a product be developed, they ask for "alternatives" so that they can make a decision. Because, as any exec will tell you, making decisions is the hard stuff, and that's what they get paid to do. Generating alternatives is the easy stuff, they believe. So it's up to the designers to generate a lot of alternatives and allow the execs to choose one.
Designers don't see things exactly that way. Designing a really good product is hard work. And once a great alternative is designed it's relatively easy to pick a good one out of competing alternatives. In fact, experienced designers regularly generate alternatives early in the design process as a way of expanding their own space of possible solutions. They'll then try to work the best features of each alternative into a final design.
Do you think the execs get to see these early concepts? Well, only if the designer is inexperienced or wants to see disaster strike. No, experienced designers will drive toward a good design from among several alternatives, then generate some relatively bad "alternatives" for a dog-and-pony show with the execs. Unless lightning strikes the d&p show, the good design is chosen from among the alternatives. Designers get their solution chosen, and the execs get to make a decision. Everyone goes home happy.
Wednesday, April 7, 2010
Saturday, March 27, 2010
Remarks on Managing as Designing
I was excited to find this book, Managing as Designing, because I think design skills can be put to good use in management and organizational design. Richard Boland and Fred Collopy edited this slim volume that contains contributions from authors who participated in a 2002 workshop. The participants came from business, sociology, architecture, dance, semiotics, economics, and history.
This is no how-to book. There's lots of theory. The various authors write comfortably within their own knowledge areas, but don't really help the reader make the translation from their own specialty to management. So, if you are wondering how semiotics can inform the management arena, you'd better be familiar with semiotics. I was delighted by the chapter on the application of interaction design to management, but I know the language of both pretty well. Otherwise, it was a tough go. Recommended if you like to stretch yourself.
This is no how-to book. There's lots of theory. The various authors write comfortably within their own knowledge areas, but don't really help the reader make the translation from their own specialty to management. So, if you are wondering how semiotics can inform the management arena, you'd better be familiar with semiotics. I was delighted by the chapter on the application of interaction design to management, but I know the language of both pretty well. Otherwise, it was a tough go. Recommended if you like to stretch yourself.
Wednesday, March 24, 2010
Getting max impact from user testing
Usability testing has traditionally answered questions about whether a given application or product is easy and satisfying to use. Questions about whether anyone would actually buy the product are usually left to sales and marketing. I tweaked my latest user test and it paid off in a big way. Rather than simply run a test of whether users could order a report online, I dug into the content of the report and had customers tell me if they understood the data, what data were missing, and what else they needed in order to do their jobs. The test ended up being a combined usability test and a needs analysis, something that hadn't been done previously on this product.
I've been dinged before because I didn't run a "textbook" usability test as described by an accepted guru. The thing is, usability testing is so flexible it can be used to answer any number of questions, and the questions in this case were around what customers needed and the actual marketability of the product. The responses were pretty decisive, and the direction of the development of the product is going to change drastically. That's not something that happens often by following textbook usability procedures.
I've been dinged before because I didn't run a "textbook" usability test as described by an accepted guru. The thing is, usability testing is so flexible it can be used to answer any number of questions, and the questions in this case were around what customers needed and the actual marketability of the product. The responses were pretty decisive, and the direction of the development of the product is going to change drastically. That's not something that happens often by following textbook usability procedures.
Tuesday, March 16, 2010
ACC tournament roundup
The ACC tournament is over and done, and it was the first time I got to see the rivalry up close. Almost everyone wore their school shirt to work on Friday. Depending on the shirt you wore people said, "Nice shirt," or "Ugly shirt" when they walked by. As an alum, I proudly wore my NCSU Wolfpack t-shirt, and some of those in red had a good deal of fun at the expense of the people who wore UNC powder blue. It was all in good humor.
Sunday, March 14, 2010
What's a usability problem?
This Dilbert comic strip raises an excellent question that usability people often talk about. What constitutes a usability problem? The PHM says, "...a user might need several steps to do something that should only take one." Out of context of the application, it's impossible to answer that question. If the application is a payment form on an e-commerce site, then this situation may affect conversion rates by some percentage and lead to lost sales. If it's a desktop application that is complex and only intended to be used by trained users, than perhaps it's not an issue. Often there's disagreement among usability people whether a usability issue is a genuine "bug" or not.
Interesting that the PHM brings this up, because historically we know he doesn't really understand engineering or usability very well. I wonder where Scott Adams encountered this topic.
Interesting that the PHM brings this up, because historically we know he doesn't really understand engineering or usability very well. I wonder where Scott Adams encountered this topic.
Sunday, March 7, 2010
Demotivation 2.0: secret leader list
This article on talent management reminded me of an odd approach to leadership development I encountered a few years ago. The company I worked for announced it had created a "secret list" of the company's future leaders. The selected future leaders were to be informed of their status by their managers. The employees didn't know who was on the list, and it wasn't even known who in management knew who was on the list. These future leaders would be given special developmental opportunities and visibility with current leaders and other perquisites, also unstated.
There was some discussion in the ranks of who these secret future leaders might be, but the topic was quickly dropped since there was no other information passed on about it. One thing was very clear, though. If you weren't contacted and informed of your special status you were quite sure that you didn't have any opportunities to move up at this company. The company already had a well-earned reputation for a good-old-boy, insiders-only culture with few paths for career advancement, and this program seemed to solidly reinforce that image.
As someone with an interest in organizational design and leadership, I've often wondered about this program, who initiated it, and how it turned out. I've never heard of anything like it. I still can't imagine what good was expected to come out it. I do know that the possibility of promotion and visibility within the company is one of the most reliable tools managers have to motivate their direct reports, and that was taken out of their hands by the program.
There was some discussion in the ranks of who these secret future leaders might be, but the topic was quickly dropped since there was no other information passed on about it. One thing was very clear, though. If you weren't contacted and informed of your special status you were quite sure that you didn't have any opportunities to move up at this company. The company already had a well-earned reputation for a good-old-boy, insiders-only culture with few paths for career advancement, and this program seemed to solidly reinforce that image.
As someone with an interest in organizational design and leadership, I've often wondered about this program, who initiated it, and how it turned out. I've never heard of anything like it. I still can't imagine what good was expected to come out it. I do know that the possibility of promotion and visibility within the company is one of the most reliable tools managers have to motivate their direct reports, and that was taken out of their hands by the program.
Wednesday, March 3, 2010
Jamming applications into bad templates
I've had a lot of conversations with business people and developers who want "templates" that will work for any application they develop. This is usually in the context of their wanting to cut out all "unnecessary" analysis and design work so a project can jump right into coding. I've tried to explain that jamming your application into an inappropriate template is harmful at worst, silly at best. I'd never found a really good example that I think makes the point, until I found this:
http://www.handerpants.com/
I may put these on my X-mas list.
http://www.handerpants.com/
I may put these on my X-mas list.
Subscribe to:
Posts (Atom)