Sir Arthur Conan Doyle, (Sherlock Holmes) The Adventure of the Copper Beeches.

This is a promotional video created by the municipality of Ontinyent (Spain) in order to illustrate their e-Government platform.

As part of the team that participated in the development of the platform, I think the video perfectly reflects our main design goal: simplify people’s life by removing paperwork barriers.

The biggest success of mobile devices was produced when their interaction paradigm changed: mobile apps moved from a miniaturization of desktop applications to a new paradigm based on the use of fingers for direct manipulation. The image above illustrates this change showing a Nokia 770 (2005) which required a stylus to be operated and the iPhone (2007) which could be effectively operated with finger gestures.

The new paradigm was appropriate for small devices but it turns out that desktop applications can also benefit from this change.

Can desktop applications follow the mobile-style design?

When I read a question on SatackUx about whether this new mobile paradigm could be also applied to desktop applications, it sounded a bit counter-intuitive for me at first. However, many projects headed to bigger screens are taking advantage from lessons learnt in the mobile area.

Mobile UIs emphasize the need to focus on the task in hand (avoid featurism), the need for being responsive (avoid programs being blocked while loading) and the role of content (provide the users the info they want) among other aspects. Is worth noting that the above aspects try to solve problems that are essential in mobile devices but they are also common in desktop software.

By applying the UI guidelines for tablets (where screen real state is not so constrained) to desktop application design, you can obtain a design that is also appropriate for the desktop with the benefits of the mobile-like design (except for the touch based interaction). The above image shows the CNN app for Android tablets which could be perfectly suitable for desktop use. This idea is aligned with the mobile-first approach for web design proposed by Luke Wroblewski.

The new design for Google products.

Recently Google introduced a new design on their products including the redesign of maps, docs, calendar and finally Gmail.

The main goals of the design were explained in a talk by Jon Wiley at UX Week 2011. The goal was to redesign services to be:

• Focused. They decided to remove color and use it only to convey meaning by highlighting specific elements. For example, main actions such as create a new document are represented by a red button, sharing actions are represented in green and navigation actions are accessed with blue buttons.
• Effortless. They tried to reduce cognitive load by only showing options when they are needed. The increase of white spaces is one of the first things you notice with the new look.
• Elastic. They decided to support different screen sizes by applying responsive web design techniques.

These design principles are core to the mobile web but now they are also being applied to the whole web regardless of the used device, and I am sure that more and more websites will start to follow this path soon. 

As software designers we need to know about users. However, user behavior and our observations are inevitably affected by our human nature. More frequently that we think, we take decisions that have not rational explanation. Even for such a random decision such as choosing a name for a geometric figure, our human nature has something to say:

Given ”Booba” and “Kiki” as options for naming the figures above, more than 95% of the subjects make the same choice for their naming.

We cannot escape our human nature, but knowing our weaknesses in judgement can help us to improve. Recently I read the list of cognitive biases from Wikipedia and I found them useful to understand better some use behaviors (and design accordingly), and also to be more rigorous on user research. Here is a short selection:

Bandwagon effect – the tendency to do (or believe) things because many other people do (or believe) the same.

Many assumptions regarding software design are repeated again and again from managers and programmers to customers and users. You have probably heard before that ”Choices should always be limited to 7+/-2”, that “Stock photos improve the users’ experience” or that “White space is wasted space”. Despite data showing otherwise, the power of repetition seems to be bigger.

Fortunately, at UX Myths have the goal of debunking these myths with the help of factual data. This is useful to convince others that your minority opinion is backed by serious data.

Confirmation bias – the tendency to search for or interpret information in a way that confirms one’s preconceptions.

Frequently the scientific method is completely reversed. This was perfectly illustrated at Phd Comics by comparing the intended and the actual method:

Todd Zaki Warfel provides some advice on how not to conduct research. Todd provides different tips that are directly related to some of the cognitive bias commented here but specially this one.

Endowment effect – “the fact that people often demand much more to give up an object than they would be willing to pay to acquire it”.

Simple designs are great. However, we are more prone to add features than remove them. Quoting Antoine de Saint-Exupery: “Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away”. So, no more elaboration on this point.

Framing effect – drawing different conclusions from the same information, depending on how that information is presented.

In the age of infoxication, making large amounts of data easily to understand is a big challenge. By choosing the adequate representation of data we can make complex data look simple to the user. For example, Google Analytics makes use of Edward Tufte’s spaklines visualizations:

Omission bias – the tendency to judge harmful actions as worse, or less moral, than equally harmful omissions (inactions).

We normally prefer to keep useless emails than taking the risk of deleting something that we can eventually need. Threatening users with with messages such as “are you sure you want to completely delete these files?” does not help either. As designers we can free the user from this fear of irreversibility. One good example is Gmail, where they allow to undo a traditionally irreversible action such as sending a mail.

To achieve this, you can trick the user behind the scenes by postponing the real action if necessary but the tip is to never use a warning when you mean undo.

Wishful thinking – the formation of beliefs and the making of decisions according to what is pleasing to imagine instead of by appeal to evidence or rationality.

It has been documented that users are not good on describing solutions but on detecting problems. As designers, it is important to observe how a product is used in order to detect problems instead of theorizing about hypothetical uses and desired features.

Dunning–Kruger effect – a twofold bias. On one hand the lack of metacognitive ability deludes people, who overrate their capabilities. On the other hand, skilled people underrate their abilities, as they assume the others have a similar understanding.

Dealing with technology it is difficult to be sure whether you know the tip of he iceberg or the full story. By participating in knowledge-based communities such as StackOverflow or StackUx you can form a better idea of your real degree of expertise. By sharing your knowledge you can verify whether you can solve problems that require a deep knowledge of  subject.

False consensus effect – the tendency for people to overestimate the degree to which others agree with them.

The bad use of Powerpoint presentations has been considered to promote the false idea of consensus. Try to make your communication effective by making it simple and direct to the point (not the bullet one).

During the last month of July, I have been regularly participating in the User Experience community at Stack Exchange (StackUX for short).

StackUX is a community based on questions and answers where everything is voted to promote the high quality content. The site follows the schema introduced by StackOverflow. With this schema questions are not only answered but answers are continually improved. Conversely to what happens with forums or mailing lists, the best answers do not get lost in the middle of the conversation. The diagram below illustrates the hybrid nature of the approach with respect to other collaborative communication mechanisms:

Participating in the community has been a great experience. I got accepted several answers which allowed me to enter the top 10 of participants during July. It has been great to discuss interesting UX topics such as the Google+ circle concept,the application of the iPhone UI paradigm to the desktop, data visualization for numeric values, the keyboard shortcut discoverability or the definition of “levels of complexity”.

I found the StackUX approach very useful for learning and sharing knowledge among the UX community and I hope that it keeps on growing.

A growing community.

StackUX is still in beta stage but it is a healthy community according to the success metrics of Stack Exchange sites. StackUX has more than six thousand participants and about two thousand questions with a 99% ratio of accepted answers.

The next step in my opinion should be to attract the most influential people in the UX community. I did not explored the user list in detail but it is not easy to find in the community most of the authors of the reference books and leaders of well-known UX companies such as Adaptive Path, Happy Cog or Rosenfeld Media.

Some of these people are already participating on the IXDA mailing list style, the generic Quora Q&A site, or the book-list oriented UX Zeitgeist. So, it is not clear whether or not there is room for a new collaborative community. In any case, it is a good signal that a medium such as Smashing Magazine has started to pay attention to StackUX.

When I went to Denver in 2009 I had to fill a long paper form on the plane for the authorities to let me in. Despite the difficulties of writing on plane tables,  I was able to answer different kinds of questions regarding the following topics:

• Personal data. Name, surname, date of birth…
• Logistics. Number of the plane, name of my hotel…
• Whether I was a criminal or not. Weapons, illegal substances…

After we landed, I was asked by a Border Guard about the purpose of my journey. “I came for a conference” I said. Then, he replied with a serious tone:

¿What is the conference about?

I didn’t know whether he was interested in the conference or he was not believing me at all. All I knew was I had been taking part of a long and unfriendly process. Unfortunately, on-line forms are normally not much different from border controls.

This year I have been involved in eGovernment and eCommence projects, where forms had a main role. I have heard different opinions from colleges, managers and clients regarding form design. Since I was decided to avoid users to feel like in a border control, I decided to search on guiding principles for web form design. Here I summarize some of the principles I tried to apply:

1. Avoid the unnecessary.

It is very frustrating when you are asked for information that is unrelated to the purpose of the form. As a designer, if information is not really needed, do not ask for it. In addition,  in case the information is needed, but it is not clear why, explain it to the user.

Another unnecessary task is to ask the user to format the data. If there is more of one way to format data (e.g., credit card or telephone numbers) you can chose among these options:

• Flexible input. Allow any input format and process it automatically (e.g., removing all non-numerical characters).
• Structured input. Decompose the input field in several parts (e.g., day, month, year instead of a single date field) to make it clear what to type.
• Fill-in-the blanks approach. Similar to the previous one, but embedding input fields in sentences to provide context.

Note that “tell the user how to format data as if the user were a machine” is not in the list. You can find more information about these input patterns.

2. Organize the information.

You can simplify the information by grouping related elements. Organizing elements into groups makes them look as if they were less. For an example, you can see the picture on the right consisting on two blocks of 36 dots (one in a single 6x6 block and the other arranged in three groups). 

Thanks to the Gestalt effect you can use space to arrange elements and define its visual hierarchy. So, empty space is not wasted space. However, not everyone has this notion. I have been told that some forms I designed had too much empty space.

One of the reasons for the previous complaint was that by using space, the user was forced to use scroll, a “fact” that was supposed to be terrible. The myth about users not using scroll seems to be quite widespread, but arranging all the form elements in little space can make forms cluttered and difficult to fill. 

To reduce complexity, you can split the form in different steps provided that information is given about the progress:

Regarding the specifics of form layout I have read some interesting recommendations from Luke Wroblewski and Caroline Jarrett:

Labels and fields. Common options for the layout are to place labels (1) on top of input fields, (2) left-aligned, or (3) right-aligned. Luke Wroblewski summarized the pros and cons of each option. The conclusion is that you can only optimize two of the following three factors regardless of the layout you chose:

• Ease of scan. Labels are easily scanned when their start position is aligned.
• Label-input association. Labels should be placed close to the input field in order to reinforce their connection. 
• Vertical space. The shorter the better.

Buttons. According to Caroline Jarrett, it is better to arrange the action button aligned to the left edge of fields since this is the first place the users look at after filling the last input. When more than one action is needed it is good to emphasize the primary action and do not separate too much the different buttons.

3. Provide guidance.

Although the layout of the form can make it easier to fill, the main reasons for a user to abandon forms are not related to layout. These reasons are:

• Questions that they don’t understand
• Questions that they have no answer for
• Intrusive questions that are inappropriate to the task
• Validations that refuse their preferred or correct answer

So, in addition to the “remove the unnecessary” principle, the user needs explanations that clarify what, why and how to answer. It is important not to confuse explanations with a bunch of text of instructions that the users are not going to read: Help text must be short and contextual. 

You can find very interesting examples on a great article on how to include helping elements.

4. Don’t be evil.

Don’t make things difficult on purpose. The use of dark patterns provides benefits in the short term at the expense of the brand credibility and user frustration. It is better to be honest and tell the advantages to the user. Websites such as Ryanair are examples on how intentional flawed design is used to win extra cash from the user.

Another common example is to force the user to register and validate his email address. This is specially annoying when the service requested has no specific need for the email address other than sending SPAM in the future (e.g., some software vendors such as Oracle or IBM download pages). Thanks to services such as 10 Minute Mail, users can fake easily mail confirmation. So it is better to explain the value of establishing a communication channel between you and your users than trying to force them by putting barriers to the process. It is a good idea to simplify the sing-up process as much as possible.

5. Look at examples.

I have read some excepts from Web Form design: filling in the blanks and Forms that work that have been very helpful in providing me guiding principles and examples. Furthermore, the web is full of examples of form designs. We, as users, are filling forms in the web on a daily basis.  We only have to pay attention to the problems we find in the forms we fill to avoid them in the forms we design.

Software engineering compared to Aircraft engineering: the feeling that something is out of control.

By observing these two faucets in the picture you could notice a crucial difference in terms of interaction:

It is true that you could achieve the same tasks with both faucet models: regulate volume of flow and temperature. But the key difference is that the design of Faucet A is driven by technology while the design of Faucet B is driven by user needs instead.

Faucet A has two valves because two pipes are used for hot and cold water (a technical reason) and you have to move both valves to increase caudal if you want to keep the same temperature. Conversely, Faucet B maps two different movements (up-down, left-right) with the control of volume of flow and temperature, and they can be modified without affecting one another. 

I thought it was a good example to illustrate the need for focusing on user needs (and not technology) when designing interactive systems such as a faucet or an Information System. 

Architecture has been influential to Computer Science. One example are Christopher Alexander’s patterns, which where adapted to the software world for the construction of Information Systems (programming patterns, design patterns, interaction patterns…). Another example is the use of concepts such as System Architecture or Information Architecture in the software industry.

Recently I take a look at the book 101 Things I Learned in Architecture School by Matthew Frederick and I found many interesting lessons that can be applied to software.

These are my selected 10 quotes from the 101 included in the book:

Design an architectural space to accommodate a specific program, experience, or intent.

The design of a building such as a school, a church or a hospital cannot overlook the activities they support. However, in Computer Science, the development is not always focused on the user needs and activities. Fortunately, the there is a trend in computing that puts the focus on the user in software development (user centered design, user experience design, or usability are terms with this idea in common).

Any design decission should be justified in at least two ways.

Don’t take your first idea just because it is good. Consider alternatives and trade-offs. One good example of this principle applied to software is Apple’s design process where 10 alternative designs are produced for each feature to select the best option.

A good designer isn’t afraid to throw away a good idea.

A good idea should not be imposed in a software product just because it is a good idea. Sometimes this idea is not what the project and the users really need (or it is conflicting with better idea). History of computer science is full of examples of software with good technical features that nobody uses. 

Three levels of knowing: Simplicity, Complexity and Informed simplicity.

An architect such as Mies Van Der Rohe remarked the power of simplicity with the sentence “less is more”. The balance between features and simplicity in software is a common battle. The concept of “informed simplicity” (simple but powerful) has been applied to the software field by John Maeda in his Laws of Simplicity.

In this book the 10th law is “Simplicity is about subtracting the obvious, and adding the meaningful”. This law is illustrated with an image that represents a 10 (it is the tenth law) with a “vanishing” zero (subtracting the obvious) and a strong number one (keeping/reinforcing the meaningful). Simple drawing, a powerful meaning.

If you can’t explain your ideas to your grandmother in terms that she understands, you don’t know your subject well enough.

In the software field we are used to find tons of acronyms that only help to introduce complexity and generate confusion. A sentence such as “this is a SOA-based product for the social media that combines p2p and web 2.0 architectures” is not much different from what you can hear out there. The essence of an idea can be described in a simple form, which is better for all. Books such as The back of the napkin show that any complex problems can be solved by a simple drawing. Conversely, below you can see a slide to “outline” the Microsoft Live platform:

A good graphic presentation meets the Ten-Foot Test.

Boring presentations with information overload and little graphics that nobody can read and follow from a distance also exist in the software area. Garr Reynolds provides essential tips for presentations (I personally tried to apply them in my thesis defense). Below is an example extracted from Garr’s blog:

No design system is or should be perfect.

As Voltaire stated “the perfect is the enemy of the good”. Great software projects such as Gmail have been proudly wearing the “beta” label (which means not only that it is not perfect, but that it is not even considered complete).

Manage your ego.

Sometimes you feel like managers, clients or partners are wrong about an aspect of the project. However, it is not important to determine who is right, but how the project is affected by each decisions.

Limitations encourage creativity

We all could create better software with fixed requirements and unlimited time and money. However, reality is different. If the chess game allowed pieces to move in any direction it won’t be a game any longer.

Just do something.

The term analysis paralysis is commonly used in software. The need to know every aspect of a problem before action is taken can lead to the project not to progress.  By acting instead, you can correct your assumptions and extract new knowledge from reality early and often. So keep on moving.