Showing posts with label interface. Show all posts
Showing posts with label interface. Show all posts

Monday, September 20, 2010

What defines a user experience practitioner?

There has been an ongoing LinkedIn thread in the User Experience (UX) group regarding just what defines a user experience practitioner. This is something that I have noodled as well as I have tried to determine what my last decade as a software entrepreneur has turned me into (professionally, at least). Of the many hats I have worn, ideation, prototyping, interaction and interface design and user testing has been the most interesting and personally satisfying, but does that make me a UX expert?  The LinkedIn thread leads me to believe there are two distinct groups, the traditional practitioners who come from industrial design, architecture, etc., and digital practitioners, who are more visually inclined. Certainly I am more of the latter, tho with a strong foundation in marketing fundamentals and keen knowledge of business process methods, both of which I think are additional strengths for effective digital UX design.

Anyway, I thought I'd share my recent contribution to the conversation as it describes a key notion of mine regarding software design and user interaction, which is the ability to achieve greater clarity of purpose by freeing yourself from constraints and rules:
"I have been following this conversation for some time, and I think a key distinction between these two UX camps is that one is governed by immutable rules, and the other is not.  User experience in the real world, as defined by architects, industrial designers, etc., is constrained by reality -- things like gravity, friction, mass, and so on.  The digital user experience is constrained by none of these things. In fact I would make the case that the more the real world intrudes on the digital experience, the more it is potentially diminished. Just because a physical object is known for a specific purpose does not necessarily make it the best metaphor to represent a vaguely similar action.

And as much as I respect the deep training UX demands in the real world, perhaps that same training, when applied to a primarily visual experience, is detrimental when it comes with so much psychological and creative baggage. Artists, on the other hand, excel at imagining possibilities without constraint. The beauty of the web and web toolsets are that they provide an easy way for artists to realize their ideas without making too many compromises. This is not to say anything should go, but it is always easier to scale back big ideas than to take a small idea and make it more than it is.

Certainly a balance of both skill sets would be optimal, but moving quickly and being good enough for the medium is going to win most of the time."

Tuesday, May 18, 2010

The big lie in search

The biggest lie in search is also its most touted benefit -- that it is intuitive and easy to use.

Perhaps, as much as a blank piece of paper is intuitive, so too can be a single, empty text box partnered with a single submit button.

But the search results page? Easy and intuitive, it never has been, and it is getting worse and worse as search companies keep adding more options, suggestions, clusters, facets and widgets to try and help you make sense of the endless pages of results. Even the Google with its once pristine layout recently felt compelled to add more clutter to the interface, an explicit acknowledgement that the results they serve up simply are not good enough.

So how could the search experience be improved?

One way is to make the results better by asking just a little more of the searcher up front. If you are able to ask the right questions, you can infer much. For example, if, instead of a single submit button, suppose there were three; "animal," "vegetable," and "mineral." By forcing the user to select, huge amounts of ambiguous results could be eliminated. Of course, this approach impacts the simple, intuitive search box and button combo myth, but if the experience and results are better, does it really matter?

Another approach is to build applications and interfaces that integrate rules to constrain search queries to a specific business purpose or process. To quote from a patent currently pending (um, mine):
"This invention relates generally to software-based search technology, and particularly to rules-based (rules being any standardized set of principles or methods for organizing and structuring information (e.g. The AP Style Manual; IDEF, a business process language; the Marquess of Queensberry rules for boxing) searching via a constrained or guided query structure."
 You can read the full patent here should you be interested.

Bottom line -- attributing the property of "intuitive" to a text box forces a free-for-all environment that must cast too far and too wide, and demands far too much processing on the backend in the attempt to guess at user intent.  Constraining the queries, either by empowering the user or by integrating them into the user experience, can more easily deliver better, more relevant information.

Sunday, August 23, 2009

Process power to the people!

There are two kinds of business processes in the enterprise – consistently executable processes (deviation will not be tolerated!) and ad hoc processes, which guide, advise and recommend. The first are ideal for automation as they are tangible in their output, the second, not so much. The first have an entire class of tools and software to support them (BPM in its many forms), the second, very few. Ironically, this seems backward, as only 10-20% of the enterprise is automatable, while the majority consists of ad hoc, or “knowledge” processes.

Why aren't traditional process tools used for ad hoc processes? Process thinking is hard, it is not natural nor intuitive as it is a man-made thing created to describe man-made things (people brought together to produce goods and services for less than the market will bear) – thus the tools developed are hard to learn, hard to use and hard to understand by humans (but relatively easy to use as business rules for software code, thus the connection to automation).

For the benefits of business process to be realized throughout the enterprise, the tools to capture and communicate process must be easily utilized by anyone, anywhere, anytime with little or no training.
Is it possible for process tools to be created to do this? Sure it is, but it is hard. It takes time, experimentation and investment. And process tool vendors don't even consider it a requirement to do so as they have used the same metaphors for decades and assume rigorous training is a given, not an option.

While the Web freed the interface, web-based tools are only as good as the effort put into the design. And, while process tool vendors are bringing browser-based process tools to market, they have only done so now that the technology has made it easy for them to reproduce the same interfaces they have always used.

Of course, since these vendors now have browser-based tools, they seem to think this makes them inherently more useful and that they can now support and enable ad hoc processes.

But they simply don't get it.

While the Web provides a powerful means of distribution, it is not the medium that matters most – it is usability and usefulness. Only then will the power of business process truly be brought to all people.