It has been long enough since I started directing the UX design efforts at Ask.com… and it is now that I feel accountable enough to expose some of the philosophies behind this process. I’d like to explain how my group has architected our practice to match the Ask way of doing things as I feel it could be helpful for others in the field. The philosophy that identifies Ask.com in our industry defines the UX Group’s approach as well – and can be narrowed down to these three aspects:

1. Our focus on product design
2. Our inclusive and flexible structure
3. Our approach to solutions ahead of challenges

Allow me to break it down for you further. Here, now, my scathing exposé of how each of these aspects churn the magic brew that is “UX at Ask”.

UX Positioning: Focus on Products – and the People Who Use Them

Having directed User Experience for multinationals ranging from Microsoft to Nike, I find that very large enterprises are either immobilized by stifling process, or hampered by cumbersome organizational hierarchy. What’s worse, in said chain of command, User Experience is usually subservient to Engineering or to Marketing.

Marketing-orchestrated UX can put commercial communication as driver of its innovation (Which tends to be transient, superficial and short-sighted). Engineering-ruled UX puts technology constrains ahead (which could be derivative, over-featured and complicated).

Ah, but at Ask, UX Design resides where it should: the Product department. That means we care about users first and foremost. Our design is propelled by results, not point releases; and fostered by user needs, not communication campaigns. Users are at the core of the product design; they’re our raison d’etre. And what better goal for User Experience than the user itself?

We know our audience changes – and with them, our success metrics – so we remain engaged with our audience though feedback, user studies and limited deployment results. Our products can take leaps of faith, propose new ideas to our industry (as our celebrated 3D user interface that raises multimedia content directly to the search results page), and react to our end user’s opinions and actions, not our servers’ log files.

Compare this to our competition. While Google’s UX leadership focuses and measures success in microseconds of latency, we focus on delight and usefulness to our users. We can afford trying new things because our objectives are not entirely framed by machines’ output, rather by people’s voiced, evolving needs. While Microsoft focuses on new features as a way of forcing their services in the market, we focus only on the right features to attract audiences motivated by sophisticated simplicity in their lives. While Google focuses on speed to remain as market leader, we focus on content richness and engaging experiences to remain market innovator.

UX Structure: Inclusive, Flexible and All-encompassing

This product-focused ethos at Ask.com allows for a participatory model for our UX process. Here’s how a traditional model (i.e. not ours) would work:

- Any requirements from Engineering, Marketing, Product Design and Business Strategy are first digested by Program Management, and somewhat, somehow, interpreted (directed more like it) to Research (mistake one: this will alter the outcome of their work).

- Research then hands their findings to Design… and disengages from further interaction! (mistake two).

- Then Design does its own interpretation (blind-folded to the needs of what requirements came before) and delivers results to Usability for testing (mistake three: this tends to become a confirmatory exercise rather than a learning one, as it comes too late into the process to affect REAL change).

Our flexible system allows for ideas from any participant: Our front-end developers, our back-end engineers, our program management, our creative staff… even our top management! (which historically is well known to have a personal interest in UX concerns). Therefore: concepts and prototypes are invariably our first step in any initiative.

This may appear a chaotic environment to the uninitiated, but this type of input and interaction is the “secret sauce” of our User Experience process. One of the main reasons UX is widely acknowledged as one of our main differentiators is because any designer has full access to upper management to portray the value of design as strategic thinking, rather than just a tactic exercise (Yet another benefit of our collapsed internal hierarchy!)

UX Process: Solutions First, Challenges Second

Clearly, the way we go about UX differs slightly from other companies. It is a slight tweak of the established steps in the industry–but what a difference it makes!

Most initiatives will start with (1) a Definition Phase (requirement gathering and planning), then, in an obsolete “waterfall” model, move sequentially to (2) a Spec Phase (technical specifications, asset planning, dependencies management), then (3) a Design Phase (concept mock-ups, interaction flow, page architecture, wireframes, prototypes, visual design), then (4) Release Phase (implementation, dev & QA support) … and if they really care, a (5) Maintenance Phase (revisions based on user response).

I have been in enterprises where first step in the process is the Technical Spec (!!!), listing all the dependencies, all the compliance guidelines (I am guilty of a few of my own), and all the technical constrains. In that situation, Design comes last. Ideas are often shackled by inertia and “thou-shall-nots” from previous challenges, imagination is restrained from the get-go with the burden of anticipated problems and past legacy that only look backward, not forward.

At Ask we decide to do things a tad different: we switch the Design Phase AHEAD of the Spec Phase. This simple, yet huge difference makes a big impact on what we allow ourselves to dream on. First: We solve a problem. Second: We figure out how to accomplish it… Not the other way around!

Design maintains a constant presence in the end-to-end effort (a departure from Peter DeGrace’s “Sashimi” process model)

A point-of-view and a hypothesis is formulated beforehand (with the help of Design’s early aspirational visualizations) during the initial (1) Definition of the project. Then, it is shown to users through testing with the help of (2) Design. Following that, we perform limited releases to gather further user feedback.

(3) The Technical Spec comes right AFTER we have gathered learnings from all those previous steps. This sequence is crucial for any innovation to take place.

Spec is also a process that starts mid-way in the involvement of Design phase, and continues on even during last phases of implementation or (4) Release has occurred. This is largely because engineering modifications will shape how the final guideline will look – and because the mission is not just directing current initiative, but (5) Maintenance of future scalability and upcoming cross-functionality with other verticals in the network.

In addition, none of our phases have a complete FINAL handout. They remain active and flexible. We believe in an iterative and even cyclical process to help smooth out the unexpected challenges that subsequent phases may bring. This also helps makes our process of delivering new products nimble and responsive to a continuously evolving medium.

Makes sense, right? It does to us, too.

Open/Save Dialog Boxes to be more exact.

I am talking about those annoying pop-up windows that applications expel when interacting with document files (opening or saving them). They are way past their useful life and now days are just a hindrance to a consistent mental model in the user experience of modern operating systems.

Why the hindrance? They are simply redundant devices to a much more comprehensive one: The Finder (Desktop, or Windows Explorer, or whatever you want to name it). Visually parsing file compilations on any modern operating system is already achieved through the metaphor of windows displaying groupings of files or folders. You dive through different levels by the opening of folders into additional windows (and increasingly, through searches and tagging filters)… Why then, the need of activating a second apparatus when interacting with the very same files through an application? Inertia. Inertia from obsolete reasons that could only validate by going back to the days of the birth of the Dialog Box, when it appeared (to the public at large at least) on the Lisa operating system, later on the Mac and soon after in Windows.

1st. Obsolete justification.

Dialog Boxes were literal visual translation of the preceding command-line interaction mental model: Open > This File This meant: Initiate application, then define an action first, and finally specify the affected file. In a way, interaction was application-centric. On any modern GUI though, interactions should be document-centric (As the finder affords): This File > Open The system figures out what is your default application and activates necessary assets.

2nd. Obsolete justification.

Dialog Boxes were needed for a strong reason: Operating systems were not yet multi-tasking… You were either working on a word processor, or navigating the finder, or interacting with a spreadsheet. The idea of protected memory was yet not finessed and you had to quit a previous task to initiate a new one. Therefore, when inside of an application (Paint program for example), you were forced to “open a porthole” into the file system. Now days, with the ability to switch not only windows but applications with ease… We do not need to open a gap from one modal environment to another… We reach the Finder and all our files are there contained within a richer experience than the narrow view of a small window. There are also available strategies like the “Open recent” menu or the “Welcome Dashboard” (aka Project Gallery) that make Open/Save Dialog boxes less and less necessary. So why not simply get rid of Dialog Boxes and use the Finder instead? Beyond the previous inertia, there are two big reasons remaining:

1. When opening files within an application, it is many times desirable to filter the type of files (to look at only text files, or only images, etc).
2. When saving a file (perhaps a more complex task), you first have to specify its attributes (such as name, format, compression, etc.)

The first challenge is being resolved by the increasing sophistication of the finder windows themselves. In both Mac OS 1.4 and the upcoming Windows Vista, any content of a window in the finder can be easily filtered with pre-assigned filters (i.e. Smart folders in the Mac). So jumping from an application to a finder showing relevant documents could easily be achieved. The second one is more difficult to resolve… But not by any model less convoluted that the Dialog Box!… So here goes my proposal:

“Open” dialog box: The button, menu or command of “Open…” simply switches to finder with the default location for the application (last cluster accessed) showing filters activated (i.e. images in .jpg format) and other relevant and available filters (i.e. images in .gif, .bmp, etc). The user, already comfortable with finder navigation, has the freedom to explore, temporarily suspend (Something which the restrictive and modal Dialog Box does not allow) or simply cancel the operation by switching back to the application.

“Save” dialog box: The button, menu or command of “Save as…” simply switches to finder with the default location for the application (last cluster accessed) with file placed, name selected (ready to take user input) and available to be moved by drag-and-drop if so desired. A technique just as expedient as it would be to navigate with the controls of a Dialog Boxes… but simpler as it recycles existing skills on operating the Finder. And for saving formats other than default? Well, that warrants another essay called Death to formats! As current trends in storage capacity and transmission already allow for the luxury of format-agnostic files, where the additional resources or necessary for opening on different applications could already embedded in the file (In the metadata or resource fork), and a computational disambiguation algorithm to convert among them could be part of the applications or operating system themselves (this last one specially when dealing with legacy programs unaware of future “formats”by offering them only what they understand). The additional burden of saving all available formats in one file (in size weight or computational time) that this strategy might incur is a minimal and transparent annoyance compared to the long-standing barrier of understanding formats. Most users still do not get the difference on WHY using a .jpg versus a .gif! In fact, it is all useless detritus in their day-to-day cognition process.This proposal is not utopian. In the past, Apple used to adopt a similar approach (the format suffix was hidden by default and not needed as the system looked for its definition on the resource fork). My pitch goes further in actually integrating the different formats into a single raw file, pretty much as Adobe Illustrator files already imbed (optionally) enough information to be opened by either PDF readers or its own editing software, even including external resources as fonts and images. Apple in any case, seems to be moving on a similar direction with the adoption of XML for tying together all the resources that go into their files (which behave more and more like packages) for their software Pages or Keynote. ICO is also a good example of a file that provides different information depending on the needs of the application (16×16 graphic to a browser, 32×32 to the XP desktop). The recent DNG approach to photographs in raw format is also the right step towards neutral files.Any of the previous proposals support a document-centric approach in the design of operating systems, a closer experience to real-life manipulations where you employ a polyvalent or “multipurpose format” document (i.e. “piece of paper” and act upon it with different applications (i.e. “markers, pencils, scissors, glue”).Yes, it is that simple really. Lets kill unnecessary dialog… with the machine.

We have a problem at Microsoft…

Our users don’t notice our basic warnings signs. The signal-to-noise in the average user interface is so low that any important message has to be brought to their attention by extreme, forceful means:

- Using large, bright banners of uncommon colors (same strategy as advertisers do).

- Placing them in their visual path, sometimes even blocking legibility or functionality (Which users, jaded them, learn to ignore anyway after a while).

And you know what? They still don’t work! Our users are inured to most extraneous messages (stimuli) they are NOT seeking for (Same symptoms as Jan Panero Benway & David M. Lane’s Banner Blindness malady).

My proposal? Using the “Threat Detection” ability innate to humans.

Yes, I am talking about the same congenital mental switch what William James and Henry Holt formulated in the Principles of Psychology as early as 1890 (which in itself was the direct evolution of Williams’ Theory of Emotion in the 1880’s). The same inherent reaction corroborated in modern studies such as the legendary “Emotion Drives Attention: Detecting the Snake in the Grass”. They all agree on the human mind pre-determination to pay immediate attention to those forms that we deem more dangerous (fear-relevant). Their studies showed that we can distinguish the sinuous form of a snake or the wheel and spokes shape of a spider out of a background of visual noise than say, any other non-threatening form (fear-irrelevant) such as a flower or geometrical form.

The spider’s form (and “other vermin” as William duly notes in his chapter about Instinct) is imbedded in our brain due to a drive for self-preservation.

My proposal, again, is to use this ancestral response to our advantage.

In a typical warning system based on High, Medium and Low importance… The simple adoption of fear-relevant imagery would improve the relevance of the warning systems.

And just to reinforce the issue, I chose black as the background of high-level warnings as I deem the usual red too over-used in marketing and therefore diluted… besides the point that it triggers the wrong response. (According to Theroux in 1998 “Mere perception of red color enhances the human metabolism by 13,4 %”-???) On the other hand, black is associated with death, evil, and mystery. William highlights our fear for “Black things” (and I quote) “from the fact that we easily suspect that dangerous beasts may lurk in these localities“.

I personally hope the connotations of a predatory, carnivorous insect prowling in the dark could be nicely associated to the practices of phishing, spam, and computer virus.

To be consistent, the Medium-level messages will be presented by another bug, a domestic fly in this case. Bothersome, but not threatening. Since it is considered an eyesore within any context… it may provoke users to acknowledge and answer its questions in order to get rid of it as expeditious as possible.

Instinctaneous High Level Warning

Instinctaneous Mid Level Warning

Instinctaneous Low Level Warning

These “natural message carriers” will make for a more intuitive caution-inducing system… And the users my feel compelled to interact with them even if just to tell them to bug-off.

Granted, the specific samples below may or may not prove the usefulness of “Thread Detection” in UI (That is, which of the two is more annoying and attention-demanding)… but further usability tests with different variations on the idea should be performed if my proposal was to be taken serious (color vs. size vs. form vs. animation). The main intent of this idea though is to simply make use of what Donald A. Norman identifies in his book “Emotional Design” as “bottom-up behavior”: A positive or, in this case, negative affect that stimulates our visceral processing, which in turn modifies our behavioral, and then our reflective one. As he points out, visceral procession is a faster, more immediate (more effective?) reaction. Perfect for the task at hand.

I say we bring back the value of instinct into software experience! One small swat at at time.

Classic High Level Warning

Instinctaneous High Level Warning

In the good tradition of meme christening (Same method that brought us terms such as folksonomy, infotainment and craptacular) allow me all to coin the concept that from now on shall be known as instinctaneous, a portmanteau of instantaneous and instinct that will give name to the concept of achieving a desired and instant response out of users of a designed experience by means of exploiting their subconscious instinctive qualities.

This technique shall be useful when designing user experiences in software, hardware, environments and processes.

Usage: “The acknowledgment of this warning sign shall be instinctaneous by the user”

Please, keep posted for upcoming proposals in user experience and interface design. This website will be devoted to the cause of improvement of such through the use of instinctaneous techniques and devices.