UI-patterns.com

Blog post: Towards building engaging relations

Tue, 23 Jun 2009 00:00:00 +0000

How do your customers feel about your company and the service you provide? Are they frustrated, energetic, focused, or just happy? Translate their emotions into how much value they will bring to your business and how loyal they are. How do you want your customers to feel, and how do you get them there?

Emotional states of your customer and how they relate to their value and loyalty.

The worst emotions your customers can have toward you are those of discomfort. Are they stressed because the product they ordered last week has not shown up yet? Are they frustrated because they fail to figure out how to place an order? Or do they feel neglected and irritated when customer service is either too slow or gives the answer they feared?

Customers with emotions of discomfort can destroy your business. On the short term however, it is your support team that will hurt the most, as customers with these emotions will return their products and call in with complaints. In the long term, these are the customers who could destroy your brand by either reactively or proactively communicating to other people how much you suck! Customers with emotions of discomfort can be your worst nightmare!

Marketing in the old days before the internet came along was all about attention. By investing money in TV, newspaper, billboard advertisement and similar mass-marketing channels, you placed a bid for for the customer’s attention. If you poured enough money into the funnel, you would win the auction and the money spend would be translated into sales. Those times are gone.

When you get the attention of new customers, they are interested in what you can offer them. You might even convert their interest into short-term sales. But more importantly, the odds of building a long-lasting relationship with the customer have been increased a notch. They are indifferent to your brand and product, but have a momentum of energy. Use their energy and explorative excitement to let them learn about you. Teach! Teach about how you can help them kick ass!

Once you have build a relationship to your customer that you are both fond of, the customer will recommend you if asked. They like you! Even better, they will come back for more! If they feel valued, have trust in you, and feel cared for, they will reward you with plentiful business. They will come back again and again, yielding returns much larger than the one-time fix you got from getting their one-time attention. Customers with emotions corresponding to this stage will recommend you if somebody asks. They are reactive rather than proactive.

If loyalty is your goal, you want to turn your customers into your ambassadors. In this state, your customers will advocate your products and proactively tell other potential customers about your products. This is the ultimate end-goal for word-of-mouth marketing: it’s the cheapest and possibly best marketing there is.

Notice the three levels of engagement used: indifferent, reactive, and proactive. Just as there are three levels of engagement on the positive side of the graph, there are also three levels on the negative side. There is however one big difference: Proactive behavior from customers with negative or destructive emotions toward you will be provoked much sooner and more frequent than customers with positive and pleased emotions. People are more bound to blog, speak, or engage with you when they feel angry, neglected, and are upset than if they are happy.

This post was inspired by the 1999 Seth Godin book, Permission marketing, which is about getting permission to build a relationship to your customer instead of just interrupting their attention constantly. The cluster idea and emotional states was greatly inspired by The DNA of customer Experience by Colin Shaw. Also, Kathy Sierra deserves some love for the now closed Creating passionate users blog. Finally, there’s also a splash of the Prospect theory and the value function.

Blog post: Why design patterns work

Wed, 17 Jun 2009 00:00:00 +0000

A design pattern is a recurring solution to a common problem. A solution for a problem that has been found to work well over and over. Such a solution over time becomes a convention.

Conventions are not limited to the online world, but is to be found everywhere in real world as well. As we grow up, we learn the convention of pushing a door-handle down to open its door and driving on the right side of the road (depending on what country you live in) to avoid nasty collisions. We learn to cross a street when the light is green and hold when its red. We learn how to read a newspaper by learning the conventions of page layouts and formatting to easier scan its information. In this way we can find the stories we are interested in quickly and efficiently.

Conventions all start off as an idea good enough to be imitated by others. Similarly, design conventions on the web stem from ideas on one website good enough to be imitated by another. As more websites copy an idea, it is exposed to the public as more and more see it. When it has reached a critical mass, it needs no explanation. This is when it has become a convention. The idea that solved a problem becomes a convention if it is common enough. If it also has a good amount of quality, it is a design pattern worth talking about.

Conventional design patterns provide a reassuring sense of familiarity to the user. When one is spotted the user immediately knows how it works and what it does. No unnecessary time needs to be spent to figure out how things work. The user does not need to think.

Take advantage of design patterns and the conventions embedded in them. Using design patterns may not win you the pulitzer prize for new and innovative thinking, but they will help you reduce friction and thus provide better usability. Innovate when you know you have the better idea, but use design patterns and conventions in all other cases.

It’s all about the execution.

Blog post: The 80/20 rule - the Pareto principle

Thu, 11 Jun 2009 00:00:00 +0000

It is a proven fact that 80 percent of the effects in a system are generated by 20 percent of the its variables. Use this to prioritize your design efforts.

The 80-20 rule claims that for any large system 80 percent of the effects are generated by 20 percent of the variables in that system. The rule has proven true in all large systems including those in user interface design as well as economics, management, quality control, and engineering among others.

The exactness of the percentages in the 80-20 rule is for illustration purposes only, why the rule has also been called Paretos Principle, Juran’s Principle, Vital Few, and the Trivial Many rule. There are plenty of examples of 90-10, 70-30, and 95-5 rules to underline the non-exactness of the 80-20 rule while also emphasizing its universal utility.

Examples¹ of the 80-20 rule include:

80 percent of a product’s usage involves 20 percent of its features.
80 percent of a town’s traffic is on 20 percent of its roads
80 percent of a company’s revenue comes from 20 percent of its products
80 percent of innovation comes from 20 percent of the people
80 percent of progress comes from 20 percent of the effort
80 percent of errors are caused by 20 percent of the components

Use the 80-20 rule to focus your resources in order to realize greater results. Identify what 20 percent of a products features are used 80 percent of the time and concentrate design and testing efforts on those resources. Or identify what critical 20 percent of a product’s features are responsible for 80 percent of the revenue and concentrate on that.

The 80-20 rule can help you decide what to redesign, what parts of a product or your time to downplay, what to throw away, or where to invest your scarce resources. It can help you resist efforts to correct and optimize designs beyond the critical 20 percent as more would yield diminishing returns.

The principle was originally used by the Italian sociologist and economist Vilfredo Pareto in 1906 to describe the unequal distribution of the Italian wealth where 20 percent of the people owned 80 percent of the wealth.

Discussion

The 80-20 rule displayed as a graph (green line). If all effort yielded equal results, the red line would be valid.

The essence of 80-20 rule is that things are not distributed equally. Each unit of work does not contribute to the same amount. In the perfect world, every employee would contribute the same, every bug be equally important, every feature equally loved, and planning would be simple.

The ratio can change and does not need to be 80-20. It could even be 90-20 (the numbers does not need to add up to 100). 20 percent of a workforce could be responsible for 90% of the results.

In economic terms there is a diminishing marginal benefit of adding extra resources. It can be argued that this also relates to the law of diminishing returns as at specific point, adding an extra worker will yield less marginal benefit than the worker added before. Using resources on the last minor details will not produce as much value as the resources used to build the core fundamentals of the product⁴.

A technique for prioritizing what tasks to focus your resources on is to categorize your tasks as A, B, and C – where the tasks marked with an A will yield greater results than tasks marked with a B, which will yield greater results than the tasks marked with a C. In many cases, the different tasks would not be prioritized in order of what will yield the most value, but rather what we think is the coolest. A sequence of tasks could be A,C,B,A,C,C,B,A,C,A – where if we were able to prioritize these tasks in the order of A,A,A,A,B,B,C,C,C,C it can be argued that we would end up with an end-product of much higher value with a given amount of resources available.

Sources

¹ Universal Principles of Design, William Lidwell et. al., p. 12, Rockport Publishers, 2003

² Vilfredo Pareto, Wikipedia.com, August 21st, 2008

³ Pareto principle, Wikipedia.com, August 21st, 2008

⁴ Pareto Principle, Better explained, August 21st, 2008

Read my earlier blog post on Prioritization of features explained graphically for more explanation and examples of this design principle.

Blog post: Give your users the backstage pass

Mon, 08 Jun 2009 00:00:00 +0000

As your web application become increasingly more complicated and deal with increasingly larger chunks of data it is possibly also going towards the path of being more unresponsive. Viewing a flash video in HD, Uploading a 300 MB file, or even ordering a physical product in a web shop will possibly leave your user on hold. Regardless of the waiting time being 10 seconds, 10 minutes, or 10 days, the user will be left in a state of not knowing.

Instead of just showing a load indicator or sending out a confirmation email, keep the user updated. Let the user know what is taking so long and how much more waiting there is to do. Provide upload progress graphics, explain what is going on in a simple message, or send emails to the customer knowing when his or her product is shipped and when it is going to arrive.

Give your users a clue about what is going on behind the scenes, and they will stay happy – even though they’re still waiting.

Read the Speed in software design blog post to read more about ways to prevent putting users on hold.

Blog post: Don't worry about breaking the abstraction

Wed, 03 Jun 2009 00:00:00 +0000

Having a good descriptive metaphor to guide your design will help you immensely! Abstracting your thoughts into a metaphor provides an already thought out solution to solving a design problem, and thus also hints to which paradigm solutions to unexpected challenges might be found in.

Just as developers use programming design patterns to to solve their problems, developers often make good use of metaphors to abstract out complex problems to something more familiar, concrete, and more manageable.

One of the more obscure abstractions I’ve made in my programming past was a SubscriptionJanitor class that through a cron job did daily clean up in the database, marking subscriptions with failed credit card transactions as disabled. Over time, the janitor took on more responsibilities and soon did more than just dealing with subscriptions and just janitorial duties, thus rendering its title obsolete. He was in for a promotion. The abstraction was broken and a new one had to be found.

As your design evolves over time, your will possibly also be bound to break your abstraction at some point in time. Don’t be scared. Find a new abstraction and possibly also a new metaphor to describe it. Too many designers and programmers are too fond of their own creation to break it, and thus prevents their line of thought to go beyond the metaphor. They will not break the abstraction even though sticking to it will hinder further innovation and progress.

Falling in love with your own creation – with your abstraction – will hinder you. Don’t fall in love with it, but be ready to move on when the time is right. When you start seeing yourself rejecting suggested features as they will break your precious baby, then it’s time. That’s a good sign. Don’t be scared to break it. It might just be time to move on.

Blog post: Exploring new patterns in interface design

Fri, 29 May 2009 00:00:00 +0000

Instead of just watching for established patterns in web design, why not try to go to the edge and search for emerging patterns that might just make it into the web application world in the near future? How about searching for new UI patterns outside the web world?

This is what Stephen Andersen did in his talk at FOWA Dublin (thank you Des Traynor for pointing that out to me). One of the patterns he discovered was the checkbox design from the iPhone:

There’s even a jQuery checkbox plugin for it already:

There are many possible sources of inspiration for your interface design. Have you seen any interesting patterns emerging into web design recently?

Blog post: Make people feel at home

Thu, 28 May 2009 00:00:00 +0000

How welcome do your users feel when using your product for the first time? How do you welcome them? Do you go out of your way to make people using your product feel comfortable and welcomed?

Most of the 37signals products uses the blank slate pattern to help get people started. In their Highrise web application, they even have a full “Welcome” tab in the menu dedicated to welcoming the first-time user. Once you feel beyond the welcome step, you can choose not to see the tab anymore.

At nouri.sh, a series of inline help boxes teaches you to use the application. At any time, you can choose to hide a help box if you feel like you’ve learned enough from it.

Flickr.com has had a long lasting tradition about greeting you in a new language every time you log in. One time, it will say ‘Ahoy ’, another it will say ‘Bangawoyo ’ with the subtitle “Now you know how to greet people in Korean!”. Such personalized fun messages makes the user enjoy himself and feel at home – and thus more forgiving, as Attractive things work better.

Good websites, as with good product design in general, make it easy to find your way around: leaving no doubt as to which button to click or handle to turn.

Blog post: Chase the unexpected

Wed, 13 May 2009 00:00:00 +0000

One of the basic challenges of building software is the lack of knowledge. We never know it all. Creating a new innovative product is hard to plan for, as we do not know where to look. Likewise, a perfectly rational decision is impossible as we will never know everything needed to make one. Even worse – at project start we often know next to nothing!

Innovation does not come from planning. Many discoveries and inventions over time were results of random accidents while tinkering with something completely else. Chance plays a big role.

So why not plan for chance? You can either take a passive role and wait for chance to happen – and even create the space for new ideas – but without aggressively chasing the unexpected chance, you are most likely in for a long wait.

Here’s a list of tips, tricks, and tools you can utilize to make chance go your way:

Be open to surprises! This is actually not as easy as it sounds. It’s about changing your mindset. Expect to find answers in unusual places – then the chance of innovation is far more likely to happen. Keep a buglist! Make a habit out of evaluating how things can be better. Could check-in be easier in the airport or could you help your local grocer selling more goods? Force yourself to think about it constantly. Always have a block of paper and a pen ready to scribble down your thoughts!
Seek out new sources of inspiration. Put yourself in unusual positions. Get away from everyday life and the settings are comfortable in. Staying in your comfort zone will make you do work as you have always done work and look at things the way you have always looked at things. Put yourself in physically different positions than what you are used to. Socialize with people whom you would not normally socialize with. Browse magazines and books you are not used to browsing – and spend time surfing on the net! The further afield, the better.
Broaden your field of expertise. Tear down the wall. Learn different approaches to what you are doing. Learn about processes in other industries – and about their methods and techniques. Cross-train your staff and do not only focus on your competition, but also on how non-competitive industries have solved similar problems.
Allow for alternate interpretations. Cultural probes can help you come up with new ideas while trying to make meaning of the works of others. A cultural probe could be you sending out a disposable cameras to to somebody in your target segment. Let them reply to 15-20 questions you made up, by taking pictures. When the camera returns and the film is developed, intrepid their pictures in find the new ideas blossom. The key is that the pictures are open for interpretation. You might interpret something else than what they meant – but that doesn’t really matter: the new ideas matter.
Hire outsiders. Hire people that are slightly off the center and that is not afraid to speak their mind. Is formal education always the most important thing?
Change hats. Try to walk in the shoes of your users. Construct archetypical personas and write narrative scenarios concerning the problem from the personas’ point of view.
Seek feedback. Put up photos, sketches, mockups, or posters up on your wall describing what you are working on in order to let people passing by giving feedback. Hold open houses and go-home meetings showcasing your work. Either throw one for the other departments, or invite external people from the industry.

Blog post: Tear down the wall!

Tue, 05 May 2009 00:00:00 +0000

Too often, I see programmers who just want to program, designers who just want to design, sales people who just want to sell, and researchers who just want to research. I believe that this lack of motivation to cross functional boundaries hinders smooth integrated work processes and provokes the phase-separated workflow much like the waterfall model that we have tried to escape from for so long. Perhaps most important of all, the functional separation hinders the kind of innovation that spurs from having a common tacit understanding across functional groups and having two or more fields being combined and exposed to one another.

Many companies feature this rigid separation of functions as well: they separate functions like programming, design, marketing, sales, and manufacturing – creating walls between groups that have much to learn from- and teach to- one another. In regards to innovation, such separation hinders progress more than it helps as with people who only keep to their own field.

Are we really past the waterfall model? We might be past the most obvious waterfalls within each functional field, but looking at the organization as a whole reveals another picture. Across functionally separated departments, still too many keep to their own turf.

Knowing about the domain, its users, and challenges provides a common shared base for discussion about a problem. It makes everybody involved in a project able to take qualified part of the decision process. If all team members fully understand decisions made throughout a project and their rationale, micro decisions made by individual team members will have a larger certainty of going along the lines of other decisions made and what was intended. Perhaps more important: if a new decision that goes against previous ones needs to be made, it is easier for the individual to evaluate whether it is for the better or worse if he or she understands the rationale behind previous decisions.

Understanding why we are doing what we are doing and where it will take us (the goal), makes it easier for each individual team member to make decisions on his or her own that follow the direction agreed upon by the group. This moves the decision process and workflow from being centralized to being decentralized. It allows more team members to chip in, more angles to be evaluated, and more concerns to be heard.

Each time knowledge or information is handed over across the functional-boundary-wall, it needs to be translated from tacit knowledge to explicit knowledge. When knowledge is translated from field jargon and relations not yet formulated to paper, nuances get lost. There are many shades of meaning, of which only few can be articulated.

So start setting up cross-functional groups with members of several different functional fields on your next project. Let everybody be part of the observation and decision process. I would argue that both clients, developers, designers, researchers should be out doing user observations. It is not enough to just see or hear what people say; you have to be there in person to interpret meaning and discover the underlying motivations and needs for yourself.

Blog post: User life-cycle

Thu, 30 Apr 2009 00:00:00 +0000

The product-life-cycle is a well known phenomenon that explains users’ adoption of new technology and by that also your product. The early adaptors are willing to pay a high price to be the first to play with new technology while the price is forced down when your product hits the mainstream due to fierce competition from the companies that lured on your product for new pray.

A far too overlooked life-cycle is the one of the user. A user of your product will only use it as long as it fits his or her needs. A user today might not have the same demands and needs of a product that he or she has tomorrow. The demands change over time as the life-cycle moves along.

A good example of such a life-cycle are the one of bloggers. Many bloggers start their activities using a free blog service like blogger.com or wordpress.com. Over time the demands of the blogger to the chosen service changes as the popularity grows and wish to earn money on advertising kicks in. This is a good time for the blogger to buy a domain and setup a new specialized blog for himself. Later in the life-cycle the blogger might even wish to turn his or her website into a magazine or other kind of specialized website.

Another example a company looking for help to manage their finances. In the beginning, at site like quickbooks.com might do the job perfectly, but as the company grows, the company might have needs that demand a more complex solution that might not even be on the web. Later on, this solution might even be discarded for something even more complex like MS Dynamics, or at a later stage, SAP.

Users are aware that their needs change over time, why they do not plan to stick with your product forever. With this in mind, you might actually want to consider making it easier for your users to switch phases. If you run a blog platform or a financial web application, make it easy to import and export data from and to other applications. Making it easy to import data makes immediate sense to most, as you of course want to lure users in to your machinery in order to milk them for money from now till forever. Sadly, however, you will never be able to lure anybody in to your machinery forever. Your users’ exit is inevitable at some point.

Make sure that you provide your users with an exit strategy from the beginning. This will lower the barriers for a user to sign up.

Where does your product fit in to your users’ – or customer’s life-cycle?

1. Curious pioneer
2. Happy amateur
3. Willing enthusiast
4. Agile professional
5. Bureaucratic professional

The user is your customer:

Blog post: It's about the whole experience

Mon, 27 Apr 2009 00:00:00 +0000

The quality of a web application cannot only be judged on the quality of the application itself. A myriad of accompanying services and experiences are connected with a product and is not and should not be easily separated from it. Is the web application easy to combine with other products and external services? Is it easily integrated into other products or services? Is the documentation sufficient and easy to use? Is there need for documentation? Is it advertised well? Do I feel welcome? How is the warranty and what are the terms of use? Is there personal confrontation in the sales situation, and is it easy to quit?

Making it easy to both join and leave

Some web applications makes it easy for you to join and even leave and uses this to help lower the entrance barrier of getting the user started with a service. Blogger.com and wordpress.com for instance makes it dead easy to import data from your old blog and even export your content once you decide to leave.

Basecamp is easy to integrate with your own system

The project management application from 37signals provides both an RSS feed of your projects’ activities, and an extensive API that lets you integrate the application with your own systems making you both read and write as much as you want. The openness from 37signals has resulted in several iPhone applications and has led other web app providers (30+) to offer seamless integration with Basecamp – all of which only makes Basecamp a stronger product.

When excitement is part of the equation

In January, I bought a ski vacation from Nortlander. There was nothing special about it until two days before my vacation started. This was when I received an email from Nortlander telling me about the snow conditions, the sunny weather forecast in the upcoming week, and that they looked forward for taking care of us. Even though it was easy to spot that it was a mass mail, my already high level of excitement rose even higher and was poured into my view of Nortlander as a company as well.

There are so many ways you can improve the whole experience

There are plenty of ways to improve the experience of your online product, that does not have to do with the web experience and application itself. When you are competing with many similar products, improving and focusing on neglected parts of the experience might just give you the edge you need.

Blog post: First results from the UI patterns investigation

Tue, 21 Apr 2009 00:00:00 +0000

The UI pattern survey initiative was launched without much fuss last week. With over 1000 replies, the data collected is slowly gaining momentum, and even though it is too early to make any empirically sound deductions from the results, I thought I’d share the outlook of what is to come.

Coordinate questions

The following questions were answered by the user being asked to locate a certain element. He or she then pointed the cursor to the element on an iframe and clicked it. The coordinate the user clicked on was recorded and the images below were the result.

All sites were viewed in a 1024×800 dimensioned iframe, which the images below illustrate. Each square on the image equals a 40px X 40px square in the iframe. White color means that nobody clicked on that particular square. Darker color means more clicks – that is more sites have the respective element located in this location.

All replies to questions are summed up per site basis and thrown away if the standard deviation is too big. If the data is valid, it is included in the final results.

Location of the search form or link

Location of login link or form

Location of account creation (sign up) link or form

There is more…

At the moment, there are 13 questions in the database right now, so go explore the rest if the above images was of interest.

If you would like any questions to be asked, then it’s really easy to submit one!

Blog post: The UI pattern survey initiative

Wed, 15 Apr 2009 00:00:00 +0000

This is a call-out for all designers, developers, information architects, project managers, writers, editors, marketers, and everyone else who makes websites. Now is your chance to get to know the web a lot better by helping sketching a true picture of how UI patterns are used today.

I would like to introduce The UI pattern survey

survey.ui-patterns.com

When writing about how user interface design patterns are used and should be used, there is no real empirical evidence for what is written other than personal observations, professional experience about what works, and pure common sense. At no point has any of the pattern libraries that exist on the web today tried to conduct a thorough investigation about the state of UI patterns.

The UI Pattern survey initiative has its motive to do just that. I’ve build an survey application in order to learn more about how design patterns are used on the web today.

The real value of the new User interface pattern survey is the ability for everybody to add questions and websites to be investigated. Consider this as an opportunity to finally get an answer to many of the questions you might have about how websites are built today!

Target: Large websites with a community

This is the first survey of its kind – many more will hopefully follow in the future. To begin with, only websites with account functionality will be investigated.

Open for all

This initiative is about obtaining knowledge. Do you have a question you want to ask? Well, then submit it to the system, and the survey will include your question! If you have a site that you think should be included in the investigation, then simply submit the site! The results of the survey and questions added at a later stage will be published once a sufficient number of replies have been obtained.

But I don’t understand…

…well, it gets interesting when you from the results can draw that in X percent of the cases, the login link is located to the left of the sign up link or that it is more common that a search button is decorated with an icon than without.

The extend of the possibilities of what answers are possible is extremely big and new questions can quickly be asked and answered within short amounts of time, as new questions will be favored over questions with lots of replies. You’ll get an answer quickly!

Spread the word

For this project to be of real value, it needs to gain momentum. So please do whatever you can to help UI-patterns.com spread the word!

Get started!

I can’t keep going on… and it’s certainly more fun to take the survey than reading this. So…

…Go take the survey now!

- Anders Toxboe

PS. For now, the survey is only available to Firefox and Safari users. IE and iFrames do not go well together!

Blog post: Low budget user testing

Thu, 09 Apr 2009 00:00:00 +0000

I recently attended a half-day seminar on best practices for handling redesigns of websites. The seminar itself wasn’t of much value – the only thing I learned is that we rock in our approach to building websites and their relaunches at my work, Benjamin Interactive.

The attendees at the seminar all reminded me of university professors engulfed by their scientific background. There are many ways of conducting user studies and tests. The “correct” way of conducting such investigations according to the academia is to ensure scientifically proofed data. This includes collecting enough data for the findings to be empirically true.

That means not conducting just one or two studies, but 10 or 20 – or even more. That means renting or building expensive user-test labs. That means hiring expensive experts to ensure unbiased data and maybe much more important: adding a difference between who is building a product and who is testing it.

This approach seemed to be the “correct” way of conducting user research when talking to the attendees at the seminar. I must have provoked more than a dozen when I told them all that I couldn’t care less for that kind of approach.

In my view, user studies should be conducted by the people building the product. A developer is not only a developer and neither is a designer. Developers and designers – the ones building the product – should know who they’re building it for – in person. Having somebody else do it for them allows for double interpretation of who the users are: one by the user experience experts writing it down on paper, and another by the developers and designers reading that paper.

Having studied HCI at the university, I’ve both tried the “correct” way of doing user research and a more loose guerrilla HCI approach.

In my view, the most valuable thing to gain from user research is feedback. The more rapid the feedback the better. From my experience, I haven’t gained much more knowledge from conducting user research the “correct” way than from grabbing a victim in the cafeteria for a 30 minute session.

My goal with user testing is to be able to rapidly test what I have just been building, correct what I’ve build with base in what the user test showed, build something more, test that, correct it, build some more, etc.

Have any of you out there experience situations where the “correct” way gave better results than the budget way of doing user tests? I can’t find any other reason than bureaucratic and organizational ones.

Blog post: Quality in web design: Business needs vs. user expectations

Sun, 29 Mar 2009 00:00:00 +0000

Evaluating the quality of web design is predominantly a subjective process as it needs to be evaluated in relation to some sort of demand or need of a user. It does not make sense to talk about good or bad web design only evaluating how pretty it looks. Most people do not use websites in order to be visually stimulated, but instead to find information, to make reservations, or keep in touch with contacts. They thus evaluate the successfulness of a website’s web design on its ability to deliver information sought, help make reservations, or facilitate keeping in touch with contacts.

Talking about good or bad web design in this way only makes sense if it is in the context of what the user expects. The most important part of the quality concept in web design is thus the user’s evaluation of the web design’s success and not the designer’s. Quality in web design is the degree of fulfillment of the user’s expectations.

When developing the website that makes your business run, we need to evaluate web design from a business perspective. However, relying solely on a business perspective of quality is dangerous.

Many websites are build on a concept of quality that relies on what the market demands and what currently works, but to prevent the foundation of our businesses from being pulverized by new competing products, we should rid ourselves from preconceived and esoteric opinions about what quality is. Instead we should evaluate the quality of our work with basis in the users’ mind and with an ignorance of what the market demands.

The key is to evaluate quality with basis in the user’s expectations to how a web design solves his or her needs and then pull down a business perspective, which in turn most likely will make us deviate our design from blindly living up to the users’ expectations.

Blog post: User interface sketching tip 5: Constrain yourself

Mon, 16 Mar 2009 00:00:00 +0000

This tip is similar to the tip given in the blog post “Use a Sharpie”. It is about constraining yourself from drawing small details and focusing on the idea, the concept and context. Does the overall idea seem useful? How does it deliver value? Would it fit into the full project and what the user is doing before and after using what you’re sketching?

To force yourself into refraining from focusing on the small details, set up measures to physically force you to do basic, quick, and dirty sketches. Some people set up deadlines with extremely small time available in order to move their focus from about less urgent issues to the task at hand. When sketching user interfaces, you can go small in a similar way.

Draw on post-it notes

Have a bunch of post-it notes ready and grab a pen. Now start sketching a full page on a single post-it. The very small paper forces you to only draw the most crucial and important parts of the interface. The focus on only the larger details of the wireframe provides a low entry-barrier and invite anyone to participate. Another good thing about post-it notes is that you can use the glue to put notes together to form a full walkthrough of your product.

Continued...

Blog post: Do best practices prevent innovation?

Thu, 12 Mar 2009 00:00:00 +0000

User interface design patterns are best practices – proven solutions that solve common problems. But can you really create new and groundbreaking products by building your web application like so many others have done before you? Is it possible to spawn creativity and innovation from using design patterns when these merely represent old and used practices?

Consider a design pattern library as a toolbox to implement your ideas. A design pattern is not a product idea itself, but more a possible ingredient. Combine these well-known ingredients to create something new faster and with less risk of failing than if you invented your own new ingredients from scratch. Few innovative products come out of nothing. Instead, creativity and innovation more often grows from combining the already known in new ways.

There are many factors that will make or break your product. Some important factors are the general concept, your target audience, the business model, and the execution. The latter is the only factor that design patterns are part of. Execution is about craftsmanship – about knowing how to build a solid product granted a foundation for such a product is in place.

Blog post: User interface sketching tip 4: Get your arm off the paper

Sun, 08 Mar 2009 00:00:00 +0000

This blog post is one out of several blog posts on improving your user interface sketching techniques. You might want to read the first three posts: Drawing corners and boxes, Drop Shadow, and Use a thick pen.

Get your arm off the paper

Resting your arm on the paper while sketching locks your lines into arcs, why trying to draw straight lines will only feel awkward and come out wrong.

Instead you should focus on drawing from the shoulder and not your lower arm. This will allow you to get a much better feel of both the paper and what you’re drawing.

Blog post: Speed in software design

Sun, 01 Mar 2009 00:00:00 +0000

Since AJAX became popular in web design, web applications has started to look much like desktop applications and has as such begun to suffer from some of the same design flaws. What I especially want to rid the world for is load indicators and meaningless error messages.

Load indicators remind me of the spinning beach ball in OS X or the animated hourglass in windows. They each represent a static state where the system is frozen and I am locked out not able to do anything!

How do you measure speed? Buying the fastest servers available and optimizing the hell out of your application will certainly do much, but it will not change the fact that you want to change the speed of your application that your users perceive. Whether this speed is improved by throwing a gazillion GB og RAM and MHz at your servers or merely setting up a few rules for how you design your application is up to you.

A few such heuristics could be:

Ban load indicators! Get rid of unresponsiveness. Do not take the user as a hostage while he or she waits for an operation to finish. This could be expressed as getting rid of the wait cursors – they are a sign of bad design; Do something else instead. Even though 30 boxes use load indicators in their calendar, the application is far from unresponsive.

Eliminate extra steps. Go through your application and count clicks and screens needed to perform an action? How can they be minimized?

Let the user know how far they’ve gone. Your application will seem unresponsive if you do not provide your users with a clue of how long lengthy operations will take. Failing to let the user know how far they are in a process will create more problems for your in the long run: how are you supposed to do with the data a user has entered in a Wizard if he or she drops out in the middle?

Continue or abort. Your system should be able to recover from its own problems! Sure, the user cares about what went wrong, but it is not their problem. It’s yours! Do something proactive instead than asking them if they want to continue or abort because your system caused an error.

Perform client-side validation. Instead of letting the user take an extra roundtrip to your server and back to validate the date they’ve entered, perform client-side validation of their data and save them the trip.

Preload data. You create a Google AdSense ad by clicking through a 3-4 screen wizard. What most do not realize is that the entire form of all 4 pages is loaded at once. This means that clicking next merely releases a javascript action that hides the current screen and displays the next. A similar thing is seen in the Facebook picture gallery where preloading the next images makes the experience seem super smooth. On top of that, the <a name /> value is changed each time an image is clicked, so that the URL will always point to the image you’re viewing.

To sum things up: Design for responsiveness! The software should be able to keep up with its users and not let them wait. What really matters is the perceived speed and not the actual real (machine) speed.

Blog post: User interface sketching tip 3: Use a thick pen

Wed, 18 Feb 2009 00:00:00 +0000

This blog post is one out of several blog posts on improving your user interface sketching techniques. You might want to read the first two posts: Drawing corners and boxes as well as Drop Shadow.

Use a thick Sharpie

Sketching out a user interface is not about details but about concepts. It is about sketching – not drawing. When you draw, you tend to worry too much about making the details look good. This is why you might want to choose to utilize a medium or broad point permanent marker (Like a Sharpie pen or similar) to sketch your interface, instead of a thin point one – or a bullet point pen. So sketch big and focus in on loose form rather than tight line accuracy.

This is also why many find sketching interfaces on a whiteboard especially useful. Being forced not to draw details constraints your thought process into focusing on the concept and ignoring the details.

Some people prefer using crayons over Sharpies as Sharpies often bleed through the paper.

The above illustration illustrates how the sketcher tends to get into details when drawing with a thin marker. The thin sketch is both more correct and more appealing, but at the same time feedback on the thin sketch revolved more around details than the concept. The thick sketch was drawn about 10 times faster, and has its focus more on the concept. With the thick sketch, the sketch could be redrawn and iterated 10 times faster than with the thin sketch. It’s all about rapid prototyping and instant feedback!

Design pattern: Completeness meter

Wed, 24 Jun 2009 00:00:00 +0000

The user wants to complete a goal but needs guidance in when it is reached and how to reach it.

Continued...