Showing posts with label user experience. Show all posts
Showing posts with label user experience. Show all posts

Tuesday, September 26, 2017

Perfect autosave

One of the challenges in mobile design is informing the user something has happened -- a form has been submitted or field update saved. The boring and accepted way to do this is a popup window that says "You just did something!" And if your developers are over thirty, they probably will insist on putting a confirmation button to dismiss the window. Under 30, they probably have the window fade after a second or two, or when you tap out of it. Without this, the change might be subtle enough that you are unsure what if anything just happened, and depending on connectivity, the ubiquitous loading animation may flash too quickly to do little more than add to the confusion. And don't forget by adding text to a confirmation window you are creating another language/data element to worry about when you decide its time to go multi-lingual.

So I would like to give this to the world, the perfect autosave image.


Take it, use it, enjoy it.  Me? I use it when a user updates via select/dropdown, or clicks into a field, makes a change, then clicks out -- the image fades in then out a second later. And as a bonus, I add this sound effect which reinforces that something has indeed occurred.

Enjoy!

Wednesday, October 6, 2010

Must a user experience be "positive?"

User experience is an important dimension of software development, but it is not the entire thing. 

Sure, a "positive" user experience can increase adoption, but if the business requires things to occur in a precise way at a precise time, then the software has to enforce that, even if it means incorporating unpleasant and unnatural methods to ensure it happens exactly the way it must. 

Accomplishing this means you need to be agile in your thinking, able to see connections and intersections in new and different ways, and not be constrained by conventional thinking.

Monday, October 4, 2010

Understanding business process can create a better user experience

Software consumes, transforms and presents information. It is utterly about communication. And consumption, or capture of information, depending on the business activity supported, may be of far greater importance than how the information is represented. This is particularly true if unstructured data is feeding into the system.

As I discussed in my previous post, information simply does not have the physical or conceptual limitations of a cup holder or door knob. Thus, information design is not just about the presentation or graphical layer, but the structure as well -- data modeling, information architecture and perhaps, most important (in my experience, anyway), business process modeling, so that you have a detailed and granular understanding of the processes the user must go thru in performing a set of tasks that intersect with the software system. Process modeling helps better design the interactions and hand-offs with touch points within and outside of the system. It also helps understand the information types required, the actors involved, the constraints required by the system and the organization, additional systems or tools that are necessary, and the inputs and outputs that drive the user through to completion. 


Bottom line, the better you can understand the business and its requirements, the better and more meaningful experience you can create.

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.

Tuesday, May 4, 2010

Would you pay for great search results?

In our experiments at Emantix with automating search queries, we discovered something really curious -- the longer and richer the query, more often than not the top result was very, very good. But the following results were not -- at all.  In fact, in our experimental search engine, howdoya.com, we had to tune down the richness of the query so that, at a glance, the entire results page looked good, giving the user an overall perception of quality.  And of course, when we tested with organically occurring ads, the same was true. Really great queries -- fewer, if any, ads, mediocre queries -- more ads.

So the question is, do more relevant search results diminish the quantity and quality of ads displayed? And if so, what are the implications of and opportunities in removing the obligations inherent in a paid advertising revenue model?

Why not an ad-free, fee-based search engine?  A low annual fee that is painless to an individual, but collectively, on a web-scale, could be a highly profitable enterprise?

Would you pay a nominal fee for better results and less visual clutter?

I would like to propose a word, a verb, to describe this opportunity  -- to "craigslist" -- or to disrupt an entire industry by eliminating a critical source of revenue.

Friday, February 12, 2010

Free the desktop!

While virtualization is all the rage, making your word processor, spreadsheet and other day-to-day tools “virtual” still ain't solving your big problem. While your TCO can certainly be brought down, you aren't going to get a corresponding or greater return on productivity.

A brief history:

In the beginning, the application or program was the primary point of entry for the user. Then, as users installed more and more applications on their desktops (which begat more and more files), the file became the primary means for entry – click the file and the OS generally knew which program to launch. Today, we are in a hybrid environment of desktop apps, network client/server apps, files and URLs/URIs that connect to networked or remote hosted applications. And lets not forget "the cloud."

The problem with the desktop is simply that it is the wrong metaphor for the distributed enterprise. And, as illustrated by the floppy disk that represents “save,” software companies are loath to change “learned” metaphors. Great leaps are only made by taking risks (or at the very least stepping outside your comfort zone).

So how do you build a better desktop? By reinventing how you interact with business content and business process. Business process can provide a crystal clear lens into the enterprise that reflects and communicates exactly what an employee could, should or must do.

Imagine:

No matter where you are, or what device you are using (laptop, smart phone, kiosk, toaster), you log into your “workspace,” where you see the processes and tasks that define your job. As each task is selected, the relevant content, regulations and policies, subject matter experts and yes, the software systems, are exposed. Clicking on any one of them links to, contacts, or logs you into that thing. You in turn print, download or upload work files, enter data and collaborate with peers.

Bottom line – while virtualization is not solving the productivity puzzle, it certainly does provide some critical, enabling pieces. But the rest, well, is yet to come.

Thursday, January 7, 2010

The imperative to reinvent business process

Why am I so keen on the idea of reinventing business process?

Because an amazing thing happens when an enterprise's business processes leverage the distributed nature of the Web.

Productivity...increases.

Unfortunately, this is not what traditional business process methods, tools and techniques were created to enable. Originally, they were developed to do essentially two things – one, to analyze how an organization operates and determine areas for improvement (which might or might not have resulted in a technology implementation); and two, identify resource types and definitions so that database schemas could be designed. Thus the tools created to do this are generally expensive and complicated, with steep learning curves. And the result, or output of these tools are diagrams either too large and complex to comprehend, or so granular and precise that they fail to communicate any understanding of, or relationship to, the enterprise as a whole.

For an enterprise to see dramatic productivity gains, the tools to do so must be in the hands of, and usable by, the business user – the person actually doing the work.

So what about business process needs reinventing? Four things:
  1. Anyone should be able to document, or model, a business process with little or no training.
  2. Anyone should be able to use the result, or representation, of a documented process to navigate the tasks and activities that define their role within the organization.
  3. The documented process should directly connect process activities to all relevant content.
  4. Human interactions with a process should act as feedback into the process, either validating it or indicating areas for improvement.

Friday, October 9, 2009

A passion for process

Business process is something I have been fascinated with for some time now. And, while it may not be obvious at first glance, my current venture, Emantix, is simply the latest evolution of my fascination with and thinking on business process. After all, business processes are really nothing more than words organized in a such a way as to achieve consensus between two people or more as to what it is they do. Nothing more than words. Nouns, verbs, adjectives, pronouns, interrogatives, prepositions, interjections... antonyms, synonyms, hyponyms, troponyms, hypernyms, meronyms... make a sentence with me.

But I digress.

In the last company I started, Contextware, I reinvented the mechanisms, the tools, of business process, as well as the output, or interface. But I did not go far enough. Truly reinventing process requires much more than mere functionality, buttons to push, true reinvention demands a greater and more comprehensive understanding of information and the rules of language itself, as that is where business process knowledge lives and breathes, and hides.

And the biggest challenge of all is whatever form the answer takes, if it isn't easy as hell to do, people won't do it, use it or buy it. So while my postings on this blog may cover many things, I apologize for how often I keep coming back to the fundamental business benefits of — and imperative for — reinventing business process.

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.