Use Case Diagrams

Projects start off at the 60,000 foot level -- the client wants a widget that allows their users to do X, Y & Z -- and need to be brought down to a level of detail where coding can begin. Something I use to start this process is a version of the UML Use Case Diagram.

UsercasediagramFor those of you not familiar with it, a Use Case Diagram describes the needed functionality in a system. Unlike flow diagrams, however, the use case diagram doesn’t represent the order or number of times the functionality needs to be executed and it doesn’t display any subroutines. Instead, it’s a high level diagram that identifies the primary tasks an actor/persona needs to be able to do.

The beauty of this diagram is that you’ve now captured the overall view of what the system needs to be able to do in order to allow the user to complete all their tasks. With the high level activities clearly identified, the diagram easily lets you communicate with your client and get their sign off that the needed functionality has been accurately captured. From here, the team can move onto further defining what’s needed to support this functionality: data modeling, user stories, task flows, etc.

The Curse of Knowledge

You can never know too much about something, right?  Wrong, at least according to a December 30th article in the New York Times.  As we become experts in a particular domain, our ability to innovate diminishes.
"Andrew S. Grove, the co-founder of Intel, put it well in 2005 when he told an interviewer from Fortune, “When everybody knows that something is so, it means that nobody knows nothin’.” In other words, it becomes nearly impossible to look beyond what you know and think outside the box you’ve built around yourself."

Reading the article, I couldn't help but think back to my own experiences with this same sort of issue.  I blogged recently about two related ideas: how interface designers are sometimes guilty of thinking as designers--when they should be thinking as users, and about the mixed bag that is competitive research, which can limit the designers creative thinking by boxing them into predefined solutions.   

Now I see that it's part of a larger problem of expertise and creativity.  The more expertise one exhibits in a particular field, the harder it is to think creatively--to so called think 'outside the box', and the harder it is to imagine not knowing what you do.  The problem affects whole companies, as a certain way of thinking becomes entrenched, and it gets harder for it to adapt to a changing landscape.  The article cites the example of Eveready, the flashlight maker, who's powers-that-be couldn't imagine that their product could be effectively marketed to anyone other than men shopping at hardware stores.

According to Cynthia Barton Rabe, author of “Innovation Killer: How What We Know Limits What We Can Imagine — and What Smart Companies Are Doing About It,” the solution for Eveready, as for any organization bogged down in its own expertise, is an infusion of outside thinking.  Bringing the so called novices--the non expert users--into the discussion at the early stages of design, weather it be product or strategy design, opens the door for new ways of thinking that experts have long been insulated from.


    
     


Powered by ScribeFire.

Design can be Used for Good and Bad

Every so often I'm rudely reminded that much of the information I get comes from a source who's goal is to sell rather than inform.  It is those times that I'm also reminded of the critical role that design plays in supporting the goals of the organization (wether they be to inform or to sell) by shaping user behavior.

Case in point.  I use Yahoo Finance to track my stock portfolio and stay financially abreast of the day.   I choose Yahoo over the many others out there because I'm used to it.  It has a simple interface and I know where everything is located.  It also has great tools, and it aggregates information from many many other sources in one place, which I find invaluable.  However I just recently noticed that Yahoo Finance is serving some text ads on the site now.  I wouldn't otherwise be too bothered by them, but they've been designed for the express purpose of looking like real (un-sponsored) content.  They're right up there on the right hand side of the page, occupying the top of one column in a three column layout.  The ad titles are just about the same color as the headlines and links on the rest of the site.  And while the other section titles are all orange and bold--designed to give structure to the page and let you know what section your in-- the only way you can tell that your reading ads is from the truly inconspicuous (light-grey on light blue, thin, all caps) 'Advertisement' header.  

This really infuriates me, especially because it's a finance site, and I can't help but notice the content of the ads.  For instance, right now I'm looking at the front page, from left to right I see a snapshot of the Dow's performance today, a headline saying 'Stocks mixed ahead of jobs report' and a couple of blurbs on 'Hottest China Stock' and '16 Hot Dividend Stocks'.  Now I'm sure you can guess which ones are ads.  And yet I can't help but see the ads and incorporate them into my understanding of the days financial news.  They were designed to be scanned, and that's exactly the kind of information I need to be able to filter out when I'm scanning a page like this.

The fact that these ads persist is a clear indication that Yahoo is concerned less about an informed public and more about using its real estate to extract as much equity as possible.



Powered by ScribeFire.

Dasher - A new way to write

I simply love finding these little gems on my weekly web excursions.  This time it's a fascinating new piece of software out there called Dasher, and it allows you to write without typing or scripting.  What's that you say?  How else can you write?  Well...The basic idea is that current methods of typing are inefficient, because they don't learn.  Let me explain.  Although there are x number of letters in the alphabet, every pressed key reduces the number of available choices for the next key press, and increases the odds that other specific keys are pressed next.  For instance, 'E' is much more likely to be pressed after 'H' than 'B' is, and 'O' more likely after 'G' than 'C'.  On current writing technologies it's up to the user to learn to be more efficient at writing He than Hb or Go than Gc.  But that doesn't need to be the case.  By taking advantage of the learning and memorization power of the computer, it's possible to create writing interfaces that guide you through the process rather than just recording what you type.  If you'll indulge me in some metaphor, imagine rowing down a river.  Dasher is the river with a strong current to wherever your going, and existing typewriting technology is the river with no current whatsoever.   

Picture_4 What Dasher does is use language patterns to present likely letters and words to the user based on the letters or words they have already written.  The goal is to make writing more efficient by reducing work.  There are no keys to press using dasher.  In fact the mouse is never clicked.  The interface allows one to write by simply navigating the mouse down a path--or tree--through the alphabet.  The start screen displays all 26 letters of the English alphabet.  You select a letter by moving your mouse next to it.  As letters are selected, Dasher displays all available letters again, but this time those more likely to be chosen are larger and therefore easier to select.  As you write, you move forward through the tree, and entire words and phrases are displayed in order of likeliness.   

Dasher needs some work before I start using it instead of my keypad, but the idea has real merit, and it deserves to be explored more.  As an interface designer I see at this tool as a great example of how simple interactions, when thought about creatively, with nothing held sacred, can have potentially revolutionary effects on the way we interact with technology.
 
 

Powered by ScribeFire.

DUX2007 - Ubiquitous Computing

Adam Greenfield of NYU’s Interactive Telecommunications Program gave a great keynote presentation at DUX07 on ubiquitous computing -- embedded devices that are wirelessly networked, imperceptible, mobile and post-gui. Devices that are not perceived as computers by the people who use them, but rather as a facet of their lives. An example he cited is the Nike+ product for runners, which pairs with an iPod to give you feedback on how you’re running while you’re running and records info such as distance, time, etc. You can then sync your workout data to either iTunes or the Nike site, where you can then become part of the Nike+ community. It is a computer, but to most people it's just a piece of plastic you put on your shoe.

Ubiquitous computing. Existing or being everyware. Perceived as a facet of the user’s life. Eroding the distinction between product and service

Consider the automobile. When the first Model-Ts rolled off the assembly line, the car was a product. You drove it here and there and that was basically it. With the addition of On-Star, the car’s autonomy eroded as it was now networked with a diagnostic tool, roadside service, emergency contact, etc. The perception of a car as only a product began to erode as well; the car began to evolve to a platform. Fast forward a decade or so and we now have car as a service -- the Zip car. Glimpsing into MIT’s Smart Cities project, we begin to see the car as an interface to the city and not the engine.

As designers, then, our challenge is to design for these product/service ecologies.

Back to the Nike+:  although the device is basically a pedometer it only works for runners, not walkers. In addition, participation in the Nike+ community requires Flash because that's what the Nike site uses. This is a closed ecology and by their very nature, closed ecologies are brittle. Greenfield, therefore, advocates designing these products/services to use open frameworks because of their openness, their ability to be flexible and extensible. The downside of an open framework is a loss of control and for companies heavily vested in controlling their brand, this option may not even be considered. His argument, however, is that open frameworks aid in a product’s long-term viability.

Some final thoughts from Greenfield:

  • As designers, we can no longer assume that the product we design will be a standalone product.
  • Everything that can be networked, will be.

A final thought from me: it's an exciting time to be designing.


Technorati Tags: , , ,

DUX2007 - Data Visualization

Data visualization was touched upon a number of times throughout the DUX07 conference.

In David Pescovitz’ keynote address on Monday, he mentioned that since the 1980s we’ve seen three waves of technology: PC Computing, communicating, and sensing. We’re now in the fourth wave which is sense making -- how do we make sense of all the data that’s out there. How do we deal with search queries that return hundreds of thousand of lines of results. How do we start to make connections between the data.

One way we deal with sense making is through data visualization -- a concept which is starting to filter out beyond the research labs into the commercial space. Through data visualization, we can take huge sets of information and present them in such a way that it:

  • allows us to immediately see how items are related to one another;
  • gives us a more immediate way to see patterns;
  • becomes a default to try and understand huge amounts of information.

In addition to visualization, Pescovitz touched a bit on how we're using collective filtering to try and make sense of all this data. We turn to social networks we may trust, such as Digg, to take advantage of the filtering layer created by that network’s society. Anything to help us get a head start on parsing the data.

Later on in the conference, Nick Cawthon talked about aesthetics and efficiency in visualization of data. His talk referenced research he had done using different types of data visualization in order to determine what participants thought of the graphic (pretty or ugly) and whether or not it worked (they could complete a task such as finding a file). An interesting outcome was that the higher the user-rated aesthetic, the more reluctant the user was to abandon that particular data visualization. At a basic level, if the interactive graphic was perceived as “pretty”, the user was willing to spend a bit more time trying to learn how to use it.

Fascinating ideas and I know we're just scratching the surface of its potential.


Technorati Tags: , , ,

DUX2007 - Simplicity

Too often, the overarching requirement we hear from clients is that the product must be simple to use. As designers, we nod our heads and agree that yes indeed, simplicity is a worthy goal for this project, without ever defining what is meant by simplicity.

At the opening night of the DUX07 conference, B. J. Fogg, from Stanford University's Persuasive Technology Lab, talked to us for a bit via video about his recent explorations into simplicity. What exactly does simplicity mean? What are the determining factors of simplicity, i.e., what am I looking at in order to rate whether or not a product is simple to use?

To Dr. Fogg, simplicity is not a characteristic of the product but rather a perception of the experience. From his studies and research, he's determined there are six elements of simplicity:

  • time - can I spend the time learning to use a new product? no? then it's not simple
  • money - can I spend money on a new product?
  • physical effort - does it require exertion beyond my usual effort?
  • brain cycles - do I have to think for a long time?
  • social deviance - does it go against the social norm?
  • non-routine - does it break my routine?

These six elements vary by individual and by context and there are trade-offs. For example, if I'm a college student who has time but not a lot of money, I might be more willing to invest my time in learning a new product than, say, a business executive who doesn't have the time but would be more willing to spend a little more money on a product that doesn't require a lot of time.

Simplicity, therefore, is a function of the user's scarcest resource at the time. To state it another way: a product, task, etc., is truly simple until it requires a resources that's not available. But remember, Dr. Fogg said that simplicity is determined by the perception of the experience. Which means a task can be perceived as simple if it uses less resources than expected.

Now I'm not saying that from now on we market our products by setting the expectations high to guarantee the perception of simple .... but it sure is tempting.

Technorati Tags: , ,

Personas and Football

This year I’m once again in the Pick a Loser football pool*. Each week, I pick an NFL team that I believe will lose and if they don’t lose, I’m out of the pool. So, for example, the first week I selected my team, the Chicago Bears, to lose (so much for fan support). They complied so I'm still in play. I can only select a team once; therefore, da Bears are off limits for the rest of the season (even though I’m fairly confident they’ll lose another game or two).

My point here is not to kvetch about our quarterback (don’t get me started) or our running back (oy), but to mention that once you Pick a Loser, you start experiencing the NFL games a bit differently. It’s not that you’re actually outright rooting for them to lose (poor sportsmanship, old bean, not at all done), but you begin to look at which team excels in mishaps, penalties, and/or position weakness, or which team is thrown off stride by an unexpected change in personnel, and how you can exploit that to ‘win’ that week.

In other words, when picking a loser I am adopting a different persona than when I pick a team to win. I have different goals and objectives, looking at the stats (data) differently and end up going down a different path (workflow) to make my selection.

This, my friend, is the point of having personas on a project. You use them to identify the different ways a user needs to interact with your product -- their point of view determines the different paths and interactions they need to take in order to achieve their goals and objectives. Once you know the different points of view, it’s a lot easier to design a flexible workflow that accommodates your users. A win-win for all.

As for me, I survived week 2 (the Chiefs in case you're interested) and now need to figure out my week 3 loser.

*disclaimer: naturally for all the kiddies out there, you should never try this at home because gambling causes your hair to fall out


Technorati Tags: , ,

Powered by ScribeFire.

Chaos and Order

The process of designing (guis/websites/apps what have you) can be very exciting, and ultimately, when a design goes well and achieves its purpose, it can be highly rewarding.  But it's also a challenge.  Every designer has their own set of struggles that they go through during the design process.

One of the things I struggle with most as a designer is the urge I have to make things consistent, or symmetrical.  I prefer order over chaos, I'll admit.  I constantly have to catch myself from spending too much physical and mental energy on removing what I see as chaos, and replacing it with structure, consistency, balance and symmetry.  It's not that these aren't worthy goals, but my experience is that sometimes those characteristics aren't the key, or even an important element on a particular interface screen or widget.  In fact, in many instances I have found that what I consider order is quite an undesirable solution, or at least, not what the doctor ordered.  
By instinct I look at my work through a designer’s lens.  It is a macro view.  I see the overall structure of the interface.  I slave over task flows and wireframes, structuring them and fine tuning them so they please my aesthetic and philosophical sensibilities.  I judge them by their adherence to my design rules-symmetry, balance, structure, consistency.  
But for the judges that matter, the users, the interface is simply a tool that they will use to accomplish a task (or set of tasks).  They will judge its success not by any theoretical characteristics, but by how well it allows them to accomplish those tasks.  They won’t look at the blue prints.  They’ll never get a look at the task flows generated in the design process, nor would they have any desire to.  
Internalizing this distinction--the difference between my view, and the user’s view--and embedding it into my design process is one of the challenges I face, and one of the determinants of a successful design.



Powered by ScribeFire.

Design Doesn't Just Mean Color

In discussing our SDLC process with some colleagues, I pushed for having a separate phase between Discovery and Development; a phase where we can take the knowledge gained from Discovery and begin sketching out high-level solutions in order to get a handle on the scope before going into iteration planning. In other words, a Design Phase.

I quickly discovered that some people hear the word ‘design’ and automatically associate it with the look and feel of the GUI, regardless of what else is being said. Until I understood that, their argument that there was no need to call out an entire phase for design made absolutely no sense. To me, using design in this context means to figure out how to do something at all levels, i.e., taking the requirements (Discovery Phase) into high-level schematics (Design Phase) to better understand their relationships, dependencies and impact in the end-to-end process. Obviously, I hadn’t explained that well.

Much conversation ensued, including the standard weeping and wailing and clutching of the pearls when passionate people get together. Amazing how we were all speaking English and yet totally missing what was being said. Until someone (the former English major, of course) effectively put us back on track by saying “Ok, but what do you mean by ....”

Ah-ha! Define the terms. With a BA, IA, and Tech Arch conversing, we found we were using the same terms to mean different things and different terms to mean the same thing. Well once we started speaking the same language, we agreed there is merit in having a separate phase specifically for design and revised the diagram accordingly. As a team, we were then able to define what that means to our process. 

I could say that as a team we designed our SDLC process, but I’m not even going to go there.

Technorati Tags: , ,

Color for Developers, part 3

Through a glass badly

"This is not a pipe."  R. Magritte

You are reading this on screen. It is not what I expected.

One of the biggest problems for any on-screen designer is the weird backlit medium we fish swim in. This is true if you are creating interfaces for browsers or desktop applications.

By now you are asking why, why does he continue to torture us with these vague allusions and puzzling suppositions. Well it is just my sick idea of fun, really, but here is a simple test. Make a pdf of your favorite picture of a human. Put it on a flash drive and walk around to a few of your colleagues computers and compare the different displays. Extra points can be scored in two ways:

1] try a PC and any other platform, Mac, SGI, Treo

2] try laptop, lcd and CRT screens. If you can still find a CRT screen, they are fading into the dust of time or the junkyards of third world countries as we speak.

Of course you will find that the image of Britney Spears moments after the haircut discloses an array of skull colors limited only by the number of screens it is displayed on.

Individual hairs may or may not resolve, and the level of contrast will have a happy variety as well. This is where you work. Every one of your users sees this differently.

So great, isn't that a big mess, can we please just ignore it? Well no, that isn't really playing well with others. What we need is a basic strategy for accommodating this tragic reality.

There are commercial solutions to calibration available, or most Adobe programs ship with basic calibration tools. These will help... but only you. There is no way of knowing if your users ever did this, and we know that asking is not a scalable strategy.

Unless you are in a highly controlled situation, in an industry where there is a financial benefit directly tied to color fidelity, you can bet that no one really cares.

So what is the solution?

1] Design it a bit crude. Don't expect someone's screen to display a reliable difference between zero, 10 and 20 percent black, that is too subtle. Try 0, 15 and 30

2] Test it. Test it some more. Don't beat it to death, but it can definitely be too subtle.

There we go. In a few short blogs the secrets of your universe revealed. You have grasped the remote from my hand, grasshopper, do not watch Jerry Springer with the powerful tools you have been given.

Color for Developers, part 2

Color in context Many moons have swung by since our last talk, grasshopper, and by now you have had those tattoos revised and replaced more times than Angelina Jolie. I can only hope you have been as politically corrupt and personally shocking, really, she is a role model to so many.

Today we will talk about color and perception, then later we will do the sacrifice part... Right, let's start with Kasimir Malevich, who had strong opinions about color or the lack thereof and put his money, [or the people's money] where his brush was. Painted such fashion nuggets as "White on white" and "Black square". If you imagine what they look like in your mind, you will be darn close.

So what was on his mind? Why bother? There are a couple of reasons:

1] Cultural He was a Supremacist in Russia in the early part of the last century and thought that painting couches and side-tables was hopelessly bourgeois.

2] Psychological He wanted to defeat his own preconceptions and create something new; a kind of meta painting that was both free of objects and depicting pure emotion.

Well can color or it's absence do that? What strange and magical powers does it have? Vassily Kandinsky, one of Kasimirs drinking buddies, associated some very specific things with color - he claimed that certain colors elicited thoughts/memories/feelings of particular sounds and feelings and made them into a handy grid.

Most people make some basic and reliable associations with colors; black associates with night, death and designers clothing. Red means fire engines and radio flyer wagons. These are cultural associations, that effect how we perceive and interpret our world. A blue light on your dashboard is understood as a fairly passive status light. A yellow light, blinking rapidly, means the engine is probably about to seize.

When we use these colors in an interface, all of those associations are carried along with it. A complicating factor is the cultural context it is being read in. Many cultures have very different tolerances and preferences for color that western europeans; any short description of these differences will be reductive, but think of these references: Jamaican villages houses, Bollywood movies, Japanese packaging... Would those local tastes effect the design of an interface for those groups? I look forward to your comments. Leave a donation for the gods by the planter.

Design? Meet Research.

A running discussions I have with my mom revolves around a cellphone: I think she should have one; she disagrees. I say it makes sense to carry one in case of emergencies; she says her regular phone is good enough for her. I say her regular phone doesn’t work in the car; she states that you shouldn’t talk and drive. Her logic defies a response.

But what I think she really dislikes about cell phones is that they’re just too complicated to use. When my mom looks at my phone, her first question is, well how would I know how to use it?  A valid point. She is accustomed to a landline -- you pick up the handset and there’s a dial tone (no, don’t even start -- she has no cordless phones). Her phone has raised buttons, not a flat touchpad, and these buttons contain numbers, not icons. (I have to admit, I don’t blame her about the icons. I couldn’t even begin to describe the icon on my phone to pick up a call -- it has no name. You have to train yourself as to its meaning.) What she really needs is a phone designed just for her.

Continue reading "Design? Meet Research." »

The Art of the Thumbnail

I’ve been a designer for a number of years and during that time, I’ve encountered many people who refuse to sketch out an idea because, as they insist, they’re “not artists”. Instead, they rely on verbal skills and attempt to paint a picture of a concept that probably sounds really great in their head, but just isn’t sounding all that great in their description. And even though they realize their audience isn’t even remotely on board, they’d first resort to interpretive dance rather than sketching out an idea. Because, as they claim, they’re “not artists”. Well neither am I. In fact, finger painting back in kindergarden was probably the pinnacle of my artistic career.

However, I did learn about thumbnail sketches, which are very small, rough sketches that let you quickly outline the basic elements of an idea. They’re an easy way to visually let other people know what you’re thinking. By their very nature they’re not a pretty or perfect drawing--objects overlaying other objects, lines scratched out, arrows pointing to a different version, a big X to abandon the initial idea which is now evolving into a new thumbnail, etc., etc. They’re small drawings, done quickly to work through an idea.

Continue reading "The Art of the Thumbnail" »

1 Picture == 1,000 Words

For most of us, visual presentation has a greater immediate impact than text or numbers alone. Graphs are effectively used in presentations for that very reason: they quickly convey that Column A is larger than Column B, or that Line 1 has outperformed Line 2. They allow us to easily grasp the overall concept before drilling down into the details. When done well, they allow us to convey complexity with ease (see Tufte, Edward).

When a search engine visually presents the results in a manner that allows me to quickly grasp the depth of the search, quite naturally it catches my eye. Grokker.com is a search application that displays the results both in an outline view and a map view. The user can toggle back and forth between the two views before selecting their preference for viewing the results.

Continue reading "1 Picture == 1,000 Words" »

#*&)#*$)# Software.

Nothing is more frustrating than having your software beep at you when you’re trying to do something you *know* it can do, and you’re flummoxed as to why it’s resisting your every effort to continue on with your work. All attempts are met with the same impersonal beep, whereupon you conclude that (a) the software hates you and (b) your only recourse is to begin swearing with enough proficiency and creativity to make a sailor blush. You just might be the victim of a mode error.

Continue reading "#*&)#*$)# Software." »

Adobe CS 3 Just Released

Adobe released its 2007 product suite this past week.  As soon as I heard the news I jumped onto the website (adobe.com) to get a glimpse of some of the new product enhancements featured in this new release, dubbed CS 3. 

Although I’ve used all of Adobe’s big ticket products at some point in my career as a designer (and I hope to  one day be professionally reintroduced to After Effects), on the job I work primarily in Photoshop Illustrator Flash and GoLive.  So I set off to get a look at what is in store for the CS 3 version of these tools.

My first destination was to Photoshop, where I got a glimpse at some interesting new features.  The most striking of them being the new tables interface (which I can’t judge because I haven’t used it yet) and the radically enhanced selection toolset, which, judging from the online demo seems almost spooky in its intelligence and it’s uncanny ability to recognize objects in images the way we do.

Next, I visited the Illustrator page.  I was really impressed with the new features in this release, especially since Adobe has a history in recent years of productizing minor enhancements to illustrator so it can keep up with its big brother. 
The most impressive feature in any one of the products I reviewed is Illustrators new Live Color tool.  This revolutionary tool lets you adjust color across your entire canvas by selecting groups of colors and moving them synchronously across the color palette, maintaining relative relationships between each of the colors.  Updates are viewable in real time on the canvas as you drag your change your colors.  Job well done, Adobe.

Flash CS 3 looks like it received the most extensive makeover, and this comes as no surprise, given it’s popularity as a web development tool, and this being the first chance Adobe could get it’s hands on it.  The most expected, and most beneficial enhancements are to Flash’s integration with the other adobe products, specifically Illustrator and Photoshop.  You can now import both AI and PSD files directly into Flash while preserving layers and structure..  Other enhancements include enhancements to  Actionscript 3.0 as well as the ability to save and reuse animations, just like symbols.

I don’t use Dreamweaver currently, having found my mojo in GoLive.  However I will be making the switch eventually, Adobe has made sure of that.  They’ve discontinued the GoLive line in favor of the more popular Dreamweaver, which they inherited along with Flash when they bough Macromedia last year.

Adobe has enhanced Dreamweaver’s support for CSS based web page creation in this release.  Included with the product is a set of CSS layout templates from which you can start building pages.  Also new are the CSS managements tools which allow you to, among other things, quickly move styles between documents and between inline and external style sheets.

Dreamweaver also comes with support for Adobe’s Spry framework, which is a set of components that use Ajax and other dynamic clients side techniques to allow web designers to more easily build rich web sites. 

Do you know your SiteKey?

SiteKey is a system some sites (notably banking sites) use to prevent customers from logging into fraudulent sites dummied up to look like the actual sites. During registration (or updating an account if it was created pre-SiteKey), the user is asked to select an image they would like to associate with their account. Thereafter, the SiteKey image is displayed when the user logs into the site, reassuring them that they’re logging into the actual site. In theory, displaying the image instills trust and confidence in the user.

The reality, according to a joint study conducted by Harvard and M.I.T., is that users tended to enter their password regardless of whether or not the image is displayed. Only a few refused to enter their password citing security concerns. Not good.

Now, keep in mind that the test was done in a controlled environment with the users being asked to conduct routine online banking activities. They may have felt secure in their surroundings (an official test, Harvard, M.I.T., etc.), and it may not have bothered them to find no image being displayed (if they even noticed). Plus, typing the url directly into the browser vs. clicking a link from an email generates different levels of security which may have caused them to go directly to the input boxes for login.

But perhaps the images (or lack thereof) were ignored for other reasons. For those of us who only rarely login to SiteKey sites, it’s next to impossible to remember the image that we’ve selected. Face it, I can barely remember my passwords. So even if I see an image, I have no level of assurance that the site is legitimate since my recollection of whether or not the proper image is being displayed is spotty at best.

However, there is one exception -- a site that allowed me to upload my own image and associate it with my account. Because I could use an image that is meaningful to me, the SiteKey implementation thereby became a much more effective tool in alerting me to the site's legitimacy. Amazing how things improve once you involve the user.

What are Task Flows?

Task flows are a tool to help us think through the design before a feature is actually developed. They allow us to interject the user into the flow of the application and determine if the conceptual model agrees with the user model.

The Information Architect (IA) is generally the team member taking the lead on diagramming the user narrative. With the business requirements and user modeling taken into consideration, the IA determines the tasks needed for a specific feature and maps out how the user will accomplish the task within the application. The resulting diagram shows a series of actions the user must do in order to begin and end the task, which can be anything from uploading catalog data to generating reports to assigning rights and permissions to user accounts.

Starting with the initial flow, which is a high level concept flow for that feature, the necessary steps to initiate and complete the task are detailed and mapped out into the flow. From there, various iterations of the original diagram are created and expanded upon as more requirements become known. The end result maps out the different levels of complexity for that task once subtasks and parallel flows are identified and designed.

By placing the user into the process at this stage, the Information Architect and the team can determine up front whether or not the final task flows will meet the business requirements along with any system requirements and still make sense to the end user.

example of user task flowUpdated: Attached is an example of a task flow. Click on the image to view it full size. For this particular project, we were displaying new functionality at the UI layer and the diagram was created to visually show all the different ways a user could arrive at this new feature. Not all flows are this complex. :)

Ajax and Design

Some random thoughts on Ajax and design.

Don’t design your page around Ajax. Armed with the same user-centric methodology you’re (hopefully) using today, you’ll first design the page and then see where Ajax can be added to enhance the interaction behavior. Start with the wireframes, which detail the page structure and content layout. Detail the wireframes by adding in the page and/or element behavior as you’ve always done. From there, evaluate the design and determine where Ajax can be used on the page to enhance the user experience.

One thing to keep in mind is that Ajax is best leveraged as an enhancement that gracefully degrades whenever possible. First defining the behavior of a page and then adding in the enhancement is one way to ensure it'll work in user agents that don’t accept client-side scripting, such as some mobile devices.

So why use it? Well, one nice thing about Ajax is that it gives the illusion of speed. It allows the browser to display information onscreen while continuing to query and receive data in the background. The user doesn’t have to wait for a page refresh before seeing new information. Because the browser didn’t have to wait for the entire results set before rendering data, the users perceives the site as being quick.

This illusion of speed, however, can backfire by confusing the user since they might not realize anything actually happened. Here’s where some basic usability needs to be tied into Ajax. Let the user know when something changes on the screen. Display a success message, highlight the new information, change from form elements to text, etc. What you do, of course, depends on the widget involved, page design, etc. My point is that you need to visibly indicate to the user that their action was received and acted upon.

Ambient Signifiers

I recently came across Ross Howard’s essay on ambient signifiers, subtle design elements that give the user context.  They work at a more subconscious level than overt signifiers; yet, even without a conscious effort from the user, their constant presence affords an effective means of communication.

The author’s musings came from his experience with the Tokyo rail network.  Along with a station’s obvious and somewhat standard clues (signage, train colors, audio announcements, etc.), each station has its own chime melody. By remembering the chime for their final stop (which they’re exposed to while waiting for the train) along with the chime for the station before their final stop (which they can hear when the doors open), commuters can more or less ignore the passing landscape and still be cued into their surroundings. Ambient signifiers allow them to maintain a sense of where they are without having to actively seek it out.

Moving into the digital realm, consider when a browser changes the background color of the location field once the user is on a secure site. It’s a subtle change, but once the user associates it as an indicator of a secure site, a quick glance at the field will reinforce that they’re in the secure portion of a site.

The challenge is how to integrate this concept into your web design methodology. Overt signifiers, such as navigation, will always be necessary but perhaps we should also develop a vocabulary of ambient signifiers as reinforcement. A deepening of background colors to indicate sections a user visits often; a lightening of colors to indicate links to older items; differences in font size to show depth of a category, etc. Once you start thinking along these lines, you realize there are a number of ways to incorporate this concept into your design, aiding in the effective use of the site or web app.

The Iphone, why.

Years ago I would go to conferences and people would hold up their Palm and lecture us on why it worked, the economy of means, the elegance. Time passed and the same people - usually people who had not actually participated in the design process of the particular device - would hold up an Ipod and preach the wonders of the clickwheel and how it had revolutionized design on the order of bread slicers or fishnet hose.

That they usually missed the point was irrelevant. The value of the Palm was that it was much smaller than a Newton, and much faster because Palm asked people what they actually used. And both of them had coherent software interfaces that easily synced the stuff on your desktop machine. That the Ipod made having many gigabytes of purloined music sort of marginally legitimate was not trivial, either.

So I wanted to get in on the ground floor of helping Apple hype the Ipod phone, because I am predicting that this will save me a significant amount in conference fees over the next two years.

Why does this phone elicit responses like Alice’s, a post or two back? Which I fully admit I shared as all the Mac addicts read the real time blogs from Macworld while jobs was unveiling it. Oh yeah, it is cool!

But what it makes such a big splash is a study in contrasts, and how the competition failed to develop and market something that people can feel affection for.

The current crop of cellphones are junk. There are so many difficult to use features that the cellphone companies market a special line of simple phones for the very young, very old or especially annoyed.

And the phone companies are completely oblivious to this resistance. Because of the way that cell phones are sold, really as a token of the extortionist contract with the service provider, there is a critical reduction that occurs to the feedback from the user. The design of the phones is passed on as a feature list and separated from everything else in the users existence. An elaborate, undoubtably extensively discussed system to create a broken wheel.

The worst thing about the current phones - and don’t get me wrong, Razors look cool and have great ads - is that if you lose it your numbers and all of the phone specific programming is gone. Unless you have a Trio or a Blackberry, you are just out of luck. But even Trio’s and Blackberries don’t have a good mp3/mp4 implementation. Much less the overwhelming cultural currency [read: cool] of the Ipod.

The Ipod advantage in both cases is it’s connection to the desktop.

For phone numbers, it leverages a much more powerful interface; your desktop through any Vcard compliant program. So you have all of your email addresses on the phone; and backed up. Think weeks of texting saved. Imagine what you will do with that time.

In terms of features, the new phone is configurable. Which means, to a luddite like me, that you can turn most of them off. Thankyouverymuch!

Not having to carry around my Ipod and my phone is probably the least of the advantages. Waiting until all the early adopters buy it and the price falls will be the hard part.

Introducing the iPhone

Iphone

oh yeah!

What's on my Bookshelf

Having recently been asked to review a book on CSS (which at first glance looks good but I'll go into details in a later post), it caused me to take a look at the crop of knowledge currently gracing my bookshelves. Hmmm, I thought. If I wanted to recommend two of those books, which two would I recommend? A nice little challenge. Deciding to keep the choices within the realm of the practical, rather than the theoretical, here's what I came up with.

First up is Designing Visual Interfaces, Communication Oriented Techniques by Kevin Mullet and Darrell Sano. The book begins with explaining the principles and elements of design and how they can be applied to user interface. There is no "one size fits all" solution but rather a discussion about techniques such as hierarchy, relationship, balance, etc., how they are used and why they're important in software design. The author also gets into module, programs and how structure, predictability and efficiency apply. Further chapters explain establishing modular units or using a grid layout. In other words, the book gives a great explanation of what design theory is and how it's the structure for well-designed user interfaces.

Next up, Designing from Both Sides of the Screen, How Designers and Engineers and Collaborate to Build Cooperative Technology, by Ellen Isaacs (interaction designer) and Alan Walendowski (software engineer). The book is divided into two parts: The Goal and The Process. The first part takes you through designing software with user centric design principles followed by the second section, which walks you through the process of building a software application illustrating what the authors did and, more importantly, why they did it. It's a good case study in creating technology that cooperates with people, shows how good designs help the user flow into their tasks instead of fighting them, and shows how design and engineering goals need not oppose each other. An good description of a theory and the application of same.

So there you have it, two recommendations off my bookshelf. The first promoting design principles and the second advocating user centric design. What's on your bookshelf?

The 'New' Look of Web 2.0

Filtering through the webisphere are various articles, blog entries, comments, etc., about the new look of Web 2.0 sites. Frequently cited are their clean design, strong use of color, utilization of font size to emphasize hierarchy, and so on. All true. These sites are great to look at and to use -- they're clean, easy to grasp and move the eye to specific points. But are the site designers doing anything new?

As the concept of the web has grown from a bunch of clickable links into a more sophisticated medium, standards from other professions have filtered into our world. The most obvious example is the integration of software practices such as mapping out site flows and writing well-formed code, which are (hopefully) practiced on even the most basic sites.

On the design side, after some trial and error, certain knowledge and practices from the physical world have successfully migrated into the digital world. Some have fallen aside (the brochureware sites of the early days come to mind). The 2.0 web sites receiving these plaudits are the result of the site designer's understanding of the elements and principles of design along with a good dose of typography and page layout.

Is this new? Not at all. However, what is new (or perhaps I should say more prevalent) is the application of the underlying principles of good design while exploring the creativity allowed by Web 2.0 technology. And when done well, it truly is a wonderful site to behold.

Que Multimedia?

A local school recently asked me to teach a course in Multimedia. It is a first year grad course for people with little design context. Ordinarily I would have been interested in the school and it’s excellent program, yet I stumbled when I heard the term. Living in our Ajax enriched environment it struck me as an old school term, and wondered why it had faded from use.

After a bit of pondering, I came to the conclusion that it is a bit like carving trees out of wood. The metaphor is reversed. The soul in what we do is the interaction; multimedia is occaisionally part of the vessel.

Multimedia means Flash, cheesy little director games, tiny choppy video. Think of children’s CD-roms where low rent repitition is sort of a crash test stand-in for learning cognition. Multimedia means things that are difficult to sell and typically bring dissappointing responses when you do. And not usually worth producing except for massive media clients as they are expensive and cumbersome to update. These are not positive associations.

What is interesting is interaction design and the ability to synthesize actions and events into tighter groupings, both conceptually & physically - ideas like direct manipulation, contextual logic and coherent paths have utility; making it blink is just not that important.

I thought about for a bit, and realized that the suit didn’t fit. Back on the rack.

Being inspired by the user

As a Designer, one of the toughest challenges I face is finding inspiration on a deadline.  There are many ways to deal with this problem; every designer has his or her own method of sparking the creative impulse that gets a project started.  For me, one of the most reliable sources of inspiration comes from empathy with the end user.  By being aware of the user during the design process, I can connect to him and channel his wants  and needs for creative energy.

To do that, I like to get a detailed and accurate description of the user’s environment, capabilities, and mind-set.  During the research phase of a project, our team will usually perform a number of interviews/observations/user tests.  I try to draw on this research as much as possible when beginning the visual design phase.

Since we primarily design business applications, understanding the user’s environment is most often simply a matter of visiting his place of work.  When this is not an option, such as in cases where user demographics prohibit such techniques, interviews are arranged were we gather as much detailed information as we can. We build a picture of the user’s capabilities in much the same way, through, filed studies, questionnaires, and interviews.  Gaining insight into the user’s mind-set involves culling data from a lot of the above.  It also frequently involves brainstorming sessions, where ideas can be thrown at each other in quick succession.  Common sense and a little psychological awareness are helpful as well.

I usually immerse myself in the data that’s been gathered to build an in depth picture of the user.  I begin to understand what he needs out of the application, and what would make him frustrated. I come to recognize his technical capabilities, as well as his limitations.  I get a clearer picture of where he wants speed and where he needs the app to hold his hand and walk slowly.  I gain insight into his surroundings, and how it affects him, as well as how it would affect the way he interfaces with the application.  This leads to insight and empathy for him, which leads in turn, to that creative spark I am looking for.

6 Tips for Designing Mobile Interfaces

I recently had the pleasure of working on a user interface for a mobile application.  Our client is migrating their existing software product from use on the desktop to a handheld device.  I am part of a team that is designing the GUI. 
Although many of the issues involved in designing handheld and desktop GUIs and are similar, handheld devices present unique challenges to interface designers.  Here are 6 tips that can help you ease your way into designing mobile interfaces…

1 – Know the device’s screen resolution.
It’s obvious, but the most important issue is being aware of the resolution you are working with.  Many handheld devices such as PDAs use QVGA (320 x 240).  Mobile phone displays can go much smaller.  This will have an effect on the amount of text and imagery you should design into each screen. 

2 – Experience the physical device. 
It’s crucial to understand how users will interact with the device before you can design for it.  Pick up the device and use it, note how you naturally connect with it.  What finger are you using to press buttons?   Is the device light or heavy/large or small?  How does this affect your hand movements?   All of these will have implications for the interface design.

3 – Know the display’s color depth.
Although you’ll probably be designing using at least 24 bits of color (16.7 million colors), mobile devices typically have much lower color depth.  The one we were working on can only display 16 bits of color (about 65 thousand colors).  65 thousand colors are more than enough to work with, but you should be aware of the differences.

4 – Understand the limitations of the device’s software.
Handheld device software is generally at least a few years behind its desktop and laptop counterparts.  Make sure you’re designing something that can be coded in the device.

5 – Understand the implications of the touch screen. 
Almost all advanced mobile devices feature touch screens.  Become familiar with the device’s touch screen before you design. Be aware of things like touch sensitivity, and hot spot preciseness.  They will impact the user’s interaction with the device. 

6 – Be aware of the device’s audio capabilities.
Many devices come equipped with a set of sounds that can be triggered by user interaction.  Audio can be very helpful in providing feedback to the user when he or she is not concentrating on the device itself (such as when performing a repetitive task, or a task that requires one to look elsewhere).

Reconciling the Powers of Less and More in Product Design

In his book The Art of Innovation (a highly recommended read), Tom Kelley (of IDEO) speaks of “Feature Creep” as the enemy of innovation. We have all used products that try to be so much they become a burden instead of a helpful tool. But how as practitioners do we fight the feature creep tendency and keep products and business processes customer-focused?

Kelley advocates two approaches. First, in a version 2.0 of a product, streamline. Resist the temptation to overcrowd the product and emphasize “integration and simplicity.” Second, you should “spend the most design attention at the place where you touch the product the most.” I would hold this especially true in physical and mobile devices, but would also emphasize this principle in process design. If everyone encounters the front door of a process, make sure that part or the process is very well thought out and efficient for the users.

2 approaches to design...

On his blog Accessites.org, Tommy Olsson describes two approaches to designing a web page, the Visual and the Structural.  Although the article is mostly about how designers and developers have different workflows, in it he goes on to say that among other things...

Visual designers see a web page as an image: the colours, shapes and images define the page; the content is something that populates the various areas of the image. This is a design-centric view

This strikes me as a poor understanding of Visual Design.  Any Designer worth the paper he sketches on should know that Visual Design can only work as a part of a system; thinking in terms of colors and shapes before content and structure is a recipe for a poor design.

The Article

Multi Column layout in CSS

The World Wide Web consortium’s (W3C) CSS working group recently released a draft of a new multi column layout module--to be included (with possible modifications) into the CSS 3  specs.  For those web developers that have been lamenting the lack of adequate multi column support in current supported versions of the CSS specs, this is an exciting and welcome addition.

In this article I will identify the basic principles of the Multi-Column model as described by the W3C, and give some examples of how it might be used to layout web pages much more easily than is possible today.

Currently, all content within a content box flows left to right, and then top to bottom, filling the entire content box (minus padding). Multi Column Layout uses a new type of model for the positioning and flow of content within a content box.

The use of the column-box (or column for short) will specifiy that content within a content-box flow in a columnar fashion. Just like table cells in an HTML table. Columns in a content-box will flow from left to right.  The content within each column flows in the normal top to bottom direction.  From the W3C paper:

Content is flowed  into column boxes in the block-progression-direction, and column boxes (or  "columns", for short) are flowed into content boxes in the  inline-progression-direction.

The implications for web developers coding in CSS are tremendous.  The only way to create multiple columns in CSS now is by jumping through hoops.  A simple two column layout requires breaking a content-box into two child boxes and floating them.  Try adding another column and you’ll find it almost a nightmare to code it with enough hacks so that every major browser renders it to a  reasonable degree of similarity.  I have yet to see a fluid four column layout using current CSS box model techniques.

The Working draft offers promise that we can look forward to bieng able to code much more sophisticated web page layouts that are standards compliant,cross browser compatible, and flexible enough to render properly on many different types of devices.
The datails: Multi Column Layout using the ‘column’ property
Multi-column layout will be easy to create in CSS3.  Simply use the ‘column’ declaration on the appropriate content-box.

The Column-Count property
To specify the number of columns you want your parent content-box to be split into, simply use the ‘column-count’ property

body { column-count: 2 }

The Column-Width property
You can also specify the width of the columns by using the ‘column-width’ property.  If you don’t set the column count explicitly, the number of columns will be determined by the column width and the avaiable space within the parent content-box.

body { column-width: 15em }

The Columns shorthand
Use The shorthand ‘columns’ property to affect both the column width and the number of columns.

body { columns: 2 15em }

The Column-Rule and Column-Gap Properties
Use the column rule property to define the style of the rules that separate columns.  It is similar to the border property, and therefore takes similar values.
Use the Column-Gap property to define the width of the gutter in between columns.

body {
  column-gap: 1em;
  column-rule: thin solid black;
}

The ‘column-break-before’, ‘column-break-after’ and ‘column-break-inside’ properties
Use these properties to tell the browser where to break the content within columns.  In other words, the browser needs to know there to move content into a new column.  These properties specify when and where to move content to a the next xolumn over.

h1 { column-break-before: always }
h2 { column-break-after: avoid }
h1, h2 { column-break-inside: avoid }

Multi Column Layouts applied
Using the properties described above, we can quickly layout a page that uses a fluid four column grid in which each column resizes with the width of the browser window--something that is impossible using current CSS techniques. The code below will do the trick…

Create a content-box:

<div></div>

give it an identifier:

<div id=”mainContent”></div>

Now insert your content:

<div id=”mainContent”> Lorem ipsum dolar sit amet, cons incidunt ut labore et dolore magn trud exercitation ullamcorpor susc vel eum irure dolor in reprehende dolore eu fugiat nulla pariatur…</div>

Create a style sheet and style “mainContent” like so…

#mainContent {
width: 100%;
column-count: 4;
column-gutter: 15px;
column-rule: solid black thin;
}

and voila…
Content within “mainContent” flows from one column to the next.  And since the number of columns is explicitly stated and the column width has been set to auto (by default), the columns resize so that no matter what the window dimensions are, there will be 4 of them…Multicolumnlayout_2

The Buck Stops Here

Sometimes, it seems that the role of User Experience Architect is 90% management and 10% actual design.

And there's lots to manage:  user requirements, development schedules, business requirements, stakeholder expectations, schedules, timelines, and overall expectations. It's been frequently observed that the UXD is the liaison among all project participants. Truly, all roads to a given project lead through the focus of the user.

As a consequence, we mediators often become bargainers. I'm sure all of us have had to negotiate our design to conform with the myriad demands of the community of project stakeholders. We've given up the fight for a slick, appealing rich interaction for the sake of an overstressed timeline; have gone for the low-hanging, quick design hits in lieu of a more holistic and integrated design approach whose benefits may be more of an investment than an immediate showcase.

But some design recommendations are non-negotiable. Budget be spent, timelines be extended--we fail to justify our worth (and collaborate in our lack of ready acceptance) if we compromise on some critical practices.

Here are some of mine--I'm sure all of you can add to the list.

1. Coherent navigation:  An astronomical percentage rate of abandonment is associated with poor navigation on a website. This directly, and concretely, correlates to lost revenue on an e-commerce site, and only inversely impacts response rates on lead generation sites (i.e., improve the nav, improve the response rate). With applications, though, where users are often captive users, the erosion of usability is less direct, but nonetheless actual. It's almost a karma thing: what goes around (or fails to), comes around (or fails to).

2. Knee-jerk rebellion. As designers, we shouldn't adopt the personas of sulky fifteen-year-olds. Conventions endure for a reason. Especially on sites and apps. They cut through clutter and noise, and allow users to focus in on the heart of their tasks. Sure, we could all make our buttons into links, and links into drop-downs, and display diagonal navigation, but that's design that serves the designer--not the users. An electric light switch is dowdy and plain, but I can rely on what it will look like and what it will do, from sea to shining sea.

Of course, if I'm in Vienna or Tokyo or Rio, that switch is likely to look very different (although it serves the same function), which leads me to. . .

3. Xenophobia and the Ugly American Compulsion. Face it, we're good at thinking we set the standards for the world, and the statistics regarding internet usage bear out--at least for now--US influence and dominance. But that's changing--quickly. China will soon ascend as the country with the largest percentage of the population online. But it's not a simple case of "majority rules." Cultural differences are sometimes subtle, sometimes glaring, but always meaningful. In designing a website or application nowadays, it's best to assume global, rather than local, standards. This filters down to the smallest IA aspects, such as forms: most of the world doesn't conform to the US convention of <city>, <state>, <ZIP>.

Resolution Past by a Majority

Qualified member of an elite class that includes the eternally regifted fruitcake of Christmases past, the Star Wars movie franchise, and the fervent hopes of the diehard Cubs fan for a Series sweep, the 800x600 resolution is truly one of those Things That Will Not Die.

We presume a dismissive, somewhat disparaging persona for the user with yesterday's browser:  either very young, undeveloped in either manual dexterity or a sharpened sense of aesthetics, or, god forbid, over 45, eyesight failing, faltering in the doddering twilight of the wired lifespan.  Conveniently, these two groups are usually of secondary importance--if at all--to the marketing folks targeting the high-profile general demographics.

Nevertheless, this user, who today represents barely 5 - 10% of all users (and dwindling all the time), maintains an extraordinary grip on website design even today. Our own website is currently optimized for 800x600, and I regularly design to these standards, often on projects that are likely to be of little interest to second-graders or their grandparents.

Of course, there's a catch. Designing for 800x600 in a world of 1024x768 and beyond is still a good practice. Indeed, with screen monitors achieving larger and larger footprints, a good many users have accustomed themselves to multiple, partially minimized windows, as Jennifer Kyrnin's ad hoc user research suggests.  Also, widgets and navigation add-ons can subtract signficant real estate from even a fully maximized, higher-resolution browser. Finally, as several designers have observed, if a layout doesn't work for 800x600, it probably won't improve at double the resolution.

Color For Developers, V1

It is time to open the temple.
The secrets of the art ones can finally be spoken. Having gone to a school that was too expensive then and ridiculously so now, I am a fully qualified shaman of these mysteries. Line up to the left of the Hibachi and keep the coals smoldering.

The great truth is an anthem that has rung true from the beginnings of byzantine painting to the abstract impressionists:

Warm colors advance, cool colors recede.

That is the first axis. Hue, the amount of color & it’s context are primary definitions of what will be perceived in which order.

Sounds simple, doesn’t it? Like a little saying to remember a musical scale, it is easy to recall. It happens to be the basis of hundreds years of painting explorations, which influenced a couple of formal design philosophies - what some people call Swiss Modernism & the International Style.

The real connector here is a Mazdaznanian cultist employed by the Bauhaus - Johannes Ittens. In a nutshell, he liked to draw mandalas and label them. Now we call them color wheels. His codifications of color theory have been disseminated by Bauhaus students who became teachers, and their students, globally since 1919.

Historical theatrics aside - I am trying to pad this because it is really pretty straightforward - warmer colors dominate your attention. But wait, there’s more.

The other axis is a cognitive one that is more elemental than color - our perception of contrast.

The highest point of contrast becomes a focus point as well.

This is strictly about tone; the interplay of light and dark. Shape and scale work in a different way; context is more important here. A good example would be stars - not that bright or large, but you can’t help but notice them.

So imagine two sliders, one that goes from warm to cool colors, one from high to low contrast. High contrast and warm colors converge at one end of the slider, but cool high contrast areas can dominate perception if the context is controlled.

Additionally, the scale is relative. In a very pastel environment, we are still biologically compelled to compare & discern. We will look for the warmer tones & highest available contrast.

So there you have. Welcome to priesthood, those tattoos will heal in a just few weeks, and you’ll be ready for the piercing.

Not-So-Great Expectations

Joel Spolsky, at Joel on Software, had a provocative post earlier this month, entitled "Usability in One Easy Step (First Draft)."

Here's an extract:

So, usability. That's really at the heart of good design, and I'm going to spend a lot of time on it.

The good news is that I can teach you everything I know about usability while standing on one foot. Ready? Here we go:

Something is usable if it behaves exactly as expected.

That's it! That's the whole story! As Hillel said, all the rest is commentary.

One foot, ladies and gentleman! The other, we presume, is aimed squarely at the collective posteriors of UXD practitioners everywhere, with their techniques and theories and methodologies and other varieties of snake oil.

It's a truism that "making things easy is hard." Spolsky's Principle (First Draft) strikes me as being simultaneously concise,  self-evident and facile. His use of the passive voice is revealing:

". . . if it behaves exactly as expected."

Expected by whom? Under which conditions? Spolsky makes an easy argument by dividing the world into two groups (Mac and PC users), whose expectations have been created and honed by software developers with extreme--documentable--precision. But how many real-world cases are this clear-cut? User expectations often come in more than two flavors.

User-centered design has developed various methods for discovering and confirming user expectations throughout the design process, from research on best practices through full-blown usability testing. Indeed, a classic probe incorporated into usability walkthroughs (and one I use heavily) is the repeated question "Is this what you expected to see/happen?"

It can take a lot of skill, time, and effort to gather and synthesize user data, and then determine the most effective way to apply the knowledge to the design. And what happens in the (all-too-frequent) instances in which there are no expectations?

Looking forward to Spolsky's Second Draft. Hopefully, he'll have both feet on the ground next time.