I attended a presentation last night by Alistair Cockburn. He is one of the authors of the agile manifesto and the presentation covered some of his latest thoughts on agile. Here is a summary of the points that I found most interesting.

Software engineering is a poorly chosen term. Software design and development is really a craft rather than an engineering discipline. There can't be a single, optimal process because software is developed by people and people are different. There are different motives, cultures, objectives, personalities, etc. that all influence how a project will evolve.

Agile is not so much a process as a set of techniques that should be tailored to fit the situation.

You can never get it exactly right in software development, but you should be constantly learning and improving. Waterfall methods are late learning. At the end of a project, you recognize things you have done wrong and that you may be able to improve next release. With agile, learning and adjustments happen throughout the process.

Process cannot fix all problems. For example, if two of the key people on a project hate each other, no process in the world will ensure that there is good communication and cooperation between them.

Large projects have large communication penalties. The more people you must communicate with, the more time you spend communicating and the less writing code or creating other deliverables. If you have two developers in a room working on a project, communication is easy and efficient. As you increase the number of people or the distance between them, communication becomes more difficult.

Paper is the most common form of project documentation, but also the least efficient. The most efficient form of communication is two people talking face to face with a whiteboard.

Distance is one of the factors that effects process. On one project Alistair was involved in, the UI designers were in Norway and the developers in China. The developers complained that they could not work efficiently because the UI designers kept changing the design throughout the iteration. The UI designers took a trip to China and then the process worked fine. They were still changing the UI design throughout the iteration, but, because they were in the same building and the same time zone, the changes could be communicated immediately and the reasons for the changes were clear.

Transparency effects productivity. The more everyone knows what everyone else is doing, the better coordinated they will all be.

Look for the bottlenecks in a project. Many people try to eliminate bottlenecks, but that is impossible. If you remove one bottleneck, another point becomes the new bottleneck. Some are difficult to eliminate. For example, maybe one job optimally requires 1.5 people, but you can't efficiently assign a fractional person. It is best to just accept that there will be bottlenecks and to make sure the bottleneck does not slow the project. For example, if database design is the bottleneck, make sure that designer has everything they need when they need it. In other parts of the process, inefficiency is not necessarily a bad thing. Areas that are not the bottleneck can "waste" some time without affecting the end date or success of the project. One way to use the extra time for people outside the bottleneck is to make your best guess and charge ahead. One one project Alistair was involved in, there were two options (A and B) and much debate and research was needed to make a decision. While that was going on, he told the developers to implement B. There was a 50% chance they would guess right. If they were right, time would be saved. If they guessed wrong, they would be no worse of than if they sat on their hands waiting for a decision and in all likelihood they would at least learn some things. When the decision came back to do B, it was already completed.

You should do knowledge acquisition tasks early in a project to reduce risk. Do the things you aren't sure how to do first. The things you know how to do you can estimate with greater confidence and they can be left to later in the project with little risk of delaying the end date.

You need to understand the business to understand how to optimize the process. When Alistair first starting to work with defense contractors, he couldn't understand why they would move key people off a project in the middle. This decreased the quality of the outcome. Most companies make money by creating the best product they can. Why purposely hurt a project by removing key people at a critical time? He came to understand that defense contractors make their money by winning contracts. They need their A team to do that. When the project is underway, the A team is better used to win the next contract while letting the B team deliver on the current one.

More information on Alistair's work is available at http://alistair.cockburn.us/index.php/Main_Page

I attended the SXSW Interactive conference in Austin, TX March 8-11. Here are a few notes from the sessions I attended that may be of interest.

Session: AJAX and Flash Mistakes

• Showed examples of common mistakes made when designing rich client applications and websites
• A copy of the presentation is available at http://www.slideshare.net/jboutelle
• Recommends the book "AJAX Design Patterns"
• Minimize the use of animation. Since rich client technologies support many types of animation, designers tend to overuse it making the app very busy and confusing.
• AJAX messes up website metrics. Google Analytics will be adding events to address this.
• Flash gives you access to system resources such as speakers and the microphone.
• One of the main advantages of rich client interfaces are to make the UI more responsive and efficient to use. One way to take advantage of this is to display information in place and reduce the number of pages the user must navigate through.

Session: 10 Things We've Learned at 37 Signals

• Err on the side of simple. In addition to making your product usable, you should limit the number of features. Provide only the most important and frequently used features. This simplicity makes the product easy to develop, easy to support, and easy to use. Let someone else built the big complicated products for the small percentage of customers who need that complexity.
• Target areas with little competition. Big companies typically aren't interested in small markets so they are underserved.
• 37 Signals has over a million customers for their simple, low feature products like Basecamp, Backpack, Highrise, and Campfire.
• Provide a great work environment and you will be able to attract great people, retain them, and motivate them.
• Keep your product release cycle short. People are most productive when working on something new and exciting. They lose enthusiasm on long projects.
• Build by sharing. Use and contribute to open source. Find ways to get your customers involved in developing your products. You gain more by sharing than you would by trying to keep things secret.
• Interruption is the enemy of productivity. At 37 Signals, they encourage employees to work as if they are remote even if they are in the same office. For example, send email rather than hold a meeting. This reduces interruptions and helps to document decisions. Four hours uninterrupted is far more product than the same amount of time broken into 15 minutes chunks between interruptions.
• Be responsive to your customers. If you solve a problem for a customer, they will typically be more satisfied than customers who never had a problem.
• Celebrate little launches. Morale feeds progress.
• Make lots of tiny decisions. If you make tiny decisions, you don't make big mistakes.
• Focus on the things that matter and feel free to ignore the rest.

Session: Social Influence Marketing

• Know how your customers think and design your website accordingly. For example, buying furniture typically involves comparing multiple products and fabrics and getting opinions from your spouse and perhaps friends or relatives. Most furniture websites are designed as if they think one person just looks at a couch and immediately buys it.
• Customers today are more influenced by social factors than by brands.
• Customer reviews are very important to purchase decisions. People look at sites like epinions to see what the experiences of others have been before making a purchase.
• It is wise to let customers get this information on your website rather than go somewhere else. For example, the Sheraton hotel website lets customers post reviews of their experiences at a location. Companies should not fear this unless they don't have confidence in their products.
• Everyone in a company should be talking to customers. Not just the marketing folks. Design teams, in particular, need to be getting customer requirements and feedback in order to produce better designs.
• Communication needs to be two-way even on your website. A company website is not just a way to publish, but a way to hold a conversation between the company and its customers.

Session: Life After iPhone

• The iPhone has dramatically changed the mobile device landscape.
• It was previously very difficult to create mobile apps because there were so many devices with so many different screen resolutions running so many different browsers.
• iPhone is one of the first mobile devices to provide a full featured browser. Most any website designed for a desktop client will run fine on an iPhone although it is also possible to optimize websites and web apps specifically for the iPhone.
• A VC fund (iFund) is offering $100 million to fund development of iPhone apps.
• The iPhone is an example of a disruptive device. It doesn't follow existing standards of interaction and thus requires fresh thinking. Design groups may need to change their deliverables. They will need to do more experimentation and prototyping. More disruptive devices are likely to follow.

Miscellaneous Musings

• After a big dip in attendance in the early 90s, conference attendance continues to grow.
• There have always been more Mac than Windows laptops at the conference, but this year the ratio was much more lopsided. It looked to me to be about 90% Macs. This seems like an indication of how much Apple has captured the hearts (and pocketbooks) of the design community.
• Lots more small mobile devies too, particularly iPhones. Many people seem to be finding a small mobile device to be a viable alternative to a laptop now for things like taking notes at a conference.
• In several sessions, speakers talked about how their websites became businesses by accident. They would start something as a hobby or from personal need and it suddenly took off. There still seems to be plenty of opportunity on the web, but it is difficult to predict what will be successful.

• Ease of use is part of the corporate culture. Each and every person on the development team strives to design a product which is usable.
• They must have a development process that accurately evaluates user needs and creates products that successfully address those needs.
• They prototype and evaluate designs continually throughout the development process. It may not be a formal usability test with external users, but they do conduct informal usability evaluations.
• They observe what happens after the product is released and correct problems in subsequent versions.

Apparently the iPod Touch is so easy to use that even a dog can use it ;-) http://gizmodo.com/gadgets/ipod/even-a-dog-can-scroll-through-pics-on-an-ipod-touch-309847.php

I read the annual "100 best companies to work for" issue of Fortune magazine. One article made the point that providing a great work environment is not just a nice thing to do, but it pays off financially. It allows a company to attract the best workers, keeps them motivated and productive, and reduces turnover. It surprises me how few companies understand this. I hear so many stories from my friends about companies where minimizing cost takes precedence over all else.

Watching the Super Bowl, I was pleased to see an ETrade ad that emphasized usability: http://www.spike.com/video/2938285/collection/25701/minisite/superbowl

The 2008 version of the bad usability calendar is now available at: http://www.badusability.com/

Google labs has issued an open invitation to try some of their new ideas and provide feedback. Sort of a public usability test. Interesting idea. http://www.google.com/experimental/index.html

Here is a nice set of design templates from the Information Architecture Institute that I ran across recently: http://www.iainstitute.org/tools/

Is it just me, or do you think technology is becoming a little impersonal sometimes? http://www.washingtonpost.com/wp-dyn/content/article/2008/01/14/AR2008011402011.html?wpisrc=newsletter

Here is an interesting comparison of recent Apple designs to some from Braun in the 1960s. http://gizmodo.com/343641/1960s-braun-products-hold-the-secrets-to-apples-future

US News listed usability specialist as one of the best careers for 2008: http://www.usnews.com/features/business/best-careers/best-careers-2008.html

Gestural Interfaces

3DV Systems showed games and media applications that the user controls through hand gestures. A camera recognizes the gestures so the user does not need to hold a controller or wear gloves. Some applications required that the user learn specific gestures such as to control menus and make selections. Others were free form and natural such as making boxing motions to use a boxing videogame.

Toshiba demonstrated a DVD player where the user could control playback by pointing a finger in the direction they wanted to video to advance or putting their palm up in the universal sign for stop.

Microsoft showed Surface – a computer built into a table with a multi-touch interface.

CNN has an article discussing some of these products at http://www.cnn.com/2008/TECH/01/10/ces.pcwii.ap/index.html

A somewhat related area is devices that sense the presence of a user and react to it. For example, iTouchless demonstrated a trash can that opens when you move your hand over it or throw something at it.

Large Displays

Displays are getting larger every year. Much of this is being driven by the HDTV market, but many of these TVs can also be used as computer monitors. The largest this year was a 150 inch plasma TV from Panasonic.

There is also a trend toward connecting multiple displays together to provide a larger virtual workspace. Crown Trading Systems demonstrated a stock trading application that utilizes 16 monitors driven from a single computer.

Programmable Keyboards

Several companies showed programmable keyboards where tiny displays were built into the keytops. This allows the icons or labels on the keys to be dynamically reassigned. I worked on banking applications at IBM where we dramatically improved productivity for certain applications by creating custom keyboards optimized for the tasks the user would perform. These programmable keyboards hold the potential to customize the keyboard dynamically for multiple applications.

Biometrics

Biometric devices such as thumbprint readers and iris scanners are being built into some computers. Some organizations are requiring this. For example, I have a friend who does software development at a large bank. They use an iris scanner for access to the facility because is much more secure than ID cards, passwords, etc.

Haptics

Delphi had some good examples of haptic controls. They have developed controls which provide haptic (touch) feedback when the user operates them to, for example, control the radio or climate controls in a car or change what is shown on the instrument panel. Haptic feedback helps the user make changes without having to take their eyes off the road. The Delphi system allows the user to change the nature of the haptic feedback to whatever an individual user prefers or finds most effective.

Many game systems also had haptic controllers that give the user feedback on what is happening in the game.

Ambient Devices

The Ambient Orb has been around for a couple of years now. It is an internet connected device that glows in different colors to indicate changes in data such as stock prices or the weather.

These devices are now being built into more things, such as an umbrella where the handle glows to inform the user when rain is predicted and they should take the umbrella with them. The devices are also being expanded to provide feedback through more than one indicator. A whimsical example is the iBuddy. It is an angel-like figure designed to be used with instant messaging. Its body glows to indicate when a friend is online and the wings flap when you receive a message.

Robots

Many robots in a wide variety of forms where on display at the show. Some are very sophisticated with the ability to move, to avoid obstacles, to grab and manipulate objects and to connect to the internet. One salesman told me he has programmed his robot to come into his bedroom in the morning and wake him up by singing, then move to his children’s rooms and wake them. It then comes to the kitchen to read him the news and weather while he has breakfast.

Today, computers are all around us. Not only the laptops and desktop systems we all recognize as computers, but also imbedded in devices such as cars, microwave ovens, televisions, etc. I think we are about to see computers become imbedded in nearly everything. An interesting example I ran across today is a computer in an umbrella. It monitors the weather forecast and the handle glows to let you know that rain is expected and you should take the umbrella out with you. http://www.ambientdevices.com/products/umbrella.html

If these products are well designed and easy to use, they will make our lives easier. If they are complicated and unreliable, they will just create more work for us.

I'll be attending the Consumer Electronics Show next week and will report back here on the most interesting things I see there.

In the web 1.0 world, and earlier, companies had to make a specific effort to reach customers and they seldom communicated enough. With web 2.0, customer feedback can be an integral part of websites and products. Often, this feedback is public. So customers are not only relating their needs and experiences with the product, but also reacting to the feedback from other customers. This gives the development team much better information about what customers need and want. It can also increase the customers' commitment to the product as they invest time and energy into improving it and see this result in the product better meeting their needs.

I think one reason is that, for enterprise software, the buyer is often a different person than the user. The user may care about ease of use, but the buyer is more likely to be shopping for the lowest price or the longest list of features. It is tempting for software developers to give higher priority to the desires of the buyer. The buyer may also be impressed by flashy visuals while the user will be more concerned about whether the software helps them accomplish their tasks and is efficient to use. For consumer software, it is more typical for the buyer and the user to be the same person.

A second reason is that enterprise software seldom gets critiqued the way that consumer software does. You can't just pick up PC Magazine and find a comparative review of enterprise software products. Feedback and open competition are important factors in the evolutionary improvement of products. Khoi Vinh of the New York Times discusses this in his blog at http://www.subtraction.com/archives/2007/1019_if_it_looks_.php

A third reason is that enterprise software is often designed for too many different types of users with different skill sets and different needs. After all, the more users the software is designed for, the more seats you can sell the customer. Trying to be many different things to many different people, however, can mean it doesn't meet the needs of any one user very well. In software as in clothing, one size fits all just doesn't work very well.

A fourth reason is the attitude that the problems to be solved by enterprise software are hard therefore the product must be hard to use. It is true that the problems to solve may sometimes be hard, but too often this is used an an excuse not to try to simplify the UI. Even if it can't be made easy, it can always be made easier.

A fifth reason is that the needs of a single customer can have undue influence on the design. If a consumer product has a million users, the manufacturer would not consider changing the design to meet the needs of a single customer. They design for the majority. With enterprise software, the number of customers is much more limited and, if Megacorp who buys a million dollars worth of your product per year wants a change, you typically make it even if that change is not needed by any other customer. Those changes can add up and over, time the product can become a little of this and a little of that like Frankenstein's monster.

For a sampling of some of the complaints people have about enterprise software, check out the article "Why Enterprise Software Sucks" at http://www.37signals.com/svn/posts/669-why-enterprise-software-sucks and look at all the comments.

Enterprise software doesn't have to suck though. These are all solvable problems. You just need to be aware of the pitfalls in order to avoid them.

If you have other thoughts on the usability of enterprise software or examples of particularly good or bad products, let me know in your responses to this blog.

We wanted to explore the feasibility of taking one of our enterprise apps designed for larger systems and scaling it down to run on a small mobile device like the iPhone. We investigated changes needed to the UI to be appropriate for a small display, utilizing the multi-touch interaction style of the iPhone, and to see how hard or easy development is for the iPhone.

The application we chose for this is called BMC Service Request Management http://www.bmc.com/products/proddocview/0,2832,19052_0_77980702_148142,00.html . It allows anyone in a company to request a request an IT or other business service such as resetting a password, or fixing a connectivity issue. We pared this application down to the basic features that a customer would be most likely to want on a mobile device – the ability to recreate a request and to track the status of existing requests.

The iPhone turned out to be surprisingly easy to develop for. It is similar to creating a web application running on the Safari browser. There is little iPhone specific coding required.

The Dev Camp lasted 48 hours from 6 PM on a Friday night to 6 PM on Sunday night. There were almost 400 developers in attendance and it was a fun and cooperative environment with lots of talented and creative people doing interesting things and always willing to help others. We were able to put our application together and have it ready for the demo session Sunday afternoon. A video of our demo is available at http://blip.tv/file/306971

David Pogue at the New York Times wrote an interesting article about the problems he had installing and configuring a NetGear wireless adapter. You can read it at http://www.nytimes.com/2007/04/12/technology/12pogue-email.html?_r=2&oref=slogin&oref=slogin  so I won't repeat it here, but let's just say that it proved to be very difficult even for a guy like David who earns his living as a technology reviewer. There are so many computer products that are waaay too complex to install and configure. Companies will put lots of effort into designing an elegant product then slap together an install at the last minute and push it out the door. This makes no sense to me. Any time and money they save on creating a quick and dirty install is lost many times over in support costs, returns and lost sales. If a customer can't install the product then it is of no use to them. The same degree of care in design, development and testing that is done for the product needs to be done for the install.

Airlines have always struck me as one of the least customer centric industries. "Freedom seating" is a new proposal to cram even more people into an airplane. See http://www.engadget.com/2007/04/17/freedom-seating-concept-packs-even-more-bodies-onto-the-plane/ . Let's hope this is an idea that doesn't fly.

The web is a great communication tool. Some people document their whole life on their blog. I knew it was only a matter of time until someone put themselves on the web live 24 hours per day. Check out http://www.justin.tv/

I mentioned multi-touch interaction a few months ago, but I recently came across a video that provides a more impressive demonstration of it - http://www.freshcreation.nl/comments.php?id=973_0_1_0_C . It reminds me of the futuristic UI Tom Cruise used in the film Minority Report, but it is here now and working. I have seen the future and it looks like fun!

Technique for quickly prototyping a website: http://noonebelongsheremorethanyou.com/ . This one is amusing, but actually does have some practical value. When I worked for a startup company and was under extremely short deadlines, I actually photographed my whiteboard and put those pictures in a spec for the developers. I saved enough time to have the luxury of sleeping a fews hours most nights.

The bad usability calendar: http://www.iallenkelhet.no/bad-usability-calendar-2007-is-here . It illustrates design mistakes.

Using real-time 3d visualization techniques: http://infosthetics.com/archives/2007/04/netcosm_3d_network_monitoring_world.html .

http://demo.quietlyscheming.com/book/Anatomy.html

In the mid-90s, I was part of a team at IBM that developed the RealThings interaction style at IBM. http://www-03.ibm.com/easy/page/581 It would have been the basis for the next generation of OS/2, if that operating system had survived.

Here are some of the technologies that PC Magazine suggests may be part of Web 3.0:

The Semantic Web: Websites will be able to understand and interact with other websites. For example, if you need emergency dental work, you could instruct your computer to check your schedule against the schedules of all the dentists within a 10 mile radius and set up an appointment.

The 3D Web: You could navigate through 3d environments much like the videogames that are so popular today, but for business or other productive purposes. For example, you could go house hunting across town or take a tour of Europe without leaving your desk.

The Media-Centric Web: You will be able to find media using other media rather than just keywords. For example, you could feed a search engine a picture of your favorite painting and will will find similar paintings.

The Pervasive Web: The web will be everywhere, imbedded in things all around us. For example, your house could monitor the weather via the web and open or close windows based on the temperature and threat of rain.

Some of these may seem a bit far out, but who would have guessed a few years ago that the web would be what it is today?

Here are some analogies to compare GUI and command line interfaces courtesy of Lyle Kantrovich.

Command Line (CLUI) 
...is like ordering a meal from a short order cook, when you know what 
they can serve, how they can prepare it, and exactly how to order it. 
For example: 
"Hey, Mac, give me a Pope Benedict and Sweet Alice with mystery in the 
alley, on wheels" (to decode this, see 
http://en.wikipedia.org/wiki/Diner_Lingo) 

Graphical User Interface (GUI) 
...is like having a menu (opportunistic pun) and a waiter who tells 
you what the specials of the day are. Of course, half of the time, 
after you order they tell you that they're out of that. 

GUI "Specials of the Day" today: 
1. "Do you know you have unused icons on the desktop?" and 
 
2. "Microsoft Update, Adobe Updates, Google Updater, and Installshield 
Updater all have updates for you to download and install...Mr. 'I have 
nothing else to do but keep my software updated'...oh, and did I 
mention that your two anti-virus and three spyware apps all need 
updates? The next time you visit, maybe I can interest you in 
upgrading your firewall to something other than that free version that 
came with your computer." 
 
The GUI Fast Food Server: Mr. Wizard 
"Great...so you're ordering the #2. Would you like fries with that? 
Are you sure? Please read this Fries 2.0 license agreement and select 
'I Agree' before continuing. Great. Where would you like me to put 
the fries? Installing potatoes...Oops, sorry, there's not enough 
space left on your plate." 

What are your thoughts? Should BMC provide command line interfaces in addition to our GUIs or are you happy with a GUI alone?

I attended the SXSW Interactive conference in Austin, TX March 10-13. Here are a few notes from the sessions I attended that may be of interest.

I have always found this conference to be a good way to get the pulse of the web world. During the dot com boom it was crowded and the attitude of attendees was almost euphoric. Then, after the crash, the conference shrunk dramatically and the attitude was somber and defeated. A panel session that illustrated this had a set of twenty something dot com founders during the boom. They excitedly described how it was a new economy where the rules of business had changed. They were awash in venture capital and were rapidly building companies that they had no doubt would be tremendous successes and change the world. The next year the same people participated in a panel about dot com failures. Their companies had all gone out of business.

Over the last several years, the conference has again grown large and the attitude is once more upbeat without the euphoria and excess of the past. That attitude now seems to me to be reasonable and appropriate. Everyone has learned from their mistakes. They now seem to have learned how to build successful and sustainable web businesses.

Session: Why we should ignore users

• Feedback from different users are often contradictory. Ask 10 different people and you may get 10 different answers.
• Some of the users' needs are subconscious and do not get expressed.
• Users may not know what is possible.
• The more users you have, the wider the range of reqs and the more complex the product.
• What users ask for is not always what they really want. For example, McDonald surveyed customers and they asked for a low carb burger. When this was added to the menu, however, it flopped.
• Some products are new and have no existing users. User feedback is more useful when doing new version of an existing product than in design of a new product.
• A good UI has some unexpected features that users didn't ask for.
• Need to design for indirect as well as direct users.
• It is more effective to hire great designers than to do lots of testing.
• Testing should inform design, not drive it.
• The more foreign the task domain is to the designer, the more important it is to involve users.
• Short development cycles make it difficult to follow a User Centered Design process.
• Users will typically not ask for or may even resist a complete redesign, but sometimes that is what is needed.
• As an alternative to radical change, you can change incrementally or allow the old version to coexist with the new.
• Need to narrow design artifacts to the essentials. For example, personas should include task activities, not irrelevant personal attributes.
• Great designers can design terrific user interfaces without customer input.
• [Scott] I feel compelled to editorialize on this session. While many of the points made have some validity, there are ways handle each of them. I have always found user input to be vital to good design. There may, perhaps, be some great designers who can skip a user centered design process and user input, but most of the people who think they are one of those great designers are not.

Session: Opening remarks by Kathy Sierra

• Kathy is the author of several books and a blog at http://headrush.typepad.com/creating_passionate_users/
• Need to add some humanness to apps.
• Need to get customers past the suck threshold
• If a UI is good enough, users will be passionate about it.
• Help and docs should be conversational.

Session: Stop designing products

• When a new technology comes along, it just has to work. Next phase is to pile on features. The third phase is typically to make it easy to use.
• The experience is the product.

Session: Corporate accessibility

• A free online book about accessibility is available at http://www.uiaccess.com/justask/
• The University of Texas had a competition and gave awards as a way to incent their webmasters to make their website accessible.
• It is important to have an accessibility evangelist.
• Offer consulting to help teams make their sites accessible.
• Like WebXM as a test tool.
• Building a website to be accessible costs no more money than making one that is not.
• When Chevron started their accessibility effort they felt it was unreasonable to fix all 120,000 pages in their website. Decided to do it on all new pages, not revisit old pages.
• A good website for accessibility info is http://webaim.org/articles/implementation/
• Need to train developers how to write accessible code and give them an appreciation why they need to.
• The Netherlands has a government run accessibility certification and other countries are likely to follow.

Session: Design patterns

• Patterns are a good intermediate between principles and guidelines.
• They allow you to more efficiently build websites or products with greater usability.
• A good book on UI design patterns is http://designinginterfaces.com/
• Yahoo has an excellent design pattern library that they use and have made available to the public - http://developer.yahoo.com/ypatterns/

Session: Death of the desktop

• The GUI interfaces and desktop metaphor that we use today is about 25 years old.
• http://humanized.com/ has created products that are command driven based on the work of Jeff Raskin.
• To the user, the interface is the product.

Session: Customer service is the new marketing

• Great service turns customers into evangelists.
• http://www.zappos.com/welcome.zhtml spends money on customer experience rather than advertising. Free overnight shipping, free return shipping, 365 day returns. Will not offshore customer service because quality is important. Try to maximize long term revenue from a customer rather than any individual transaction. Have a 4 week training program that all employees take that teaches them the culture and how the business works. The call center has no scripts. Employees are empowered. Have gone so far as to send flowers to unhappy customers. Customer support is their second highest cost after the product itself. Have decided to compete on service rather than price.
• http://30boxes.com/welcome.php Fixing bugs in a timely fashion results in satisfied customers even though they have had a problem. Have a support forum so that users can help other users. Often fix bugs within minutes while competitors sometimes take months.
• http://flickr.com/ Have an idea forum where customers can make suggestions. All employees have to spend some time in customer care. When they had to take the site down for a serious problem, they held a coloring contest. Participants got a free subscription to Flickr Pro. Turned lemons into lemonade.
• Lawyers often advise companies to never apologize, but the companies in the panel have found that customers appreciate and respect apologies.
• Some companies make it difficult to cancel an account. This may help protect some revenue by holding customers hostage, but creates ill will and bad word of mouth.
• Aggregator services sort providers by price, it would be great if you could sort by quality of service.
• Google searches for blog mentions of their services and then responds to negative comments.
• A good blog about customer satisfaction is http://blog.getsatisfaction.com/

One of the ways to design better products is to keep aware of innovations and utilize the ones that make sense in your own products. User interface ideas often transplant well across domains. For example, ideas than come from consumer products will often fit in enterprise products and vice versa.

For example, we noticed a couple of years ago how tags where being used on sites like Flickr to make searches more efficient. We added tagging to BMC Performance Manager so that users could tag any of the objects being monitored and managed with any tags they wanted to create. We took this one step farther by automatically tagging objects with system generated meta information. We created dynamic tags for information that changes such as object status. Tagging has proven to be a very useful and powerful feature that allows users to quickly find the objects they are interested in and even to navigate using searches instead of the tree.

Here is a video that shows what it is like for someone reading a book for the first time. http://www.youtube.com/watch?v=eRjVeRbhtRU It is a bit humorous and exaggerated, but it gets the point across. Things that are simple and familiar to you are new and complicated to someone else.

One of the mistakes that software designers and developers often make is to design for themselves. Something seems simple and familiar to them so they assume it will be to their users as well. One way to avoid this is to run usability tests. Bring in customers (or people who have similar background and experience to your customers) and have them use prototypes or pre-release versions of your new software. See what trips them up and ask for their feedback on what can be improved. Then revise the software and test it again until it works well. That results in happier, more productive customers and lower support costs for the product.

There is an insightful review of this book at http://www.joelonsoftware.com/items/2007/01/21.html One of the biggest reasons for failure on the project documented in the book was starting to code before designing. That's like building a house without blueprints. You wouldn't think of having the construction crew start work on a house before the architect has a chance to design it. Surprisingly, it isn't that unusual for this to happen with software, however.

It often goes something like this. You have some programmers assigned to the project and you need to give them something to do. You may have been given an end date for the project already and time is short so you want your developers to get right to work. Software is malleable so you figure you can start something and, if it isn't quite right, you will modify it later. Of course, later you may find there is no time to change what has already been done, so you ship what you have and plan to fix it next release. This is a recipe for poor quality and inefficiency.

Some people interpret Agile methods as encouraging this design on the fly approach, but that isn't true. Agile may be about making mid-course corrections, but is also emphasizes the need for up front design and planning. The development teams I work with have a release planning session at the beginning of the project where all the tasks are prioritized and scheduled into iterations.

You don't want your developers sitting around with nothing to do while requirements and design are being completed so it is important to have the requirements and high level design completed before they start their work. One way to do this is to stagger the project starting times for people with different skill sets. While developers are smashing the last bugs and getting one release of a product ready to ship, I start on the UI design for the next release.

If we do our work well, we hope never to show up in a book like "Dreaming in Code."

A complaint I have heard most everywhere I have worked is that too many meetings are unproductive. A bunch of people will get in a room and have lots of discussion, perhaps disagree on some issues, and then end the meeting with no decision being made.

I worked for a startup during the dot.com boom that had a simple technique for making meetings productive and I have tried to apply this everywhere since then. The technique was to decide at the beginning of the meeting what decision was to be made and who would make it. Whenever possible, the decision was owned by a single person. That way, someone has real skin in the game, the decision was made by the person who had the best skills and information to make it, it was not a committee decision watered down by compromise, and the decision always got made because there was only one vote. Everyone was able to provide input, but only a single individual was empowered to make the decision. We based the selection of the decision maker on the nature of the decision. If it was a marketing decision, the marketing person made it; if it was a user interface design decision, the UI designer made it, etc.

Simple and effective.

One of the debates that often comes up is the tradeoff between breadth and depth. You can either fit more features into the release or fewer features that are designed and implemented to greater depth.

An analogy may help to clarify this. In a car, most everyone needs some basic instruments such as a speedometer and a fuel gauge. Some people like to have additional instruments such as an ammeter and an oil pressure gauge. Fewer still would like even more instruments and, in the extreme, the dash on a car could be designed to look like and airplane cockpit with indicators for wind speed and such.

It is common in software development to allocate too much effort to depth. One important customer may ask for something so it gets put in and everyone gets it whether they want it or not. Someone may come up with an idea they think customers will like and throw it in, but never verify that any customer wants it. The result can be a product full of things that few, if any, people use that get in the way of common tasks. The product becomes needlessly complex and usability suffers. Once these complex functions make it into a product, they are seldom, if ever, removed. Customers will sometimes resist moving to a new version of a product because it is more complex and only adds things they do not need.

It is usually a better approach to emphasize breadth over depth. There is a rule in software development called the 80-20 rule. It says that typically 20% of what is in a product accounts for 80% of usage. It is best to start simple and add complexity only as it is specifically requested to meet customer needs. To go back to the car analogy, the first release may include basic instruments like the speedometer and fuel gauge because most everyone needs them. Later releases can add things like an ammeter provided enough customers want them. If you went straight to designing the car to have an enormous range of instruments like an airplane cockpit, you would make it too complex and it would not meet the needs of any customer very well. The time that would have gone into adding an airspeed indicator, can instead go into adding other features that customers will actually use or into improving the usability of the product instead of adding features.

Good customer service is also important in software development. We may not always be face to face with our customers, but the design decisions we make can impact the customer experience for hundreds or thousands of people. In addition to usability testing, I think it is also often helpful to put yourself in the shoes of the customer. To use the product and personally experience what works well and what doesn't. At BMC, we have started to hold internal user reviews. In these reviews, product developers and field personell, such as software consultants, perform common tasks using a new product and provide feedback before the product is released. This has proven to be a great way to catch problems and to come up with ideas for new features. It also ensures the field folks are familiar with the product and ready to help the customers as soon as the product is released.

One tipoff to bad design is when you see signs explaining how something works. If they just designed it to work the way people expect in the first place, they wouldn't need the sign. My city built a new airport recently. In the restrooms, the paper towel dispensers were built in under the mirrors in a location that wasn't visible. The architects liked the clean appearance this gave. Of course, most people couldn't find the paper towels. So the airport ended up having to place signs on the mirrors pointing to their location. Even then people were reluctant to put their hands up in a spot they couldn't see in a restroom. Eventually, after enough complaints, paper towel dispensers were placed on the wall as people are generally used to.

Sometimes bad design happens because the designers doesn't understand the users they are designing for. Other times it happens because poor tradeoffs were made. A coworker was telling a story the other day that provides an example of poor tradeoffs. The hotel he was staying at had a hair drier on the wall with a cord that was so short he could only dry the hair on one side of his head with it. He asked the manager why the cord was so short. The manager said they get complaints about that all the time. He said they initially added the hair drier based on customer requests. Then their health and safety expert pointed out that customers might be able to drop the hair drier in the sink and electrocute themselves. It would have been expensive to move the hair drier and the mirror away from the sink so the cheap solution was to shorten the cord. Of course that negated the purpose of putting the hair driers up in the first place. The customers didn't just want hair driers, they wanted ones they could actually use to dry their hair (on both sides of their head!).

As my team designs the user interfaces for BMC products, we try to avoid this "can't see the forest for the trees problem." In other words, we look up from the myriad requirements driving design and ask "what is the customer trying to accomplish with this?" We don't let the details cloud our view of the big picture.

A few years ago, I was working for a large computer manufacturer and had the assignment to test the out of box experience of a new model of PC. This was around the time that the internet was first becoming big news for the general public. The marketing folks had correctly deduced that capability to connect to the internet was going to be important to customers and they got this message across well in all the marketing materials. Even the box proclaimed "Internet Ready" in big, bold letters.

The customers who participated in the test were very excited about this. They had heard about he internet, but had never actually browsed the Web themselves and were anxious to give it a go.

The PC was packaged well and was easy to get out of the box and set up on the table. There was a big, pictorial instruction card on top that gave simple instructions on connecting up the mouse, keyboard, monitor and telephone line. The cables were nicely color coded and labeled. All the customers had their PC up and running in minutes.

They booted their new computers and soon saw the Windows desktop. This is where things started to do less smoothly. Where was the internet? The instructions didn't say. Looking at the screen, the only clue was the Internet Explorer icon. So they clicked it and got a settings dialog asking them about things like ISP, DNS and other unfathomable acronyms. The PC had trial versions of AOL, Earthlink, and other providers that would have allowed them to connect to the internet, but it was not obvious to them to try these. Every single person failed to make it past this step and came away disappointed.

If a product does not work for a customer, it matters little to them whether it gets them 90% of the way to their goal or 50%. They expect 100% and, if one company doesn't deliver that, another will.

The usability of a product is not just related to the user interface, it is the total user experience.

I gave demos of a product called BMC Dashboards for BSM. It "puts a face on BSM" providing ITIL metrics that allow executives to get an overview of IT from a service perspective. It is one of the first products we have designed with a rich web client interface. It provides the interactivity of a desktop client while being accessed through a web browser with nothing to install locally. The charts are are very compelling and they provide good summaries of data that is collected by a number of other BMC applications. I got great feedback on this from customers who came by the demo booth. There is a screenshot of the dashboard and a podcast I recorded at UserWorld at http://talk.bmc.com/podcasts/podcast-isensee 

If you have feedback about the user interface for any BMC product, I am interested in hearing it. Just click the Contact Me link on the right side of this page to send me an email.

Oracle Browser Look and Feel guidelines. Includes components and flows. http://www.oracle.com/technology/tech/blaf/index.html

Usability.gov - US Government usability guide. http://usability.gov/

Web Metrics Testbed - free web usability measurement tools from NIST. http://zing.ncsl.nist.gov/WebTools/

Research Based Web Design and Usability Guidelines. http://www.usability.gov/pdfs/guidelines.html

Usability.net - usability information from the European Union. http://www.usabilitynet.org/home.htm

SURL Usability News - usability research reports from Wichita State. http://psychology.wichita.edu/surl/usability_news.html

Good Experience - The user experience website from consulting company Creative Good. They have a free newsletter with lots of good information and interesting links. http://www.goodexperience.com/

Boxes and Arrows - UI design for the web. http://www.boxesandarrows.com/

Craig Marion's Software Design Smorgasboard - an annotated bibliography of UI design websites. http://mysite.verizon.net/resnx4g7/Design/UIDesign.html

Paulhibbitts.com - an extensive set of usability links. http://www.paulhibbitts.com/links.html

Taskz.com - User-Centered Design information from a business perspective. http://www.taskz.com/

Guidebook - a gallery of graphical user interfaces. http://www.guidebookgallery.org/index

Userfriendly.org - usability cartoons. http://ars.userfriendly.org/

BadDesigns.com - examples of what not to do. http://www.baddesigns.com

If you know of others that you think should be added to this list, please let me know.

I was certain that the product could be greatly improved by changes to the workflow and by implementing a GUI. If we did not do this, our competition likely would and our product could be noncompetitive by the time we released it. Yet this was not what the customers were asking for. What to do?

After much thought, I finally decided to design and prototype two versions of the product. One was exactly what the customers had asked for and another was a completely redesigned version with a GUI. I then took these prototypes back to the customers to get feedback.

Their reaction was emphatic. They loved the new GUI version! They had no idea what the possibilities were and couldn't have envisioned this, but, with the prototype in front of them, they immediately saw the advantages.

A lesson for me was that customers are typically not expert UI designers. When collecting requirements, it is important to tease out the true needs of the customers. Then the designer must translate these needs into a design. You have to know what questions to ask and when to take a response literaly and when it interpret it. Ask questions about needs, not about design.

The role of a UI designer is much like that of an architect in the construction industry. Customers who want a home designed supply requirements like how much money they have to spend, how large the house should be, and what style of architecture they like. The architect translates these requirements into a design and gets feedback from the customers. The architect also works with the builder to make sure the design is feasible. The architect balances all the competing requirements and creates a design that is documented by blueprints and drawings.

Customers probably did not tell Frank Lloyd Wright how to design the famous home Falling Water yet the design undoubtedly delighted them and was based on their needs.

Like an architect, the UI designer balances the needs of the customers and the constraints of the developers to come up with a design. They document this design with prototypes and specifications. If the UI designer does their job well, the outcome surprises and delights the customer.

At BMC, we have adopted a variant of Agile called Scrum for most of our projects. A podcast about this is available at http://talk.bmc.com/podcasts/podcast-gat

Usability processes always need to be optimized to fit with the development process a project uses. In this week's blog, I'll discuss some of the ways I have modified my usability techniques to fit with Scrum.

I am responsible for designing the user interface for a product called BMC Performance Manager. This development team is using Scrum with two week iterations. Every two weeks, a set of features are designed, implemented, and tested. At the beginning of each iteration, the developers are chomping at the bit to get to work on coding. They need to get the user interface design for these features within the first 2-3 days of the iteration in order to meet the schedule.

I believe that user interface design is optimally an iterative process. I like to design, get user feedback, and refine the design based on that feedback. Sometimes it is necessary to prototype multiple designs and conduct user testing to determine which approach works best. In a large product, it is important the all the features be designed to fit together into a cohesive whole.

Under our previous development process, I would work on the user interface design a few months before coding started. This provided time to do testing and refine the design. I would prototype the user interface and document it in a spec. This gave the developers a clear blueprint to work from.

With Scrum, the development is done in smaller pieces each with a short schedule. The product requirements can change during development. Features come and go based on customer input and on the progress of development. High priority features all get in, but low priority features may be added or dropped to ensure the schedule is met. Scrum emphasizes real time communication over written documents so, instead of writing specs, the development team relies on meetings and short documents on a wiki.

My challenge was to figure out how the usability process should be adapted to best fit into Scrum. I am currently working on the third release of this product developed using Scrum so have had time to refine my methods until I have a process that I think is working well.

I have found that it is important to do high level design at the beginning of the project. As soon as the requirements for the project are fairly complete, I do rough screen flows for all the critical features. This ensures the features will fit together well into the overall design. I start collecting user feedback at this point. Having a rough idea what the UI will be helps the development team to estimate the work effort and accurately plan the iterations for the release.

As the development iterations start, I refine the high level design into screenshots that show exactly what the UI will look like and describe the interaction. These screenshots become part of the documentation for each feature on the wiki. Because the high level design has given me a good idea how the feature should work, I can create the low level design very quickly. This meets the needs of the iteration schedule, but still allows me to create a design with good quality.

Some iterations are designated as hardening iterations. This is time designated for fixing bugs and making sure the code is ship quality. No new features are added in hardening iterations. This provides a good opportunity to do usability testing.

Daily interaction with the development team is essential to successful implementation of agile. The user interface designer needs to function as an integral part of the team. It doesn't work well to "throw the design over the wall" or act as a consultant.

A good article on integrating usability into an Agile development process at another company (Alias) is available at http://www.agile2005.org/XR19.pdf

There is lots more that could be said on this topic, but I just wanted to touch on a few of the key points this week. If you have questions, feel free to add a comment or shoot me an email.

A nice gallery of screenshots of major GUIs over the years is available at http://www.guidebookgallery.org/index

Few people realize how long graphical user interfaces and the desktop metaphor have been around. Many of the key concepts in today's user interfaces were shown in a demo by Doug Engelbart in 1968! Video of this demo is available at http://sloan.stanford.edu/MouseSite/1968Demo.html

Graphical user interfaces have evolved and since then, of course, but the basic ideas are from the 1960s. Thirty eight years is a long time - especially in the computer industry. So what is coming next?

Researchers around the world are working on many innovative user interface ideas. Here are a few of my favorites:

Multitouch interaction - http://mrl.nyu.edu/~jhan/ftirtouch/

Gestural interfaces - http://www.gomonkey.at/en/index2.htm

Displays integrated into your desk - http://www.asktog.com/starfire/starfireHome.html

Intelligent assistants - http://pulsar.esm.psu.edu/Faculty/Gray/graphics/movies/AppleKnowledgeNavigatorPromo.mov

Future office systems - http://www.microsoft.com/presspass/asf/CIW%202min%20Tour.wax

3D interfaces - http://www.sun.com/software/looking_glass/

BMC has several hundred products running on different platforms and for different purposes related to our mission of Business Service Management. Because of the broad range of this product line and because many of our products came into the company through acquisitions, there has historically been much diversity in our user interfaces.

We realize, however, that our our customers need products that share data, have a common look and feel, and are easy to use. We are addressing this by developing a common user interface style that is being applied across all of our products.

You may have seen the style guides that companies like Apple and Microsoft publish. They do lots of research to determine what works best then provide a set of guidelines that developers use to create user interfaces that are usable and consistent. The quality of user interfaces have improved greatly over the years because of efforts like this.

We have similarly created a set of user interface guidelines that our developers and user interface designers follow at BMC. We have taken this a step farther and created the Common User Interface Library. This is a set of components that product teams use to develop products that follow our common user interface style. This gives us better usability and development efficiency at the same time. I'll give more details on this in future blog postings.

Next week, watch for a brief history of user interfaces past, present, and future.

If there are particular topics you would like to see discussed in this blog or if you have questions or feedback, please feel free to contact me.