Interface Design & Usability

Creative Navigation

2008-02-20T14:42:00.009-06:00

Navigation for Websites and software applications fascinates me. I'm always on the lookout for some new and inspirational way to help users find the content and features they are looking for. And based on my personal style and what I feel are best practices for the domain I focus on (enterprise web-based applications and websites), I gravitate towards simple, clean, and efficient methods.

Yesterday a design student that I'm mentoring (thanks Kelsea!) showed me the Maroon 5 website and I was really impressed. I'm not concerned with the implementation, which in this case happens to be Flash. I'm focused on the concept. The designer used a very simple geometrical shape with a strong color to draw attention to navigation that "appears when you need it". You can quickly find the navigation anchor--an orange triangle in a sea of grey/black--but the choices remain hidden allowing the content to dominate and show through.

When you move your mouse over the image the navigation menu appears:

In another part of the site it is done slightly differently. The orange bar is dropped and the navigation text floats over the background:

Excellent job!

If you know of any other really creative navigation methods, please reply to this post and share with the other readers.

UT Austin MBA Interview on Creativity

2008-02-13T23:56:00.005-06:00

I was recently interviewed by a student in the University of Texas at Austin MBA program on creativity:

1. Do you find any business processes get in the way of creative ideas?

Not really. Deadlines and pressure are actually good for creativity. To create we must work within bounds -- limited possibilities do not strangle creativity, they make it possible.

2. What do you feel is the best method for fostering creative ideas?

I believe you must combine energy, pressure, and cross-disciplinary exploration. Energy in the form of excitement and drive to achieve, pressure to achieve something great within an ambitious time frame, and lastly the search for ingredients outside of our normal scope. We often create by taking a concept or idea from another discipline and twisting or turning it to fit our needs. There is so much that software designers can learn and be inspired by in the fine arts.

3. What is it that led you to a creative position, and how do you stay competitive?

I believe everyone is creative. No question. As for staying competitive, it's very simple -- you must apply yourself in ways that benefit the business. You must always keep your eye on the money. If I'm not wrong, I believe that much of the old masters' works were created based on what they were commissioned to paint; not whatever they felt like painting. Find the intersection between what you want to do and what will benefit your company or customers.

4. How do you measure the success of ideas?

With regard to the software we design, we actually have objective measures in place such as efficiency and effectiveness that help us to determine if we have improved a design. We also use less objective measures such as satisfaction surveys and word association exercises that provide us with good feedback.

5. How is creativity rewarded within your organization?

Creativity is rewarded at NetQoS by turning the right ideas into products or product features. I say the "right" ideas because not all creative ideas make business sense. I'm also reminded of a quote from Harry Truman: "It is amazing what you can accomplish if you do not care who gets the credit." For me, seeing my work in a product that people need to do their daily jobs is the ultimate reward.

6. Would you rather be in charge of a creative failure, or an ordinary success?

I'm not sure what an "ordinary success" is, but I would not be happy being in charge of a creative failure. No success in our business (high-tech software) is easy or ordinary.

TechSmith Interview on Morae Usability Testing

2008-01-17T13:25:00.001-06:00

TechSmith interviewed me about using their product Morae for usability testing: http://www.techsmith.com/morae/interview/rwilson.asp

Great post on interaction designers

2008-01-15T16:26:00.001-06:00

Worth reading: http://www.coroflot.com/creativeseeds/2008/01/sidestep_interaction_designers.asp

You get what you pay for!

2007-12-14T09:39:00.000-06:00

Nothing of value is free. Some may quickly point out that there are many valuable open-source products available for "free." But they aren't truly free. At the very least, they are sold for the fame of their creators. (I wonder what Linus Torvalds' net worth is as a direct result of creating and giving away Linux for free?) And many companies give away products, but with ulterior motives.

Furthermore, nothing of value is cheap! Or rather, "you get what you pay for." (Except when it comes to a certain plumber I know.) I read a report at a conference recently that explained why Walmart failed in South Korea--because South Koreans associate cost with value. Their perception of Walmart is that everything they sell must be poor quality given their prices.

Is a poor quality product better than no product at all? (Now that's a great topic for another post - let's not diverge.)

Back to the bottom line: Would you be willing to put your child on a life support system that was run by software freely downloadable off the Web? Would you fly in a plane powered by free software? Would you accept a pacemaker with free software in it? True, there may be situations where you can accept greater risk. If Microsoft Word crashes, it's not the end of the world (as long as I don't lose a large amount of work!). But would you trust an e-commerce application or your enterprise network--the lifeblood of your company--to free software?

My company, NetQoS, sells a NetFlow monitoring tool called NetQoS ReporterAnalyzer that helps network engineers spot and identify the source of problems on the network. It is not cheap, but it is the best product on the market in its category. Many man-years of effort in producing a product that is the best in several categories, including ease of use, scalability, reliability, and superior analysis have been invested into ReporterAnalyzer at great cost to NetQoS. We have worked with subject matter experts, conducted usability and field testing, observed users using the product, listened to users, and experimented with various prototypes and potential implementations before arriving at the current design.

This investment ensures users can quickly identify, understand, solve and even prevent serious problems that could cost millions of dollars! By investing heavily in the user interface, NetQoS has not only made the product easier to use, but has contributed to making its users more effective at their jobs. Increased efficiency, faster problem resolution and early problem prevention, and big savings!

Yes, there are a couple of cheap NetFlow reporting tools out there. There are even some free NetFlow tools. And they offer features and functionality relative to their price. Of course one might argue, "well, I only need X... I don't need all those other features..." And that may be true, and in that case the cheaper solution may be the right choice. But realize that not only are you giving up the extra features, you are also potentially sacrificing the quality of the features you need as well. The cost is not tied to quantity of features alone, but quality as well.

And just like the life support system running on free software, all is fine until something goes wrong, and then it's too late. And how will you know until it's too late? I'm really not trying to plug my company or say that free software is bad. Free software is a wonderful contribution for research, scientific experimentation, and many other domains. In fact, it can play a critical role in the advancement of many sciences where non-free tools are simply too expensive. In fact, I use free software every day!

But I wouldn't use it to run my company's life support system.

Fixing bugs is not equivalent to fixing design.

2007-11-30T16:37:00.001-06:00

I love cigars. I smoke about 1 per month as a treat. That may seem like nothing, but I really enjoy it. About 2/3 of the way through a good Rocky Patel, there is a moment of clarity. Greens become greener, blacks become richer and edges become sharper. A little Laphroaig doesn't hurt either.

It is usually at this point that I come to some realization. Tonight that moment was defined by frustration regarding misconceptions of software design.

I evangelize design daily. I argue for the importance of good design, justifying the investment in time and resources to design and build smarter. But recently I was told a story about the iPhone that illustrates one of the sources of the cautiously skeptical expressions of many business executives that I meet with.

Hardware mistakes are expensive; software mistakes are (relatively) cheap!

According to one person, much more design and testing work went in to the hardware of the iPhone than the software, and the reason given was because it is much more expensive and unacceptable to ship defective hardware than it is to ship flaky, buggy software. (I cannot verify the accuracy of this claim and truly wish I had real data to support or deny this.)

At Dux2007 in Chicago, I attended a workshop where I asked the group why we don't design software like we do hardware? Why don't we spend more time in prototypes, mockups, etc. One of the attendees, a software designer... said "because it's cheap to fix software problems - all you have to do is make a download available that resolves the bugs."

That's what so many executives are really thinking, aren't they? Build it, test it, get it
out the door, and then ship fixes as necessary. Time to market, fix later.

And herein lies the mistake: fixing bugs is not equivalent to fixing design.

True, bugs in software can be fixed easier and cheaper than bugs in hardware. But we’re not talking about bugs--we’re talking about DESIGN. You can’t fix a design with a download! Design is the essence of the product, how the product interacts with users, the personality of the product, the metaphors, etc.

Attempting to fix design in an update results in confusion, retraining, potential loss of trust, etc. The changes are too significant. Therefore redesign is often delayed until the next major release of the product, resulting in additional costs, potential loss of customer loyalty and the opportunity to “lock them in”, etc.

So, yes, software bugs can be remedied easier than bugs in hardware. But design problems in software are no easier or cheaper to resolve than hardware design flaws, and therefore we (software designers, creators, builders) must adopt better processes, principles, and expertise towards designing better software products from the start.

Promoted to Vice President, Product Design

2007-11-27T09:34:00.001-06:00

I'm happy to announce that I have been promoted to Vice President, Product Design at NetQoS.

See:
http://www.netqos.com/company/management.html#Russell_Wilson
http://www.netqos.com/newsroom/press_releases/2007/11-27-07.html

The formation of this role elevates the importance of design within our company and further communicates to the industry the growing need for design leadership in software development. It is my belief that senior and executive level design positions will be standard roles in software organizations within the next 5-10 years.

Selected in the top 100 design blogs!

2007-10-15T20:38:00.001-05:00

I am honored to announce that Dexo Design made it on the list of the Top 100 User-Centered Blogs/!

Dexo was selected among other world class design blogs such as Functioning Form, Adaptive Path, Boxes and Arrows, A List Apart, UX Matters, Zeldman, Meyer Web, Keith Instone, Design By Fire, Louis Rosenfeld, Usernomics, Experientia, Information Aesthetics (one of my favorites!), Alertbox, and many more...

What do we mean by software design?

2007-10-11T22:46:00.001-05:00

Design is a broad term.

Some claim that everyone designs, and depending on exactly how you define design, that may be true. Not surprisingly though, many professional designers react uncomfortably to this. It helps me to distinguish between being creative and designing. Creativity is a free-form process that anyone can participate in. We are all creative in some way or another. But professional design is a discipline where experience, talent, techniques, tools, and skills are applied to synthesize and articulate fuzzy creative ideas into something usable.

There are many facets to that “something usable” though: the interior, the exterior, how it looks, how it performs its function, and so on. With regard to software there is database design, object-oriented design, web service design, interface design, navigation design, and visual design, just to name a few.

Why differentiate? Why distinguish between database design and visual design? It’s all design right? Because the talents, techniques, and tools required vary drastically among them. And we have people who refer to themselves as “designers” mixing with software engineers or programmers resulting in confusion about who is responsible for and designing what.

To help this issue, we can group the various design disciplines without over generalizing too much. “Front-end” and “back-end” are common terms used to separate the interface from underlying code – the code that makes everything work. It’s not bad I suppose and it has the advantage of already being used and understood (to some degree). But more appropriate terms would be “interactive design” and “functional design”.

Interactive design encompasses visual design, interaction design, user research, information architecture, information design (not database – the user representation and visualization), and usability. Interactive design is about the user experience, what the user sees and interacts with: form and behavior. Alternatively, functional design is about the underlying architecture and foundation to support and deliver the user experience.

Historically, we’ve done a good job on functional design. That’s what software development has been all about. I can’t count the times in the past I’ve heard “just slap a GUI on it and we’re ready to ship!” (You would never hear that in automotive design, would you?). As users’ expectations have increased thanks to experience with well designed software (they didn’t know what they were missing) and the natural evolution and maturing of software development, interactive designers are slowly being recognized as critical to world-class software development.

So, by software design we mean interactive design and functional design; equally important, but drastically different.

Career Paths for Software Designers

2007-09-13T22:07:00.001-05:00

There are two career paths for software designers: the path to creative leadership and the path to executive leadership.

Which path is right for you? Let me outline some of the pros and cons of each:

Creative Leader	Executive Leader
Pros: Flexible & unencumbered Follow your passion	Pros: Member of executive team Political influence
Cons: Less political power	Cons: Not an individual contributor Management The business side

As a "creative leader" you will drive design from the top and be expected to contribute directly yourself. You will have flexibility and you will be unencumbered by the management duties typical of high-ranking executives, freeing you to "create." You will be expected to produce, to evangelize, and possibly to write or speak at conferences. However, while being seen as the "brains" behind design, you may also be somewhat dismissed by corporate executives as having very little "business" knowledge, and therefore very little input into corporate strategy and sometimes even product strategy.

As an "executive leader" you are expected to understand the business-side; market drivers, profit/loss, etc. and most importantly be skilled and effective in management -- a task many up and comers are often shocked to find so difficult and taxing. The more people you manage, the less you contribute yourself. The executive leader enjoys a more standard position in the corporate power hierarchy and therefore will wield more strategic power and influence.

Creative and executive leaders hold varying titles depending on the company. Some examples include:

Creative Leader
Creative Director
Chief of Design
Chief Designer
Principal Designer

Executive Leader
VP Product Design
Director Product Design
Design Director
VP User Experience
Chief Design Officer

The choice of which path to follow can be difficult if you want to remain an individual contributor and focus on design, but also want to have strong political influence in product strategy and mix with the rest of the company's executive team. There may be hybrid roles that combine these two to some degree, but I question their ultimate effectiveness.

So, ultimately the question you have to ask yourself is whether you want to create and lead through design, or build and design through leadership? Or, more simply, do you want to push yourself as a creative or push yourself as a business-leader?

New word: Criticallous

2007-09-05T00:32:00.002-05:00

New word: Criticallous

From critical (inclined to criticize severely and unfavorably) and callous (feeling or showing no sympathy for others).

Function: adj

1. Used to describe someone who is both harshly critical and seemingly lacking in empathy. For example: "Joe is so criticallous in every design meeting we have; it makes it hard to brainstorm."

criticallous

The biggest usability bug in Windows

2007-09-04T11:36:00.002-05:00

It seems that a part of human nature is to accept things as they are and adapt accordingly. This can be both a strength and a weakness. With regard to tools and products, we use what we have, most often accepting the shortcomings, until someone comes along and invents something better or makes an improvement. And then we examine the new product or improvement in awe, wondering why we didn't think of it, surprised at how obvious it is in hindsight.

It is not easy to remove oneself from the everyday flow of life, from the behavioral patterns we form and adaptations we make, to acknowledge the problems and ask "how can this be better?" And yet, this is the space where designers should spend a great deal of time.

To that lofty end, I'm going to step down from my dramatic soliloquy and ask "Why in the name of all that is holy does it have to take so long to start Windows?"

I, like many others I'm sure, use my computer for hours and hours every day. And one of my chief frustrations is waiting for my laptop to start up, and for that matter shutdown. Because I use a laptop, I start up and shutdown often. This isn't as much of a problem for desktop users who leave their computer running, but when the power goes out or you have to install new software, prepare to wait.

And why should this be acceptable? Would it be acceptable if it took a web site 5min to load? Would it be acceptable if it took your camera 5min to start? What about your TV? Your washing machine? Your car? We have adapted and come to accept it as "the way it is", but I argue that it is the biggest usability bug in Windows! To be fair, this problem isn't limited to Windows. I don't use a Mac, so I can't compare, but I'm sure it doesn't turn on instantly.

If it were up to me, I would have a team working around the clock on a solution for instant-on/off computers. I'm sure it's not an easy problem to solve, but a fix for this unacceptable bug would have a tremendous impact on productivity and the entire user experience surrounding computers.

The rise of the design executive!

2007-08-30T22:45:00.001-05:00

Two noteworthy articles, and harbingers for the rise of the design executive were published this August:

Wanted: VPs of Design (Businessweek, Aug-07)
Enter the chief design officer!: hail to the chief! (ACM Interactions, Aug-07)

Motivated by these articles, I did a quick Google search on “vice president of user experience” and found this role at several well known companies including Google, Yahoo, eBay, Microsoft, and Oracle, as well as countless lesser-known and smaller companies. I didn’t bother searching other possible titles.

It’s apparent that companies are beginning to recognize the value and need for design leadership as an integral part of the executive team. More so than ever before users demand more from products, and if a company is looking to achieve competitive advantage, innovate, and be an industry leader, it must elevate design as part of its strategy.

Prioritizing Design in Successful, Legacy Applications

2007-08-25T21:26:00.001-05:00

Ben Erwin, one of the product managers I work with (and a good friend) at NetQoS writes:

Maybe I’m the only one who has this problem? It figures. It’s obvious that the design team for my product line struggles with showing value to our company. But can you really blame the company? After all, product designers are sissy artists only concerned with colors and whether or not the horizontal navigation properly aligns with the banner bar. That was sarcasm…so please stop crafting the hate mail message that just popped into your brain. As a product manager, I have the upmost respect for product design. They have treated my customers with some very sexy (technical term for us ignorant folks when describing good design), well-designed software that continues to receive “oh’s” and “ah’s” from the market.

But those “oh’s” and “ah’s” fade fast. They just don’t seem to stick in the mind of sales, marketing, and software engineering. This lack of “stickiness” is primarily because customers keep banging the drum for more tangible features – features they think they *want* but not necessarily features they *need* (but that’s a whole new topic for another post). Not a week goes by where a sales person walks in my office and politely demands some new widget report. If I can’t deliver the report, XYZ Co. won’t buy our product, therefore the company won’t meet its revenue target for the quarter, therefore we all lose our jobs, and therefore we’re all homeless. No one ever comes into my office making the homeless argument because XYZ Co. wants better workflow in the product or is halting the deal because of the lack of aesthetic appeal in the UI. Sure there are complaints about these items but it’s never the priority. The priority is what the customer thinks they want before purchasing the product. That’s their buying criteria and subconsciously all of the sissy design stuff can come later.

To make matters worse for our product design team and their fragile egos, our products are legacy and very successful. This success was built with little to no expertise in product design and this success continues today, although we have injected some product design expertise into product development. Therefore, it’s difficult to separate what’s really driving the success. Is it the new, streamlined, and sexy interface that product design contributed to the product? Or is it the new widget data collection module we implemented too? Maybe it’s both? Unfortunately, the both argument dies quickly with the reminder of the company’s success before implementing design expertise and garnering the “oh’s” and “ah’s” from customers.

All of this rambling really boils down to a simple question: What is design’s impact on the bottom line? And a few follow-up questions: How do you prove it? We all know it is part of the bottom line somewhere but can you tie product revenue to it? Without question the customer’s experience with your product improves with the addition of capable product designers who focus on the aesthetic appeal and usability of your product. But that experience is hard to put dollar signs against. When the company thinks back about how we closed the XYZ Co. account, it’s because software engineering cranked out the widget report in the nick of time without product design slowing them down. And thank goodness…otherwise we’d all be homeless. Praise software engineering and sales! By the way, why do we need product design again?

Again, maybe I’m the only sucker out there looking for answers. It could be an issue of my product’s market. Maybe product design becomes an obvious competitive differentiator as the competition begins to catch up. Hopefully I’m not alone; otherwise you just wasted a lot of valuable time reading this post – sucker! Again…that was sarcasm. However, I do see a lot of successful, legacy products on the market that are just plagued with poor design – they just ain’t sexy. Are these companies going to do anything about it?

Why Microsoft's ribbon sucks

2007-08-25T01:42:00.001-05:00

Bottom line, I have a lot of respect for Microsoft and many of the outstanding people that work there (e.g. Bill Buxton).

But the new ribbon sucks.

I've been using it daily for months (Word, Powerpoint, Excel), and I consistently stumble on the same functions over and over again. I doubt I will ever master it. And I'm an interface designer!

When I want to center text both horizontally and vertically, I can always find the horizontal centering, but have to search for quite some time to find the vertical centering.

I consistently to this day scan all of the available options in the ribbon looking for things.

Just yesterday I couldn't figure out how to change the paragraph style for some text without looking for 3 to 4 minutes.

When I want to print a page, I have to remind myself that it's under the big Microsoft circle button. And there are so many more...

Bottom line, for me at least, nothing is automatic. Nothing is natural. Learnability is poor. It's as if I'm looking at a bag of goodies and my eye has to scan through all of them to find the particular piece of candy I want.

If the problems were all a result of change, that would be one thing. But I've been using Office 2007 long enough to exclude change as a problem. If the changes were learnable I would have certainly learned them by now. I believe the problems stem from the following:

1) visual density/complexity

There is just too much to process on the screen. It's a Swiss Army Knife with every tool exposed (well, not all of them). Not only is it too much, but the density, the proximity and variety, make it difficult to process quickly or to associate a function with a location. For example, it's impossible to mentally associate upper-middle with paragraph styles because upper-middle is too broad and would include many other functions. My mind must process the ribbon each time rather than jump to a location.

2) anticipated functionality

The designers chose (through testing and usage data I'm sure) what functions to display prominently and where to display them. Whatever criteria they used leaves me with less than half of what I need visible on the screen at any given time to accomplish what I need to do. So I wind up searching for what I need -- everytime. In my experience, anytime I'm asked to anticipate what users will want to do, I hesitate. True, very often you have to do it to some degree, but it's challenging to get right. And the degree to which this was done with the ribbon, in my opinion, made it an impossible goal to achieve.

We (designers) all make mistakes. I recently designed a navigation system that I thought was innovative and efficient. In testing it failed miserably and I had to redesign it. What amazes me given what I know about the Office redesign, and the amount of work that went into it (along with the great minds that contributed), is that they must have gotten good test results and I can't fathom how. I personally would have failed.

I would love to hear comments from others on their experiences. I haven't heard many positive remarks personally (except regarding the context-sensitive right-click menus, which I think are excellent).

Consistency and Conceptual Integrity

2007-08-21T09:42:00.001-05:00

If consistency is your goal I doubt you will ever produce world-class designs.

The importance of consistency, and what consistency really means with regard to software design, has to be one of the most misunderstood and misapplied principles. I am constantly tortured with "well, Microsoft does it like this – why don't we just copy that? It would be consistent with what users expect.", and "let's make this control look like this other one to be consistent".

With this modus operandi, how can you ever expect to innovate?

Consistency is not about copying existing designs to shortcut necessary creative work (Note: I'm not talking about looking to other designs for inspiration). True, this can be used effectively, and may even be a good idea in some cases – there are many great designs out there worthy of mimicry! But it should not be a standard practice. Should every car look like a Honda? Should every tool in your garage have the same handle?

Should form follow function, or form follow form?

Maybe we should create a standards committee that specifies how all buttons should look and behave; then when someone develops a new software application, they can go to a website and download all the controls they need to build it. Over time all software products will look and behave exactly the same and our users will be much happier, right? I don't think so.

And even more importantly, consistency does not mean sacrificing usability for the sake of code reuse! Again, I am a practical designer; I understand the various business and engineering considerations (time to market, cost, etc.). I'm not advocating reinventing the wheel. But I certainly don't think that a bicycle, motorcycle, van, or high-performance sports car should all share the same wheel design either! Code reuse should be leveraged whenever possible but it has to be weighed against other considerations such as basic usability, existing metaphors and mental models, etc.

So, how can one apply consistency correctly? By thinking in terms of "conceptual integrity," a slightly more abstract concept coined by Frederick Brooks in The Mythical Man-Month. CI means that the software system as a whole should reflect one vision and should fit together seamlessly and flow naturally. This will require consistency throughout the system, but it will not be the driving force. The usage of the system is the first consideration and consistency is applied to support this.

Form follows function and then goes through the consistency/best-practices and usability testing ovens to create the final product.

The Politics of Design by Paul Rand

2007-08-14T16:48:00.001-05:00

Andrei Herasimchuk posted Paul Rand's "The Politics of Design" on the IxDA mailing list earlier and I couldn't resist reposting it here. A great reference for any designer dealing with large teams and corporate environments.

Courtesy of Andrei Herasimchuk

The Politics of Design

It is no secret that the real world in which the designer functions is not the world of art, but the world of buying and selling. For sales, and not design are the raison d'etre of any business organization. Unlike the the salesman, however, the designer's overriding motivation is art: art in the service of business, art that enhances the quality of life and deepens appreciation of the familiar world.

Design is a problem-solving activity. It provides a means of clarifying, synthesizing, and dramatizing a word, a picture, a product, or an event. A serious barrier to the realization of good design, however, are the layers of management inherent in any bureaucratic structure. For aside from the sheer prejudice or simple unawareness, one is apt to encounter such absurdities as second guessing, kow-towing, posturing, nit-picking, and jockeying for position, let alone such buck-passing institutions as the committee meeting and the task force. At issue, it seems, is neither malevolence nor stupidity, but human frailty.

The smooth functioning of the design process may be thwarted in other ways, by the imperceptive executive, who in matters of design understands neither his proper role nor that of the designer; by the eager but cautious advertising man whose principal concern is pleasing his client; and by the insecure client who depends on informal office surveys and pseudo-scientific research to deal with questions that are unanswerable and answers that are questionable.

Unless the design function in business bureaucracy is so structured that direct access to the ultimate decision-maker is possible, trying to produce good work is very often an exercise in futility. Ignorance of the history and methodology of design -- how work is conceived, produced, and reproduced -- adds to the difficulties and misunderstandings. Design is a way of life, a point of view. It involves the whole complex of visual communication: talent, creative ability, manual skill, and technical knowledge. Aesthetics and economics, technology and psychology are intrinsically relate to the process.

One of the more common problems which tends to create doubt and confusion is caused by the inexperienced and anxious executive who innocently expects, or even demands, to see not one but many solutions to a problem. These may include a number of visual and/or verbal concepts, an assortment of layouts, a variety of pictures and color schemes, as well as a choice of type styles. He needs the reassurance of numbers and the opportunity to exercise his personal preferences. He is also most likely to be the one to insist on endless revisions with unrealistic deadlines, adding to an already wasteful and time-consuming ritual. Theoretically, a great number of ideas assures a great number of choices, but such choices are essentially quantitative. This practice is as bewildering as it is wasteful. It discourages spontaneity, encourages indifference, and more often than not produces results which are neither distinguished, interesting, nor effective. In short, good ideas rarely come in bunches.

The designer who voluntarily presents his client with a batch of layouts does so not out prolificacy, but out of uncertainty or fear.
He thus encourages the client to assume the role of referee. In the event of genuine need, however, the skillful designer is able to produce a reasonable number of good ideas. But quantity by demand is quite different than quantity by choice. Design is a time-consuming occupation. Whatever his working habits, the designer fills many a wastebasket in order to produce one good idea. Advertising agencies can be especially guilty in this numbers game. Bent on impressing the client with their ardor, they present a welter of layouts, many of which are superficial interpretations of potentially good ideas, or slick renderings of trite ones.

Frequent job reassignments within an active business are additional impediments about which management is often unaware. Persons unqualified to make design judgments are frequently shifted into design-sensitive positions. The position of authority is then used as evidence of expertise. While most people will graciously accept and appreciate criticism when it comes from a knowledgeable source, they will resent it (openly or otherwise) when it derives solely from a power position, even though the manager may be highly intelligent or have self-professed "good taste." At issue is not the right, or even the duty, to question, but the right to make design judgment. Such misuse of privilege is a disservice to management and counterproductive to good design. Expertise in business administration, journalism, accounting, or selling, though necessary in its place, is not expertise in problems dealing with visual appearance. The salesman who can sell you the most sophisticated computer typesetting equipment is rarely one who appreciates fine typography or elegant proportions. Actually, the plethora of bad design that we see all around us can probably be attributed as much to good salesmanship as to bad taste.

Deeply concerned with every aspect of the production process, the designer must often contend with inexperienced production personnel and time-consuming purchasing procedures, which stifle enthusiasm, instinct, and creativity. Though peripherally involved in making aesthetic judgments (choosing printers, papermakers, typesetters and other suppliers), purchasing agents are for the most part ignorant of design practices, insensitive to subtleties that mean quality, and unaware of marketing needs. Primarily and rightly concerned with cost- cutting, they mistakenly equate elegance with extravagance and parsimony with wise business judgement.

These problems are by no means confined to the bureaucratic corporation. Artists, writers, and others in the fields of communication and visual arts, in government or private industry, in schools or churches, must constantly cope with those who do not understand and are therefore unsympathetic to their ideas. The designer is especially vulnerable because design is grist for anybody's mill. "I know what I like" is all the authority one needs to support one's critical aspirations.

Like the businessman, the designer is amply supplied with his own frailties. But unlike him, he is often inarticulate, a serious problem in an arena in which semantic difficulties so often arise.
This is more pertinent in graphic design than in the industrial or architectural fields, because graphic design is more open to aesthetic than to functional preferences.

Stubborness may be one of the designer's admirable or notorious qualities (depending on one's point of view) -- a principled refusal to compromise, or a means to camouflage inadequacy. Design cliches, meaningless patterns, stylish illustrations, and predetermined solutions are signs of such weakness. An understanding of the significance of modernism and familiarity with the history of design, painting, architecture, and other disciplines, which distinguish the educated designer and make his role more meaningful, are not every designer's strong points.

The designer, however, needs all the support he can muster, for his is a unique but unenviable position. His work is subject to every imaginable interpretation and to every piddling piece of fact- finding. Ironically, he seeks not only the applause of the connoisseur, but the approbation of the crowd.

A salutary working relationship is not only possible but essential.
Designers are not always intransigent, nor are all purchasing agents blind to quality. Many responsible advertising agencies are not unaware of the role that design plays as a communication force. As for the person who pays the piper, the businessman who is sympathetic and understanding is not altogether illusory. He is professional, objective, and alert to new ideas. He places responsibility where it belongs and does not feel insecure enough to see himself as an expert in a field other than his own. He is, moreover, able to provide a harmonious environment in which goodwill, understanding, spontaneity, and mutual trust -- qualities so essential to the accomplishment of creative work -- may flourish.

Similarly, the skilled graphic designer is a professional whose world is divided between lyricism and pragmatism. He is able to distinguish between trendiness and innovation, between obscurity and originality.
He uses freedom of expression not as a license for abstruse ideas, and tenacity not as bullheadedness but as evidence of his own convictions. His is an independent spirit guided more by an "inner artistic standard of excellence"(1) than by some external influence.
At the same time as he realizes that good design must withstand the rigors of the marketplace, he believes that without good design the marketplace is a showcase of visual vulgarity.

The creative arts have always labored under adverse conditions.
Subjectivity emotion, and opinion seem to be concomitants of artistic questions. The layman feels insecure and awkward about making design judgments, even though he pretends to make them with a certain measure of know-how. But, like it or not, business conditions compel many to get inextricably involved with problems in which design plays some role.

For the most part, the creation or effects of design, unlike science, are neither measurable nor predictable, nor are the results necessarily repeatable. If there is any assurance, besides faith, a businessman can have, it is in choosing talented, competent, and experienced designers.

Meaningful design, design of quality and wit, is no small achievement, even in an environment in which good design is understood, appreciated, and ardently accepted, and in which profit is not the only motive. At best, work that has any claim to distinction is the exception, even under the most ideal circumstances. After all, our epoch can boast of only one A.M.
Cassandre.

- Paul Rand
from "A Designer's Art"

(1) Anthony Storr, "The Dynamics of Creation", (New York, 1972), 189.

The problem with sketching

2007-08-12T13:03:00.001-05:00

This past June I attended UPA's 2007 conference in Austin, Texas. The keynote was given by Bill Buxton, Principal Researcher, Microsoft Research. The focus of Bill's presentation was on "sketching", a timeless core tool for creative design, that in software design is often bypassed in favor of high fidelity digital design tools. He presented two points regarding sketching that made a strong impression on me:

No higher resolution than required to communicate the intended purpose/concept
Resolution of the rendering does not suggest a degree of refinement of the concept that exceeds its actual state

(directly from Bill's presentation)

Since the conference, I've been evangelizing this concept internally to my team (product design) as well as to product management and development. But I've hit a few snags in the fast paced world of software development. Namely:

1) High fidelity sells, low fidelity is dismissed
With many projects facing complex priorities, deadlines, demands from the sales team, and countless other inputs, rough sketches are often not compelling and are easilly overlooked or dismissed. A picture is worth a thousand words, but only if the picture is pretty. I constantly push back on higher resolution early on, but without higher resolution often the project doesn't get started in the first place. It's as if a high resoluton rendering is needed to inspire interest only to be trashed and reworked through the correct sketching process once the project gets moving.
2) High fidelity communicates a solution, low fidelity communicates a work in progress (which is good for exec's, but problematic for development)
Here's one that's a little controversial (until you understand what I'm really trying to say). Low fidelity (rightfully so) communicates an unfinished design; a work in progress. And as Bill states, this is what you want... if your audience is marketing or decision-making executives. But with development it can be a little tricky. When we present something polished looking to development, even if it's not completely fleshed out, their reaction tends to be "that looks awesome - when can we get this from you so that we can plug it in." When we present a sketch or something rough, the reaction is often to go and try to do it themselves. In some situations this could be a good thing, and may be exactly what Bill is advocating for -- the roughness promotes others to think and contribute their own ideas instead of assuming it's already done. But in some cases unfortunately, it doesn't promote collaboration -- development just picks up the ball and runs with it without ever looking back. Yes, I know, it's a problem with process and culture. But if it exists, it exists, and until it has been fixed, it throws a wrench into the design-sketching process.

Challenges to world class software design

2007-08-08T22:37:00.001-05:00

Every job has its challenges. As a programmer, I spent long hours fixing bugs and finding workarounds. As an engineering executive, I dealt with resources, schedules, and politics. And as an entrepreneur, I struggled to find customers and generate revenue.

But designing software is tough. I’m not talking about the creative work – that’s our passion and we love it. I’m referring to the “tax” we pay for doing what we love.

So what makes up this tax? What challenges am I referring to?

1) Everyone thinks they are designers

Developers, product managers, sales, and even customers, can’t resist their own needs to create or invent by suggesting ways to change an interface or add capabilities – “let’s just add a drop-down to the top…”. Either in the form of “design on the spot” during a product meeting or customer visit, or a developer going ahead and “fixing the problem” without waiting for input from design, it happens often, and reflects perceptions and lack of understanding of the design role and expertise. It can also reflect poor adherence to process, or lack thereof, and a need for cross-department executive sponsorship and continued support. (I am not suggesting that no one can give input to the design process; many of our best designs are the result of collaborative efforts with product management and sales.)

2) Design is a nice to have

I’m always perplexed by this one, but many bottom-line executives still perceive good design as a nice to have. No, not at Apple or Intuit (I see more design-related job postings from Intuit than any other company – it makes me wonder if they just want to interview everyone they can, or if Intuit has a Wonka factory somewhere full of designers dressed like ump lumpas, all building accounting applications). Apple and others have helped to move this forward, but I still run into the skeptical eye from time to time. Another manifestation of this is when a new product or concept is attempted and the strategy is to “get something working, find some buyers, and then make it better.”

3) Who makes the final decision?

The Biltmore Estate is a remarkable architectural achievement, and is commonly considered the result of a single vision where the overall design was driven and conceived by one person. Frederick Brooks states that “conceptual integrity” is the single most important factor in the development of successful software applications. But often, with software design, there are many stakeholders, business and marketing agendas, and the need to create something as soon as possible. The nature of software design and development within high-tech companies doesn’t seem to lend itself to the purity or grandeur of a project like the Biltmore where the “genius” is given free reign to produce a work of art. It’s difficult to find the right balance between art and business in software design, and this is evident in the careful politicking among the design executive and various stakeholders to decide what gets built and what doesn’t.

4) The difficulty in justifying designs to critics

True, the best justification comes from users, and you can get that (to some degree) from usability testing -- assuming you have the time and resources to conduct formative testing. But what about colors? What about visual treatments that are more subjective? What do you do when the product manager says “I hate that blue -- why do we have to use that blue?” (I recently emailed a color wheel to a large group of employees at our company - that was a big mistake.) There are many cases where I wish I could just say “just do it that way, trust me!” My boss suggested that I respond with a standard “thank you for your input” for things such as this.

Well, those are some key ones, but I’m sure I’ve missed several. I invite anyone who reads this to submit their own design challenges. This is a work in progress and I intend to update it with the best ways to address these challenges.

Why usability is a path to failure (or "Usability is not design")

2007-08-06T12:24:00.001-05:00

What a great title for soliciting feedback and blog traffic! The article makes a good point though -- focusing on usability (alone) is operational, not creative... not design. (I have a best-practices checklist that I review when we create new designs.) I just hope that the title doesn't lead to misinterpretation of the importance of usability.

Usability is not design -- usability is testing designs and making sure that they satisfy certain criteria.

http://www.adaptivepath.com/blog/2007/07/17/why-usability-is-a-path-to-failure/

The same, or different, but not similar!

2007-08-03T16:38:00.001-05:00

Inspired by a post from Michael Tuminello in response to a question I had on the IxDA list, I propose this rule of thumb: "The same, or different, but not similar!"

The concept that Michael discussed (and I have said in the past in different terms), is that when designing, controls/patterns for similar functions across products (or even within the same product) should either be exactly the same (consistent) or vastly different. But they should never be "similar". Being similar will result in many more usability issues than being entirely different where the user does not have certain expectations for behavior.

Selecting reporting time frames should be consistent across a suite of reporting products. If one product has vastly different constraints on time selection, requiring a different time selection mechanism, it should be obvious to the user that they are working with a completely different control with different behavior.

Design Tools

2007-08-02T14:14:00.001-05:00

I am often asked what tools I prefer to use in designing user interfaces. I do believe that there isn't a "best" tool. True, some tools are better at some tasks than others, but it really comes down to what tool works best for you. I've seen designers produce excellent interaction designs with Microsoft Powerpoint. If you are fast and comfortable with a tool, use it. And if you want a better tool, you have to weigh the cost of learning something new against the benefits. Personally, I'm an early-adopter, gadget-freak, bleeding-edge, over-70-feeds in my news reader type, so I love to experiment with new tools to study their interaction patterns as well as discover what new capabilities I might pick up.

My current list of design tools:

Concept exploration: CmapTools, MindManager, Pen & Paper

Interaction design: Pen & Paper, Microsoft Visio, Adobe Dreamweaver, Adobe Flex/AIR

Prototyping: Adobe Flex/AIR, Adobe Flash, Adobe Dreamweaver

Visual design: Adobe Illustrator, Adobe InDesign, Color Schemer

Usability testing at conferences

2007-07-29T23:39:00.001-05:00

I just returned from the Cisco Networkers 2007 conference in Anaheim, California where we tested various designs in two of our products on 45 network engineers. Testing users at the right conferences has become very successful for us. First, it is very easy to recruit participants. Second, the conference attendees happen to be our target users!

We reserved a conference-floor meeting room (which was included in the cost of our company’s booth) for the actual testing. We rented two monitors and had one power strip. Internet connectivity was not necessary for our testing, but we could have used wireless (for free) if we needed to. We shipped two servers and two desktops, with mice and keyboards, and an 8-port switch. Each of the desktops had Morae Recorder installed as well as an in-house Adobe AIR (formerly Apollo) application I wrote to allow users to pick descriptive words they would associate with the products after the test (thanks to Microsoft for the idea). We had everything up and running within an hour of carrying the boxes to the testing room. This setup gave us the capability to test two participants at once which increased our efficiency and allowed us to conduct more tests during open hours.

The tests were structured to take no more than 30 minutes, and would consist of several tasks with participant-tester interaction, followed by a SUS satisfaction survey, and the Apollo/AIR reaction-card application. In past testing sessions I would give participants tasks and then silently observe with very little interaction, but this time I decided to make the task-portion more interactive and I’m much happier with the results. At the risk of disturbing their natural problem-solving flow, the feedback we recorded provided us with excellent insight into positives and negatives with the designs: what was working and what wasn’t.

When it came time to recruit volunteers, I asked all of our booth presenters to add a slide to their presentations about the usability testing we were doing at the conference. I also offered anyone who would participate a $50 American Express gift card. I wondered whether it was too much, but surprisingly, it was still challenging to get people to sign up. Ultimately we filled every available slot we had, but not without some work (I recruited 3 people while riding the buses back and forth to the convention center).

All in all, it was a great success and provided us with valuable feedback and insight that we will take back to R&D and consider over weeks to come. Several small changes will be made resulting in a much better product prior to release. And despite all the positives I’ve discussed, there were some drawbacks to testing at a conference. Namely the noise, even inside the meeting rooms, as well as the general excitement level (it’s not exactly a “relaxed” setting). But at least for us, the positives far outweigh the drawbacks. And the final price? Here it is (rounded up)..

#3 has arrived!

2007-07-19T11:53:00.001-05:00

P1011035
Originally uploaded by ixdes

Noa Loren Wilson
June 4, 2007
7lbs 2ozs

Prioritizing product ideas

2007-07-16T13:18:00.001-05:00

Adam Polansky from boxesandarrows describes a method for prioritizing product ideas called “Faceted Feature Analysis”. I particularly like the idea of giving independent voices to development, business, and user experience as part of the process. - Russ

http://www.boxesandarrows.com/view/faceted-feature