Archive for the ‘Usability and Design’ Category

Building a Safety Net

After our alpha test, we had a round table discussion with the involved developers, the alpha testers, and the rest of the product owner-y type people.  They talked about what they liked, disliked, general wrap-up business.  One of the greatest compliments we received was from a seasoned pathologist who has seen plenty of other lab information systems; what he said was:

One thing I love about this system is it made me feel like I couldn’t get hurt.

That is a thing to strive for.

Pathologists can really get hurt if a system is not built well.  Their patients can get hurt.  Our patients can get hurt.  We built in so many safety nets so that users do not have to worry about screwing up.  Users should be concerned with the task at hand, not with worrying about how software will react or if something is going to get messed up and affect patient care.  It was an honor that he said this to us, and I am proud of our system for making him feel completely comfortable entrusting people’s lives to our software.

Medical software aside, I think all software should make you feel like this.  You should never feel painted into a corner or like you can’t go back and change something.  Users should always feel safe and comfortable using your software, and by your team doing plenty of thinking up front, users will not have to concern themselves with it.  By building software as such, you are allowing them to focus on their workflow and tasks without having to worry about whether or not they will get hurt or hurt someone else.

Think about how they will unconsciously or consciously screw up, and make sure they can’t.  Or if they can, make sure they are damn aware of it and able to fix their error without a whole lot of extra steps.  No one should have to suffer anxiety when using software, and we all do far too often. 

This is something we can fix.

My First Alpha Test, or, The Importance of User Awareness, or, Gaining Perspective.

Two weeks ago we held an alpha test of the product we have been working on since June.  While I knew it would be an eye-opener to see people actually using the product, I didn’t know just how much of one.

I asked one of the developers, Ed Taupier, to give me some of his thoughts on how the alpha test opened his mind, changed his point of view. 

“Probably the most important outcome of the alpha testing, for me, was to gain an understanding of how the targeted clients would react and use the software we had built.  Or course I had my own opinions about which part of the software i really liked or disliked, was proud of or not.  My perspective is heavily "programmer" based though, which means the technological aspects effect my view.  This is not the perspective of the users, however.  
    It was extremely interesting to see what the testers found most interesting, valuable, useful and (yes) terrible.  Witnessing and gaining an understanding of their perspective impacted me a great deal.  It emphasized how important maintaining a "user" awareness and perspective is to a project’s ultimate success.  This has been one of the more difficult aspects of software development for me in the past.  Now i have a better understanding of how users in general, and our client base specifically,  view software.  This will greatly enhance my ability to contribute to and affect the success of projects in the future.”

Very well said. 

I’ve actually been reading that bolded quote for about 20 minutes, trying to expound upon it, but it’s perfect.  Being constantly aware of the fact that someone is going to use what you are building is important (and sometimes hard).  I mean, it’s my job to be the user, to tell developers what to make…it’s harder for developers to get in that user mindset.  When I watched Ed and another developer during the alpha test, taking in every mouse click and every question and every…everything from the testers, I could see that their perspective had really changed.  It was beautiful to watch them watch the fruits of their labor being used.  My demands for checkboxes to be in consistent locations and for filters to exhibit certain behaviors were no longer major annoyances and nitpicking; the developers could clearly see what the testers struggled with and where they had questions, and they knew exactly what needed to be done.

Since the alpha test, the quality of the code has gone up, I’ve not heard one peep of bitching about having to do something, and there is very clearly a lot more thought going into the code that is produced.

It is important to keep in mind not just what feature you are building at the moment, but how someone will be using it and how it relates to the rest of the system.  Things can get really frustrating, especially if people are being demanding, but as long as you are able to get out of a developer mindset for at least long enough to consider what is being asked for and think about your customers using the software, it should be easier to see.

I wrote a post on a similar note a while ago, and I got a lot of flack for it.  I hope this post makes my previous words seem less harsh, and more well-intentioned.

The Last Refuge of the Unimaginative Mind?

I am a creature of habit.  I like this because it keeps me efficient, which keeps me happy, which keeps my coworkers alive.

This is another situation in which I work the way I naturally live.

Consistency in Experience

When you use an app or a site, it usually only takes a few seconds or so to really get the hang of how to navigate and operate things.  If all of the navigation is on the side and suddenly a navigational element is along the bottom, doesn’t your brain kind of badgerget tangled for a minute?  Personally, it makes my face scrunch up like a little badger. 

Keeping navigational elements consistent is a real key in usability; your users will get used to how to work something fairly quickly if it’s designed well.  If you have even small inconsistencies that confuse them, they will remember that they had trouble with the product and you will get negative press and unhappy customers. 

Another key example of an easy way to be consistent in design/experience is to keep your Yes/No, OK/Cancel buttons in the same place.  Doing some acceptance testing the other day, we noticed that the Cancel button was on the right and the Accept button was on the left in one area of the app.  Everywhere else it was reversed.  This was caught pretty quickly because we kept hitting Cancel when we meant to hit Accept.  Your users will do this too; your app is so usable that they just fly through everything without paying too much attention and then….they hit a snag. 

And then they make that badger face. 

And so on and so forth. 

Keeping the minute details of your designs consistent will keep your users moving quickly through your product and minimize the amount of thought they put into their use of it, which equates to great design.

Consistency in Development

On our team, we have some things that are just standard.  Things like all grids should sort, all active checkboxes should be checked by default if a user is Adding New, case searches should be wildcarded, etc.  These are items that we already know to do, and therefore we don’t have to add a lot of noise to acceptance criteria with these little things.  Muddying up the spec will make other items of actual importance get missed, noise reduces signal, yadda yadda yadda.  These are items that we have just determined will be standard, and as we get new additions to the team we make sure that they get informed of them (even if it means forgetting and kicking a story back and then telling them).  As these conventions build up over time, we ensure that our stories always represent the essence of a feature and don’t have to waste energy or space on the scaffolding around them.

Consistency in Documentation

Just like with the Consistency in Experience section, users will get the hang of reading a manual/help file/on-screen info prompt/tooltip/etc.  I know that sounds kind of silly, but little things can really make a big difference in user experience.  If you go into extreme detail about editing a user account in one section of a manual and then only make a blurb about editing a user location in a later section, it might make a difference.  People’s eyes will search for what they want to find, and if they are used to looking for headers like How to Edit a User Account and your location editing “section” doesn’t have that? badger face like whoa.

Now for the real meat of this portion of our show: consistency in stories and tests.  Tests should be consistent in naming and consistent in organization.  People should be able to easily read through the muck to get the information they need.  Back in the day?  I could never have read tests.  Now that we’ve cleaned things up a bit I have some idea of what is going on and how things work/are organized.  I can tell what stuff is because of the items surrounding it, or by the way it is named.  It makes it much easier and faster for people to read if you are consistent in the way you structure your tests.

When I write stories, I like to lay them all out the same way.  The same things get bulleted, the bottom of the story says “Mockup attached” if that applies, things get formatted similarly.  For example, when something needs to be restricted, the first thing in the backlog item is some bolded text, before the story, that says Permissions: [Whateverthepermissionsare].  This is great because:

a) Developers will see that right away and know to build it in

b) It doesn’t muddy up the acceptance criteria and cause something else to potentially be missed

c) with this convention, if there is no explicit permission statement there, developers don’t have to guess if it needs it or not

(note: these things go for the “Mockup attached” thing too…they won’t look for an attachment if that’s not at the bottom of the story, etc)

Using ubiquitous language is extremely useful as well.  We had a doozy of a time on our most recent project trying to figure out how to separate lab accounts and client accounts in stories…eventually we came up with those terms (and a bah-zillion others), and now our developers never have to ask me what the hell I’m talking about.

Oh, and, of course, as a developer I want my stories to be consistent so that I can easily identify each element of them.  Heh.

Consistency in Code (written by Scott C. Reynolds because I don’t know enough about code but I do know that this section is important to this post)

Teams usually come up with conventions in coding, or coding standards, that define how the team will do things like organize code, name variables, and things like that. This is helpful in communicating intent and reaching collective code ownership. For instance, the team standard may be "all private members are named with a leading underscore". Then anyone in the team reading code that comes across a variable named _someVariable will know that it is a private instance member and not a local variable, and will know to be concerned with things like mutability. This cuts both ways, in that the benefit gained from following the convention is about equal to the damage caused when someone doesn’t follow the convention.

Some frameworks, such as Rails, are built on the principle of "convention over configuration". In trade for following certain conventions, you get increased productivity by leveraging things the framework can do for you automatically.

Conventions become a sort of "meta layer" of communication on a team when people are doing things the same way; whether it’s naming variables, sorting classes into certain folder structures, calling things the same thing (ubiquitous language is a convention, and bears mention somewhere I think), then it removes guesswork from the equation and focuses communication on problem solving rather than mechanical details.Some frameworks, such as Rails, are built on the principle of "convention over configuration". In trade for following certain conventions, you get increased productivity by leveraging things the framework can do for you automatically.Conventions become a sort of "meta layer" of communication on a team when people are doing things the same way; whether it’s naming variables, sorting classes into certain folder structures, calling things the same thing, then it removes guesswork from the equation and focuses communication on problem solving rather than mechanical details.

Consistency in…General

Oscar Wilde once said “Consistency is the last refuge of the unimaginative mind.”  I would partially disagree with this statement.  By being consistent with the overall structure and feel of things, you can exert your mental energy into things that really matter, rather than minutiae.  Consistency in these small things means you don’t have to think about them; they exist as quality without any extra effort and greatly enhance the usability of a product, the understandability of a story, the ease of modifying tests.

…but maybe he wasn’t talking about software, hmm?

Fighting Usability, or, Learning to See the Big Picture

There was a recent interview in the L.A. Times with Wes Anderson and some of the crew members that worked on the film The Fantastic Mr. Fox.  The article has been getting a lot of attention because the crew members in charge of making it look so stinkin’ amazing gave some pretty harsh criticism about Anderson’s demands.  Some notable quotes from the article:

“Anderson had no idea that his ignorance of stop-motion…and exacting ideas concerning the film’s look would so exasperate his crew.”

""Honestly? Yeah. He has made our lives miserable," the film’s director of animation, Mark Gustafson, said during a break in shooting.”

“Animation director Gustafson…admitted he found some of Anderson’s directive’s bewildering. "There’s lots of things I lobbied against in this movie," he said.  "He’s pushed it further than I would have been comfortable pushing it," Gustafson continued. "He definitely doesn’t have some of the reservations that I have from working with this stuff for years.”

The whole article wasn’t completely full of hate; I’ve just chosen these particular quotes to illustrate my point.  I get this kind of guff and criticism at work too.  I really don’t know much about code or what it takes to implement certain things, but I do know exactly how I want things to work, look, and feel.  I know what kinds of problems I need to plan for and I know what will be deemed unusable, difficult, or confusing by users.  During a recent discussion about how something should work, one of the developers exclaimed, “We’ve already pushed the limits of the web as far as we can, and now you want this?!” 

My response, of course, was yes. 

The whole team room was against me. 

It was a crappy week. 

However, when they got it done and demoed it for us, everyone was blown away by how great of an add it was and how much of a difference it made.  Including the people who gave me hell for making them do it in the first place.

I know I will probably receive criticism for this post, but the fact of the matter is that sometimes you have to do things that are hard or that you don’t want to do or that frustrate you in order to produce the best product (I certainly do, even though I don’t write code.  Developers aren’t the only ones feeling pressure to complete impossible tasks with ridiculous deadlines). 

Take a look at the visual feast that is The Fantastic Mr. Fox.  For as much detail as the animation has and for as beautiful as everything looks and feels, wouldn’t you agree that it was worth it?  I’m not saying don’t fight back if someone is pushing you for something that is going to break your back or break the bank in time it will take to implement, but certainly weigh the value of the functionality that’s being asked for and figure out if it’s worth it, despite how impossible or daunting it may seem. 

As you develop, try to envision the end product, the big picture, rather than getting mired in the difficulty of the bit you are currently working on.  It might help give you that burst you need to push through the hard times. 

…or just make a voodoo doll of the person making the demands.

Using the Right Medium

This post was co-written on Google Wave with my colleague Scott C. Reynolds and is a follow up to our previous post about good specification practices.

User Stories and Text

User stories and other text documents are the bread and butter of defining work, and we use them like crazy. Our story practice has evolved over time, and we have come to a place where we feel that, when used appropriately, our stories are very effective. For a deeper look at the guidelines we use to construct stories, I recommend you go check out Cat’s post on the subject.  Go ahead. I’ll wait.

Okay, welcome back. Here’s the thing, stories and tasks are only part of the equation. Stories alone aren’t enough to define a system however, and trying to define everything in text is a fool’s task. (I’ve been that fool)

Pros: tell a story, capture detailed information

Cons: text is not good for everything

Using the Right Medium: Mockups

Mockups are a very useful tool when specifying details of how things should work. With stories, you really can’t add a lot of design and implementation details or the signal to noise ratio becomes too high and shit gets overlooked. A basic rule of thumb we employ on the team is "things that don’t get communicated well in text shouldn’t be forced into a text medium." Basically, if you’re going to try to describe the way something should look in a story, a) it’s probably not going to look the way you actually picture it b) that story is now noisy as crap and people are going to ignore more important parts. With a mockup, you don’t have to take forever to do a flashy, literal, perfect screenshot in Fireworks or anything; you can just drag and drop Balsamiq controls around and voila. Ya got an aesthetically pleasing mockup that humans go nuts over. In five minutes I can mock something up in front of a developer, explain how it works, and they are ready to go.

Another great thing about mockups is that they are extremely useful for getting user feedback on specs without distracting the user that "this is the final product, no more input." You can use a mockup to discuss workflow and layout without getting mired in fine-grained detail. The last time I was at the lab, I went back to my hotel room for a couple of hours and mocked up apps for 4 workspaces, brought them back to the supervisors, and was able to get plenty of good feedback and make edits right there in front of them. Gold.

Pros: Time-saver, gives the gist of what you want, keeps your stories clean while still conveying what you want, good to show to users.

Cons: Can fall into the trap of putting everything on a mockup just like you would put everything into a story and it’s inappropriate

Using the Right Medium: High Fidelity Design

How easy is it to develop from what basically amounts to a screenshot? You know exactly how everything should look, you can strip images out, you don’t really have to think about it.

Wait a minute. There’s a red flag.

You don’t have to think about it? That’s a paddlin’. A high fidelity screenshot, while beautiful, robust, and easy to work from, gives developers a signal that this screen is a specification set in stone. They see what it needs to look like, they build it like that. It’s just like BDUF; the high level of detail and granularity means that people won’t think about what they’re actually building, they’ll just duplicate what they are given.

Pros: Hotness, high level of detail, easy to work from

Cons: Removes developer thought, can take a long time to create such a design

Using the Right Medium: Conversation and Whiteboarding

While each of these mediums has plenty of merit and many benefits, conversation and whiteboarding are my favorite methods of specifying work. There is nothing like having the team (or pertinent members) together, talking through the workflow of a feature/app, mapping out how everything works, doodling out a rough idea of what things are going to look like and how things will come together. It is so damned valuable to have the working group together, talking through how things are going to work and getting their input. While business analysts and managers can come together to specify the general nature of how things need to work, having different members of the team around will help to eke out edge cases or problems that may not have been thought of in original discussion.

Conversation is obviously important by itself too; user stories are written to leave plenty of room for conversation. If you lose communication on your team and people just go off to code in the dark, a lot of the intent and original specification is lost.

Pros: Mapping workflow, multiple sources of input, easy to sketch out an idea/easy to change an idea, whiteboarding is fun as shit, conversation fully fleshes out ideas

Cons: Easy to get lost if not captured appropriately

While we’ve clearly chosen a favorite medium, you really can’t use just one. Each medium has a lot to offer depending on the scenario you are working with, and just like any other thing, you have to use what works naturally for the team in context with what you are doing.

Usability is Design

I don’t have a snappy title for this post.  This just has to be the title, because it is exactly what I need to say.

After watching the greatest movie ever made for designers and subsequently having some great conversation with David Laribee this past weekend, David made a statement that has been stuck in my head all week:

“Usability is design.”

 

I fully agree with this statement.  Having read The Designer’s Bible to help me with the web design I’ve been doing the past two months, I’ve been looking at everything with a much more critical eye.  And everything I notice is a usability issue.  Yes, flashy touches are nice, but…are you sure? 

In our most recent project, the devs made this thing happen so that when you add a specimen to an order, the background of the related box softly flashes this very subtle green, just for a second.  It is so slick and so hot, and it is the perfect visual indicator that the action you took was accepted by the system.  It’s not just something flashy and there to look fancy; it is useful.  That’s what I like; I could care less for Web 2.0-lookin’ jazz and noisy, crowded interfaces, give me something useful.

Think about some sites you maybe frequent: Google and Netflix.  What the hell does Google have, design-wise (besides an awesome logo on special occasions )?  Nada.  It’s white.  It’s got a searchbox and some links at the top.  It’s boring.  However, I can get anywhere I need within Google with those Plain Jane links.  I love being able to look at images from the context of my search; I love being able to get to my mail from there so I can paste a link in and send it off.  It’s easy.  It’s usable.  What else could they possibly need?  It is one instance where All the White Space in the World doesn’t kill me.  Because they don’t need anything else.

And Netflix…God, could there be a better website?!  I have never needed to navigate away from where I am in order to do something I want to do.  I can always get to whatever I need from the context of the page I am on.  It’s so damned usable.  Have you ever had to look up how to find/do something on Netflix?  Dubious.  The design of the page just falls into place based on the usability. 

And that’s how you should design.

Don’t design with flashy hotness in mind.  Design with usability in mind.  Usability should always be your primary focus.  If you are a designer you probably know how to make things pretty and know what people want to see.  So that stuff will fall into place, eh?

Usability is design.  Don’t let things get noticed.  Don’t make people look for how to do something in your software.  Make it intuitive; let the hotness lay naturally on top of the usability.

I could make this a longer post, but sommmmeeeebody always complains about my long posts, so I’ll just leave you with The Least Usable Popular Website Ever:

[www.adultswim.com]

Poke around it.  Let your hate grow.  Build yer shit better than this.  Go go go!