Designing RIAs...the Right Way

Anyone who knows me will tell you that I frequently preach that the only way to successfully design an application that is easy to use and meets user goals is to take a step back and think about it as a whole. I often get pushback with the usual "That sounds like waterfall to me" argument. Like I have said before, it doesn't matter what it is called to me as long as it works.

So the folks at Forrester set out to investigate how to create successful RIAs. The report focuses mostly on Cynergy who is one of the big guys in the field of RIA development (so they know what they are doing). I have to say that I am not surprised by the findings or by the way Cynergy designs and builds applications. To me it seems like common sense. But I am glad that this "official" report calls some attention to it.

You can buy the report from Forrester or get a free PDF of it from Cynergy.

User Experience Designers...Listen up!

A couple days ago I posted a question here (and on some other discussion lists) regarding how usability can fit into the Agile process. I revised it slightly and added some clarification:

What are the best methods you’ve experienced with regard to incorporating quality design & usability practices into Agile software development?

There is some debate in the software industry regarding the scope of UI design work to be completed before Agile software development can begin. What are your thoughts? When is a detailed prototype necessary? When is it not necessary?

I promised to post my thoughts so here they are.

The method that I am currently using involves some upfront design time which I consider the architecture phase. During this phase is when you gather and process all the data about various types of end users and their goals. Throughout the architecture phase, we work on low-fi wireframes and/or mockups that address high level global interaction patterns such as type of navigation, inline editing vs. popups vs. separate edit screens, etc. I liken this to the engineers' decisions to use a particular technology, library or persistence strategy. Some of this stuff needs to be thought out early since changes later are expensive and destabilizing. Because, end user satisfaction is a top priority for our customers, I propose doing usability testing during this phase (and all through development). 

While wire-frames and paper prototypes can certainly be tested, we have found that nothing works as well as a clickable prototype. Someone suggested above that just build the real thing and test that. We have repeatedly seen that a very detailed prototype can be built in 4 to 6 weeks where the actual product can take 6 -12 months. Of course with agile development you have something every 2 - 3 weeks but it does take a while to get to something that can be a true test of the user experience. The level of detail in the prototype and wireframes/mockups is really determined by the complexity of the interaction. If one pattern can be reused, there is no reason to prototype every use case of it.

This process can work very well but requires some commitment of time before development begins. This doesn't have to be a year long effort but depending on the type of application somewhere between weeks and months seems appropriate. Regardless of the amount of time required, this is often labeled "Anti-Agile or Waterfall". 

What lead me to asking my original question was my desire to know how others are doing it from a tactical perspective. Can the process I describe above scale? Is it truly anti-Agile? If it is, does that really matter if the result meets user's needs better? 

If the goal is to deliver really good software, not just really good code, I am ok with being slightly less Agile.

Do prototypes help or hinder the Interaction Design process

Almost ten years ago, Alan Cooper (author of About Face and The Inmates Are Running the Asylum and my personal hero) of Cooper wrote a journal article titled "The Perils of Prototyping". It made me think about today's software and the way in which we designers communicate our vision to developers. I posted a comment on that blog asking this question:

"Do the capabilities of today's tools and the expectations of today's users change the need for prototyping?"

The reason I ask is because it isn't as easy to test interaction design patterns on paper if they require visual transitions, sounds, tactile responsiveness (on touch screens), vibration (think Nintendo Wii).

I have seen numerous times that communicating complex interactions to developers with paper mockups, or even digital mockups, is far more difficult than showing a prototype that actually does what is required. 

I have also heard first hand from developers that say a prototype really helped them with the details. Not only does it display how the software should behave, it provides and idea of how it might be implemented. This might be unique to the fact that the prototype built with Flex was for an application that was also built in Flex. So there was the ability for direct reuse of custom components, etc.

What do you think. Is there value? Can it work in an Agile environment? Or is it still as unnecessary as it was ten years ago? 

User Experience Designers... speak up!

A colleague posed a question to me today that I think is a very important question:

What are the best methods you’ve experienced with regard to incorporating quality usability practices into Agile software development?

Before posting my answer, I am interested to hear what all of you think.

As usual, I mostly agree with Jakob Nielson

If you work in the web world, it is pretty likely that you know who Jakob Nielson is. If not you can read about his work and thoughts here. 

He recently posted an article talking about Agile Development and Usability which, like I said, I mostly agree with. Really the only part I cringed at was where he says:

"It's perfectly feasible for developers to do interaction design and usability."

Now, I have no problem with developers being involved with usability testing. I think it is extremely valuable to for them to see first hand how users act. The part that bothers me is that it is next to impossible for developers to have an unbiased opinion when analyzing the results of user testing. In my experience, it is because developers know the ins and outs of the system too well to appreciate the way users perceive the system. A designer on the other hand is in a better position to be looking at the system the way an actual user would.

Like I said, I mostly agree. His suggestion for usability and design to happen in a parallel track is one that I have advocated for a long time and has been very successful for me. His suggestion that Foundational User Research should occur before a development project even exists is spot on. This work and much of the work done by interaction and experience designers is just as much a part of the product strategy process as it is the development/ implementation process. So, part of it must be done during the strategy phase long before developers start writing code.

Experience Designer/Interaction Designer Wanted in Massachusetts

In my previous post I mentioned that I was looking for an Interaction Designer/Experience Designer.  I forgot to specify that the job was in Marlboorough, Massachusetts.

You can see the official job posting here. If you have questions email me at rob[dot]mckeown[a]workscape.com

Experience Designer/Interaction Designer Wanted!

I am looking for a top notch Experience Designer/Interaction Designer to work with me full-time at Workscape designing their next generation of Talent Management and Outsourced Benefits Administration applications.

If you have experience designing web-based enterprise applications this could be for you. In this role, you would work with Product Management, Engineering and myself to create applications that enable employees to accomplish of a variety of goals from benefits enrollment to performance evaluations. We have a major focus on building highly usable software making this a high profile position within the company.

The key requirements are:

• Proven track record designing enterprise applications
  
• Experience participating in usability studies
  
• The ability to quickly create wireframes and mockups
  
• Design skills that will "Wow" while adding real value to users
• Experience working in an Agile environment

If you have Flex skills then that is even better. Being able to quickly convert mockups to working prototypes is a major plus.

You can see the official job posting here. If you have questions email me at rob[dot]mckeown[a]workscape.com

Usability testing on a budget... but only on a Mac

If are designing software you no doubt realize the importance of usability testing your wireframes, mockups and prototypes. However, most people hear "usability testing" and automatically assume that means a giant effort at a giant cost. Well the geniuses over at Clearleft have a solution called Silverback. The real power is in its simplicity. It allows you to put a user in front of a screen and point and click their way through whatever you put on the screen while it records screen changes, mouse clicks and video of the user.

All that and its only 49.99.

It really begs the question, "Why didn't something like this already exist?"

Unfortunately, for those Windows users, it only runs on the Mac. If you know of something similar for Windows users, feel free to comment.

Why is UX hard to sell?

In any other type of product, if it is hard to use, people will look for something better. Whether it is a car, dishwasher, lawnmower or anything else, you would not put up with struggling to figure out how to use it when you can buy something else that is simpler and allows you to get to work, wash your dishes or mow your lawn more effectively.

In light of those facts, you would expect that anyone building a product, whether a physical product or a piece of software, would place ease-of-use at the top of the priority list. However, in may cases that isn't true.

It goes back to the early history of computers when the people using them were the people that created them and they understood and appreciated how difficult they were to program to do anything. So when presented with something complicated, they thought "wow... this must have been really complicated to develop". They were ok with that. But now, computers and software are "magic" to the majority of people. They don't care how complicated they are to develop and don't appreciate the effort (and they are right not to). But people creating software sometimes think that users will understand how difficult a feature is and cut them some slack if the interface isn't as good as it could be. It just isn't true anymore.

I, and other designers I'm sure, would be interested to here success stories from those designers who have overcome the "lets just make it work... we'll make it easier to use later if we have time" mentality. Feel free to comment.

Adaptive Path and Mozilla's Aurora - Part 2

Aurora (Part 2) from Adaptive Path on Vimeo.

The second part of the video shows two people using a mobile device to access a similar interface to the desktop version shown in the previous video. What is interesting is that the mobile device is not also a phone, camera, mp3 player and food processor as would expect in "the future".

Adaptive Path and Mozilla's Aurora

Aurora (Part 1) from Adaptive Path on Vimeo.

It seems that some people like this interface while others have had mixed feelings about it. But let me put my two cents in.

When I look at these types of videos I typically stand back on try to imagine a world in which I use that tool. In most cases, like with Aurora and the multi-touch coffe table, I wind up thinking that I would never use that. However, one thing to keep in mind is that the purpose of these futuristic visionary interfaces is not to predict exactly what the future will hold. The real purpose to to explore the possibilities much like a concept car from an auto manufacturer. In most cases the total package never gets rolled out but certain aspects of them get rolled into more realistic versions of cars.

So while I think some of it is interesting from an interaction design aspect, other parts seem like a solution looking for a problem to solve... but thats ok and I commend Adaptive Path for going well outside the box.

Here's something you should think about but probably don't

How many of you have websites? Quite a few I bet. Now, how many have designed your own website? Not quite as many but a lot. Now, how many of you have actually designed a 404 error page? Not as many...what happened? Unfortunately as designers we spend a lot of time thinking about what the UI should be under normal circumstances. This is also why things like form validation and error messages are usually an afterthought.

The 404 error page is one of those things that you assume people on see when they make a mistake and enter an nonexistent page url. This is probably true in many cases, but it could also be because you made a change to a page on your site and inadvertently broke a link (that never happens does it?) Regardless of why people wind up on the error page they end up in the same situation since they were expecting the content they requested and didn't. So, why not take the opportunity to help the visitor find what they were actually looking for. Robert Hoekman, Jr. talks about this in his book Designing the Obvious (which is great by the way). Take a look on page 1154 and you will see a discussion about it.

For some ideas on how you can create a better error page, also check out http://patterntap.com/tap/collection/404-pages

And before anyone comments and asks if my sites http://www.mcgraphix.com and http://klok.mcgraphix.com have custom error pages, let me admit that they don't. Hey... I'n not perfect you know. But, I will be rectifying that immediately.

Bullet Graph - Free Flex Component

I was recently reading Stephen Few's book entitled "Information Dashboard Design" and was exposed to many examples of the "bullet graph". While most of the examples show them being used to show sales type targets, it got me to thinking that they may be a good way to show actual time spent vs. the estimated time for a project in Klok. I found that there was no out-of-the-box component that met the specs that Mr. Few describes. So, I decided to put one together for myself. Here is a screenshot.


Granted, this could probably be made more configurable, but this is just the first crack at it. So, right now, you can set the label, target, actual value and give the ranges that would indicate "bad", "satisfactory" or "good". You can also specify how many tick marks should be shown on the quantitative scale.

Feel free to check it out here (view source is enabled) or download the zip here.

I highly recommend Stephen's book for anyone who is creating any application that needs to display complex data. You don't have to be building a traditional "Dashboard" put his suggestions to good use.

MXNA is down. What do I do?

That title isn't meant to be rhetorical. I really don't know where to go for my daily news. I guess I didn't realize how much I rely on it. It is a good reminder of how what we think and what is true are not always the same. If you asked me, I probably would have said that I use it sometimes but it isn't essential to my daily life. The reality is that it truly is essential.

I have to pack some kind of User Experience lesson in here, so here goes. Don't trust what user's tell you. They become so unaware of the things that use all the time that they take them for granted. Anyone who looked over my should on any given day, they would probably notice that every time I am doing a build (which takes a couple of minutes), I switch over to my browser window which always has the first tab open to http://thoughtfaqtory.com/flex/mxnaviewer/.

So keep that in mind when you want to find out how users actually use the software you build. Just remember to ignore what they tell you and pay attention to what they show you.

Worst UI Ever - Progressive Disclosure

So here is a little example of what not to do. Before I go any further, let just say that Progressive Disclosure itself is not bad. In fact it is a very useful tool in many situations where you need so show more options as a result of some previous option being selected. It is just this use of it that doesn't work.

I am in the market for a minivan so I head over to the Toyota site to see what it would cost for the one I am looking for. The site is looks very nice, however I ran into this little problem. The dropdown shown below has a clearly labeled link called "Build Your Sienna" as shown below.


When clicking it, the problem is obvious


I actually had expected to be taken to the "Build Your Sienna" screen rather than have this mysterious little form pop up. In fact, for a second or two I didn't even notice it. When I did notice it, I wasn't sure what I was supposed to do. So I just clicked "Build Your Sienna" again. While my mouse button was held down, the words "Zip code" were displayed in the form field. When I released the button, it went away again.

Since I didn't think my zip code was relevant, I just clicked on "Go" and was met with this:


Apparently, a zip code is required in order for me to build my vehicle.

First of all, the if the zip code field was going to be there it should be labeled initially. This could just be a bug due to me using Firefox. Perhaps the site wasn't tested enough.

In my opinion though, if a zip code is a required part of building my vehicle then it should be part of the vehicle building process rather than this unlabeled popup. The reason for the zip code is probably due to changing costs based on geographical location. They may not want to say that on the site, but they could have said something like "Your zip code is used to find dealers near you that might have the vehicle you build in stock" This would do two things, give the user a reason why the zip code is needed and also benefit the customer since there is a good chance that a potential buyer might want to actually go test drive the vehicle at a local dealership.

While it might seem cool to add the little form using Progressive Disclosure, this is not an appropriate place for it. "How" we put stuff on screen is only part of the equation. The "Why" and "What" are usually far more important.

Moonwalking bears and RIAs - The effects of change blindness

Change blindness is a phenomenon where humans fail to see major changes within the visual field regardless of how significant the change is. For a fun example of this effect, take a look at this. Or check out Wikipedia's page on the subject.

If you are wondering what this has to do with RIAs, lets think back to the web 1.0 days. In most applications the only way to see changes in data was to refresh the entire screen which resulted in a brief loss of focus followed by an attempt to regain focus once the page was refreshed. Usually the new page was different enough to make you briefly rescan the entire screen.

Now fast forward a few years and we are in Web 2.0 land with all the RIA goodness thanks to AJAX, Flex, Flash, etc. With these new technologies has come the ability to refresh only the data of the screen which, on one hand, is much better since you don't have to reacquaint yourself with the screen after every change. However, on the other hand, without page refreshes it may become difficult for users to actually notice that a particular portion of the screen has changed. For example, if I add an item to my shopping cart, I could miss the fact that my total or estimated delivery date has changed.

Keep in mind that if it is important that the user notices a change, then we must make it obvious (with a non-modal) notification.

To save or not to save

Every time I write something on this blog I am reminded that some software is so transparent that I don't even need to think about it. Take Blogger for example. As I type this text, I often stop typing for a few seconds at a time to think... like just then...When I become idle for a bit Blogger notices and takes that time to automatically save my work.

It tells me when it last did it so I can be sure that if something went wrong and I lost my internet connection or my machine crashed, all but the last few words would be safe. If I click SAVE NOW, I get this so I can differentiate when I saved vs. an auto-save.


Notice that the text saying when it was saved is not modal, so I can happily ignore it if I want. This is much better than an Alert saying the same thing since you can't ignore an Alert.

Usually the argument against this goes like this "We can't decide when the user should save" or "What if the user doesn't want to save?" In actuality, it is safe to assume that the user always wants to save. After all, how often do you spend a bunch of time writing something and then not want to save it? You may infrequently, discard changes but that certainly happens much less often. Since it happens so infrequently, Blogger has no way to not save. This was no doubt a concious decision based on knowledge of real users' goals.

Now, some applications may need the ability to not save. But, that doesn't mean that you can't have auto-save. One solution would be to store the last manually saved data in a secondary location until the next manual save. Then if you wanted to revert to your last save after auto-saves have occured, you could simply retrieve it from that secondary location. If revert is never needed, then you could just throw that data away when the session ends.

I can already hear the arguments now. "That would be very difficult to implement", "We should spend our time on REAL features", "How would referential integrity be maintained?", etc.

In some applications this not trivial. But, as usual, the arguments against rarely mention Jane Smith, the professional writer. Remember, software is meant for humans to use to solve their problems. We can't leave them out of the equation.

What's your title?

I am frequently asked what I do for a living and have found that when I reply with my title, "Principal User Interface Engineer", most people ask "yeah... but what do you do?". So let me ask all of you a question.

If you are someone who is responsible for designing what software behaves and looks like, then what is your title? Just curious if there is a succinct way to sum it up.

Worst UI Ever? Error Messages Part 2

I can't take credit for finding this one but it is a great example of how not to treat the user. I won't bother to repeat all my thoughts here but you can read them in the comments of the original blog.

However, I will take a moment to summarize what should be a global philosophy for anyone creating software. Here it is:

"Software is a tool to be used by humans to accomplish something. It is NOT a tool used by computers to accomplish something."

When you step back and think about it, it seems obvious. I buy and use software because I need to accomplish something (editing photos, paying bills, communicating with friends) in a way that is easier than the way I used to do it. The last thing I want is to feel like I am driven by what the software wants from me.

If a person said, "write your phone number down for me" and I wrote 555.555.5555, (555) 5555555 or 555 555-5555 then they would have no problem understanding that. If they said to me that when they think of phone numbers, they think of the format (555) 555-5555 and then asked me to write it in that format I would laugh and not expect to actually have to do it. I don't think it is asking too much of the software developer to implement that kind of logic. Some human-like logic is hard to implement obviously but some isn't. An when it is done, it can have a huge impact on the opinion a user will have of your software.

Who is "The User"?

In the software development world, it is common to hear developer, designers, product owners, etc. all talk about "The User". Most of the time however, we don't think much about who Mr./Ms. User actually is. This inevitably leads to a problem.

The problem is that if you don't know anything about who you are designing software for, you are very likely going to create software that either is geared toward use by the developers or product owners themselves or is based on some union of all traits of any possible user. Since most software companies are not building software development tools there is an obvious problem with the former. And, unless you are building very specialized software for a narrow population of user, you can't really combine the traits of a super power user and occasional perpetual novice user into one ideal person which makes the latter a problem.

Why shouldn't the developer build what she would want?
The answer is simple. Developers are a different breed of person. Take no offense if you are one. I am one too. Developers enjoy having an understanding of the inner workings of software and can appreciate the technical difficulty of it. Plus, they understand every aspect of the software they are building. All of that makes it hard to see the software from the point of view of a non-technical person, who has no interest in how software works and doesn't care how difficult something is to implement.

Why can't one UI serve all the traits of all possible users?
If you think about most things in the physical world, there is little that is "one size fits all". In fact, things that used to be called "one size fits all" now say "one size fits most". The reason is obvious. One size can never fit all. This doesn't just pertain to size...

Imagine you were in the shoe manufacturing business and you created a line of sneakers. So far so good. If someone decided that you should make shoes that would be good in the winter while shoveling snow, you would not likely try to adapt the sneaker design for this purpose. Even if you could make that work you will ultimately wind up in the situation where as you need to create dress shoes, sandals, water shoes, etc. they can't be combined into one shoe. The only way this can work is to understand the needs of "The User" better.

In our shoe manufacturer example the better solution would be to think of the different types of shoes as meeting the needs of particular consumers. As you go through the process of defining the different types of shoes needed, you will probably see opportunities to combine types. A sneaker and a hiking boot could be combined. But a hiking boot and a sandal probably can't.

When designing software we need to do the same thing. Certain functionality is meant to meet specific user goals. Those goals can usually be categorized into buckets such as Employee or Manager, Student or Teacher, Player, Coach and Scout. Once you categorize the functionality, you can start to make decisions about how the UI can support those types of user.

As UCD practioners will notice this is a step toward defining Personas. While Personas are very powerful mechanisms for understanding specific users, I have found that Agile teams are very reluctant to spend the appropriate amount of time defining them. If you have the time, by all means, go for it. If you don't, and can't get the time somehow, at least try to make a quick pass at it at the beginning of the process. Finding out during the middle of development that the software is going to be used for global reporting by executives as well as the individual employees for data entry would be very costly .

The Bottom Line
While you don't need to go survey hundreds of real users, it is very valuable to at least think about who those users are. Every user will be happier with the result.