User eXperience: the “X” factor at Ask.com
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:
- Our focus on product design
- Our inclusive and flexible structure
- 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.
