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.

Some Good Specification Practices, or, I Am Out of Clever Titles

This post was co-written on Google Wave with my colleague Scott C. Reynolds, who makes me insane every day.  It is part of his How We Do Things series.

Where We Came From

We began our large LIS project in late 2004, starting with about 6 full months of writing specifications and designing the database. We created reams of documentation for each application complete with use cases that we knew we wouldn’t even implement until after the first version was released (sidebar: some of those still haven’t been done). We defined more than 100 tables of heavily normalized database schema. Before one line of code was written, we had spent six months of project budget.

As development continued on the project we found ourselves diverging from the specifications that had been created. The documents became little more than a roadmap, with the bold headers on functional groups and the basic usage stories becoming the guidelines that we followed. Much of the detailed specification and database schema went out the window as the system took shape and people began to see and give feedback on what was being produced. Too much specification gave us a false sense of "doing it right" and led us down many wrong paths. Balancing rework with completing planned features became a costly chore.

By the time the project was complete, it was clear that much of that up-front work had been wasted time and money. Had we top-lined the major milestones of such a large project, detailed a small set of functionality, and started developing iteratively, the system would have taken form much sooner, allowing for a tighter feedback loop and much less overall waste.

How We Do It Now

Lessons learned, we set about improving how we do specification. Scott already talked a little about this in the posts on planning, so please review those if you haven’t seen them yet (here and here).

When planning a new project of any size, we take an iterative approach. We start at a very high level, and strive to understand the goals of the project. What need does it serve? Who will be using it? Are we competing with something else for market share? Is there a strategic timeline? What’s the corporate vision here? What are the bullet points? We will fill in details later. We only want broad targets to guide us further.

When we get closer to development, we start to identify smaller chunks of functionality within each of those broad areas. This is still pretty high level, but done by business analysts and management on the IT team. We start to identify MMFs (minimal marketable features) and group them up in order of importance to help determine next steps.

MMFs in hand, we take the first one and start defining it further. This is where the information from the planning post comes in. We start to write stories (Cat has a great post detailing how to build effective stories). The other information gathered to this point sits dormant, with as little specification work done as possible, until such time as we are getting closer to working on it.

Over time, and only as needed, we put more and more specification on the system, and this is done in parallel with development. In fact, often the most specific information can only surface during development of those features, as they take shape, and as we understand how users will react. Specification should be every bit as iterative as coding.

Reduced to its essence, we JIT specification at many levels to allow maximum flexibility to change direction with minimal wasted work.

Gemba As an Essential Part of Specification

Lean has a concept of the gemba attitude and genchi genbutsu; essentially, being in the place where the action happens. Developers and business analysts have to work with the domain experts, in the place where the work happens, and observe the true workflows in place before hoping to design a system to support them. You cannot get this information from sit down meetings and emails with domain experts. You must go and see for yourself, or you will miss things.

It’s often the case that a team relies on "domain experts" to provide them with the specifications they need to build software. This is the BDUF way – gather in committee and have the all-knowing user tell you what to build. Fail.

My Experience With Gemba

Our dev team works out of the corporate office in Florida, while the actual laboratory is located in upstate New York. As a result, it is often an exercise of the imagination to figure out the best way to create things for them. Before I visited the lab, I relied on information from others, emails back and forth to the lab crews working all weird hours of the night, and my knowledge of the applications currently in existence. I really only ever got half the picture, and it was difficult to ensure that the things I was specifying would fit into the lab users workflow well without actually knowing what was going on up there. When I visited the lab my whole world was changed. Actually seeing how users interacted with the software and seeing ways they would work around what we didn’t have (open Excel or Word documents on their desktop, a wall covered in post-it notes). Just from walking around talking to people for 2 days, I probably got 50 requests. And they never would have asked for them; they would have just kept suffering. Being there showed me everything about how they worked and a million ways I could improve their lives. The experience was invaluable to both me and them, and each subsequent trip has just improved my knowledge of the way we work and the way they interact with our software.

                                                                                                            ~Cat

There is no substitute for a certain amount of domain expertise being resident in the team room. Your domain experts are experts only in their domain. They may know the workings of a histology laboratory inside and out, but if you ask them to design a system to support that lab, they’ll come back with something that looks an awful lot like excel and post-it notes.

 

postitwall

Yes, this is real.  Yes, I died a little inside.

In the next post we will talk specifically about the tools and techniques we use to specify work, and how we combine them to form complete pictures of a system (spoiler alert: it ain’t just stories).

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!

Tips to Giving a Better Demo, or, So You Think You Can Demo?

I have anxiety.  I am a terribly anxious person.  Giving demos?  Yeah, totally not my favorite thing.  Giving demos, to me, is always walking a fine line…if you hover in one place for too long or ramble on about something, they’ll eat you alive.  If you move too quickly through something, they come after you with torches.  Ok, maybe I’m exaggerating, maybe I work for Vikings….whatever.  Point is, I’d like to give a couple of common sense tips for giving a demo that will (hopefully) help you get through things smoothly and hopefully not have a 30 minute panic attack and talkinonebreathlikethiscausethisishowitalkwheni’mnervous.

We do a demo every Wednesday of our current Monstrously Huge Project that we are working on, so I’ve been seein a lot of demos lately.  A crapton.  A metric crapton.  So a lot of these tips are things I’ve noticed while giving an internal demo to the team and product owners.  However, I hope you can use these tips for other types of demos as well.

An effective demo will give your users/team/managers confidence in the product and make sure that everyone sees it right.  In no particular order…

1. Focus

What I really mean by this (vague) point is don’t just stare at your screen.  Sometimes it’s easy to fixate on something that’s maybe not done yet and you want to think about some more, but people are waiting for you.  Don’t get lost in your own head; be mindful of your audience.  They are the ones paying for the big show, the ones learning from you, the ones working to improve it….whoever your audience is you are giving the demo for them so make sure that you are, in fact, giving the demo for them.

2. Pay attention to your audience

Pay attention to what people in your audience are saying, what questions they are asking, little noises they make in response to a flashy thing in your software.  People will make it apparent what things they want to see and what things they like.  Try to stay in the area where their attention is for the right amount of time; sitting in one spot for too long is a waste of time and will just frustrate them (cannibalism), moving through too quickly won’t give them a good feel of the product (torches).  Try to keep the demo moving at all times but don’t scroll to the bottom of the screen if someone is commenting on something at the top.  Just (again) be mindful of your audience.

3. Employ the same workflow that the software will use

One problem I see a lot in demos is people jumping all around, showing off little things here and there, showing off big parts that they are proud of, skipping things they’re used to seeing.  This…is a fail.  When demoing a product it is key to show how users will be using it.  Having a disjointed view of a product is not going to instill a lot of confidence and is not going to make someone want to use it.  If you are all over the place and they can’t figure out how to complete one workflow because they can’t follow your software, you’ve made your software look unusable and now they don’t love it as much as they probably should.  Showing off exactly how easy it is and exactly how they can use it for their needs is…well, whatever, it’s a win.  That’s the way to do it; get on the trolley.

4. Cardinal Sin: Do Not Show Code

I didn’t even think this was a thing, except that I see it all the time.  If you are giving a demo, DO NOT JUMP BACK AND FORTH TO RUBYMINE.  Or Visual Studio.  Or Expression Blend.  Or whatever the crap you use.  Customers DO NOT want to see the code.  A demo is a demonstration of a product or a partial product or whatever the crap it is.  Don’t show code!  Why would you do that?!  I don’t even have anything more to say here, THAT is common SENSE!  /end rant

5. Do a dry run

When I do a demo I always, always run through the product as I intend to show it.  This way I can make sure all my test data is safe (no I.P. Freeley’s, etc), make sure everything that is supposed to work works, make sure I know the areas to stay away from if the software is not complete…a dry run is just a great way to verify your product before showing it off.  Maybe not if you have a 5-year-old product that you’ve been demoing for years and are a fuckin pro at, but if that’s the case you probably shouldn’t be reading a novice’s blog. For most products (newer products) a dry run is a great way to a) make sure all that shit I said before and b) get a good feel for exactly what you’re about to do.  There is a stupidly curvy road near my house and I almost wiped out the first few times I drove it (note: I am a woman.  Be not surprised).  Now that I drive it almost every day I can practically do it blindfolded (dear God I would never, ever drive that road blindfolded).  Point is, it’s easier to do things you’ve already done.  Amirite?  Do it.

6. Set expectations

If your product is 50% done, tell your audience.  If something you are currently showing off is in progress, tell your audience.  Make sure they know what to look for and what to accept as incomplete or they’ll heckle you for all sorts of bugs that are not bugs at all.  By telling them which section of an app is in progress they will remain relaxed when something blows up rather than jumping up and down snarling and shaking spears (sorry, my company is a little more serious about software than yours, hmm?  VIKINGS!)

7. Good clean test data

I guess I addressed this a little earlier, but make sure you have good test data in something you are demoing.  What I mean is:

a) Make sure it’s stuff that works.  I’ve clicked on a patient name during a demo that a developer had wiped from the database but for whatever reason the name was still available in the grid.  Let me tell you how happy people are to see RUNTIME ERROR in the middle of a product demo.  Love it.

b) Make it family-friendly.  Ish.  Yay, being on your team is like working in a boys locker room, fun times!  When your CEO walks in and sits down to see what you’ve got? you had better not have Harry Balls and Seymour Butts as sample data.  Yes, I know they are hilarious but they are also fantastically annoying if people have to pull screenshots or show it to someone outside of the team.

c) Make sure there is enough.  A lot of times I’ll see a grid full of data on one screen and then when the person giving the demo navigates to the next screen a grid is empty.  Or has one item, which they take an action on that makes it disappear from the grid.  Oh, want to see it again?  Let me go into the code and add it.  ERRMP (I don’t know how to make a buzzer sound), wrong!  Make sure you have a few real-looking things in each section that you are going to show so you can show your audience til the cows come home (i.e. roughly the amount of times you think they might need to see it to get it, and maybe a couple extra for show).

Thanks to @laribee for accidentally giving me the secondary title, thanks to @edtaupier for giving me inspiration (you are awesome, please don’t doubt it), and thanks to @scottcreynolds for the martinis that fueled this post.

Agile, Agile, Agile, It’s the Way to Be

Note: This is in response to @scottdensmore’s request for software-themed Schoolhouse Rock.  I didn’t really know where else to post it, plus I can whore traffic this way.  Try to sing along in your head.

Agile, Agile, Agile, It’s the Way to Be

Design, code, test, deploy
You think this is the way to work?  Oh boy!

Have I got a thing to show you
It’s called agile, it’s the best!
Plenty of communication
Makes it better than the rest!
You think you’ve got a great thing going
With waterfall
But how much room for change do you have?
None at all!
With agile you build in
Plenty of room for change
*some other character pops head in* “Why build it any other way?  I find it rah-ther strange!”
Big design up front
Long requirements docs
Annoying when your BA is a ****
And your POs are all coooocks! *piano trill*

Can’t get answers when you need ‘em
Spec docs have no sense of totality
How will you ever satisfy
Your zero-defect mentality??
Weeellll, you’ve gotta go with agile
Make user stories follow INVEST
Back it up with good criteria
And your product will be the best!
Working software is
The primary measure of success
Use the agile way and you’ll get there
With much less streeeesssss!
Be a craftsman not a drone
Take some pride in your code
Leave your codebase clean for the next guy,
Don’t be a total chode!
Iterative development,
Continuous delivery
All these reasons add up to:
It’s the methodology for me!
*song slows, piano playing*
With a kaizen attitude
You can get there too duuuude….
*music resumes and full chorus*
Just work well with all the members on your team!
*piano closes out song*

Design, code, test, deploy

You think this is the way to work?  Oh boy!

Have I got a thing to show you

It’s called agile, it’s the best!

Plenty of communication

Makes it better than the rest!

You think you’ve got a great thing going

With waterfall

But how much room for change do you have?

None at all!

With agile you build in

Plenty of room for change

*some other character pops head in* “Why build it any other way?  I find it rah-ther strange!”

Big design up front

Long requirements docs

Annoying when your BA is a ****

And your POs are all coooocks! *piano trill*

Can’t get answers when you need ‘em

Spec docs have no sense of totality

How will you ever satisfy

Your zero-defect mentality??

Weeellll, you’ve gotta go with agile

Make user stories follow INVEST

Back it up with good criteria

And your product will be the best!

Working software is

The primary measure of success

Use the agile way and you’ll get there

With much less stresss!

Be a craftsman not a drone

Take some pride in your code

Leave your codebase clean for the next guy,

Don’t be a total chode

Iterative development,

Continuous delivery

All these reasons add up to:

It’s the methodology for me!

*song slows, piano playing*

With a kaizen attitude

You can get there too duuuude….

*music resumes and full chorus*

Just work well with all the members on your team!

*piano closes out song*

Like the Back of My Hand: Doing What You Know…Everywhere, or, Life Imitates Software

A while ago I wanted to start up an Etsy shop.  I had no idea what to do, as I am quite crafty but equally unfocused.  People told me “just do what you know.”  So I started making Beatles shot glasses and pint glasses (in case you don’t know me, I am disturbingly into The Beatles.  Thanks to all of you who do know me for putting up with it).  They sold pretty well and I had a great time making them.  It was easy.

When I wanted to start blogging, I had no idea what to write about.  People told me “just write what you know.”  Had to think about that one for a while before the first few blogs came out.  But the next ones were easy; usability issues are everywhere and even jokes made me think about software process issues.  All I had to do was look around and observe things and the answers were in front of me, because I knew them.  It was easy.

The point I’m getting at here is that these things were easy once I realized all I had to do was what I knew, and what I do on a daily basis.

The real point I’m getting at here is that this is obvious.  Doing what you know is easy.  Doing what you do on a daily basis is easy.  What reason is there not to adapt your life processes to your software processes?  Things that are second nature to you should present few problems in being applied to your software (though your team may take some convincing).  Really, it’s just a good way to figure out what is wrong on your team (or in your life) and figure out how easy it is to fix it.  Here is a small quiz about life and software development:

Scenario 1: You and your special someone have a miscommunication.  Do you:

a) Let it fester until the resentment has built up so much between you that you’re doing that “get the jelly, twat” joke in the middle of Publix but it’s even less funny than when Dane Cook did it

b) Talk it out until you are on the same page so that there is no tension and so that you can better handle similar situations in the future

If you said A, yer doin it wrong.  In the sense of literal communication, you need to be sure to discuss issues to keep the pair relationship and team relationship healthy.  Having a lot of tension between team mates can create not only a very unpleasant environment (for everyone), but will produce shittier code and probably mess up your velocity/cycle time (just because you’re is not functioning well as a team).  Keep your relationships healthy with communication (see: some other blog I wrote).  In the sense of letting things fester, ignoring problems or not resolving them right away is a fast way to fail.  Your system will get buggier and worse the longer you go without fixing bugs as they come up.  Fix problems as problems occur to prevent this kind of crap from happening.  If you said B, congratulations!; that was the right answer.  When pairing, dating, or even just working as a team, I find that JIT retrospectives are the way to go.  To me this doesn’t necessarily mean sit down after each feature is developed and deeply discuss every good and bad thing that has happened, but it does mean that during a weekly demo (or whatever form of that you do) you should talk about how things are going.  Iteratively handling situations will help you to grow closer rather than apart, and you will learn (in either scenario) much faster how to handle the situation as it arises and improve upon it from there.  We used scrum for a while and the daily stand-ups kind of handled this, but we really didn’t need to do it daily; it just ended up being wasteful.  Handling issues just in time at our weekly demos has proven immensely helpful to us; I recommend giving it a shot.  The big retrospective at the end still has value, but you might not even need it if you’re handling things as they come.

Scenario 2: You and your sweetie are planning a vacation to a secret remote tropical location.  Do you:

a) Plan out every detail far in advance and set a very strict itinerary

b) Keep a list of the items you want to do and set general ideas about when to do them

Why does A fail?  Rain.  Exhaustion from climbing a mountain the prior day.  Being hung over from a dastardly amount of rumrunners.  Whatever.  There are too many outside variables that you won’t know if you plan too far in advance.  Option B allows for plenty of change, and a more relaxing time.  Sure, you may need to set some things in stone if they are only available at certain times/on certain days, but for the most part keeping it easy will afford you a better vacation.  Change is a constant, so it is really the only thing you can plan for and ensure that those plans will work out.  JIT planning of your activities will ensure that you are always doing what you want to do next rather than what has been decided as your next item; JIT planning of your stories and priorities will allow room for change and make sure that the next thing you’re working on is the next actual priority.  Now, here I am kind of a liar, because I sure do like to make a good itinerary if the occasion should arise.  But I’ve fallen prey to all of the above downfalls I listed for A (especially the hangover), and also I’ve had great opportunities come up while I was on vacation that bumped other things off the list.  And they were worth it.  So I’m going to try out approach B for the next super secret remote island getaway I plan because I know it will work.  Because it works on my team.  These things, they go both ways.  Get it?

I could probably go on with more scenarios but a) your eyes might glaze over b) I think this is a good start.  Think about things you do and the way you effectively handle situations in your everyday life.  How can you apply these to the way you work, your processes, your team environment in general?  Are you working in a way that is contrary to the way you naturally work?  If so, why?  Start paying attention to things like this and see if you can find ways to improve by doing more of the same, but in a different area of your life.  All you have to do is look around and observe things and the answers are in front of you, because you know them.

Usability: Your Mom Loves It, or, I Friggin’ Hate My Car Stereo

I friggin’ hate my car stereo.

I installed it about two months ago and have just been hoping that it will get better/easier/I will magically figure it out, but no.  It makes me angry almost every day.

What’s that you say?  Read the manual?  Hell no.

I hate you.

I read through some parts, things that I needed to know immediately, but I don’t want to read it.  Most people don’t want to read it.  How many of you read the manual for each new product that you get/new software that you use?  Do you read a 60-page manual, or do you poke around with something until you’ve figured out how to use it?  Well, guess what.  Your users probably do that too.

If you’re anything like me, you poke around and swear and complain until you’ve figured it out, and then triumphantly give the bird to the technology that you have made your bitch.  I have given the bird to my car stereo several times already, but never triumphantly.  Here are some reasons why:

1) It scrolls a title across so you can read the full thing.  Well, that’s great, but it can fit probably 16 or 17 characters on the display, and it scrolls every name.  So when the song Milk by Kings of Leon comes on, it will scroll that title.  Four characters.  (note: This was the first time I noticed this particular annoyance, and what a prime example.  FOUR CHARACTERS.  Are you kidding me?!)  This is an easy piece of acceptance criteria that was missed.

As a Pioneer car stereo owner I need text to scroll when a song comes on so that I can see the full body of text.

– If text is <n characters do not scroll.

Ta-da.  That was hard.

With just a little more attention to detail and developer thought this would not annoy me EVERY DAY.  Developers should be thinking about multiple scenarios and general usability as they build new software.  This was simply an oversight and a lack of thought.

2) You can only control the iPod through the stereo itself, not through the iPod.  Well, you can if you have any models except X and Y (I have Y…I don’t remember exactly what it is, whatever generation video yadda).  A) Why make it compatible with every iPod and iPhone except the one that I use (and one other one)? B) I have 4800 songs on my iPod.  In order to use the stereo to find the track I want I have to go through EVERY ARTIST.  And the scroll wheel on the stereo?  Not so fast.  It is easier to unplug the iPod and find the item on there and play it, then hook it up.

I shouldn’t have to figure out alternate solutions to play my music.  I shouldn’t have to unplug my iPod every time.  The solution should present itself.

3) There is a way to shuffle the artist but you have to, like, uncover a staff and put it in just the right spot and the light has to pass through the glass and indicate where the buttons are to make that functionality happen.  I don’t know how to do it.  The times I have made it happen have been purely serendipitous.  I do know that every time I try to do it, I shuffle all 4800 songs and sometimes it sets my iPod itself to “shuffle artist” so the next time I try to listen to an album it plays it in random order.  Changing settings on my iPod without my permission?  That’s a paddlin’.  The functionality should be limited to the stereo itself.  Now, when I listen to my iPod on my sounddock or with headphones later, I will have to go into my Settings and change it, even though I never elected for the change to happen in the first place.  Poor.  Usability.

So, let me get to the point (finally).

I am a fairly typical user of this system.  Maybe I have a leg up because I have a pretty good handle on technology, but in general I am someone who listens to music in my car and can press buttons.  This shouldn’t be so hard.  Especially for someone (fairly) adept at using electronic devices.

Usability is a really key part of good software.  The book “The Design of Everyday Things” by Donald Norman is one of the greatest books you can read as someone interested in making quality software.  One of my favorite points that it makes is that users should not notice design.  If a user notices design, it’s generally because they have been given cause to because they can’t figure out how to do something.  Your design should be very intuitive and friendly to users; they should be able to just breeze through it without thinking.  If you have to put a lot of labels or instructions on something, you’re probably doing it wrong.  Don’t get me wrong, often some type of directive is necessary (working in medical software, it’s hard to get around sometimes).  However your system/site/app should be pretty damned user-friendly.

The keys to good usability really boil down to just a few things:

1) Developers need to put thought into the use cases of the software and multiple scenarios for which it will be used.  Think about the value that you are providing to a user and how you can make that even better.  Kaizen that shit.  Put a lot of thought into what you are making so your users don’t have to put any thought into using it.

2) Attention to detail is critical.  Think about anything you buy.  Handmade things in particular.  You want the one that looks the best, don’t you?  Well, maybe you want the quirkiest because you’re the hippest hipster of the bunch, but you get the idea.  Quality is absolutely necessary if you want to sell a product and attention to detail is a cornerstone of quality.  Yes, of course it’s important to hit the big points and get the big features, but something with a lot of great features that misses a lot of small things and is wholly unusable is not a product that people want to buy.  I consider any lack of attention to detail to be a bug, whether it is an actual defect or not.  Ignorance is a defect.

3) Make it intuitive.  If you’re developing iteratively (which you should be), demo it to your users.  Can they figure it out?  How many questions have they asked you about what something does?  Go from there.  When I design things I like to try to think about my mom using them.  She doesn’t know what the internet is, so it’s really an extreme example, but in general I try to think about people who don’t have a lot of technical prowess.  A lot of our software is designed for doctor’s offices, and an awful lot of people in these offices are averse to new technology and in general using computers/software.  What I need to do is design something that will be so easy to use that it a) won’t completely change their workflow/add time to their daily tasks b) will be enjoyable to use.  That is how you should make all of your software.

There are a million things to say about usability so this is likely the first in a series of posts (mostly this one is just a rant about that damned stereo), but I welcome any input or questions for future posts in the comments.

A Post About Kaizen in Which I Get Preachy, or, There -is- a “Try”

Scott says (9:41 AM):so a guy is on a cruise ship

Scott says (9:42 AM):and they cruise near this island in the middle of the ocean and he’s on the deck looking out at the view, and sees a haggard man on the island in tattered clothes running around and waving his arms frantically

Scott says (9:43 AM): and he goes to the captain and tells him about it, and the captain says “yeah, I don’t know what’s up with that guy. we cruise by here every month and he’s always out there doing that”

Scott C. Reynolds told me this joke this morning and it really made me think.

A lot of times development teams have this problem.  They are blind to the fact that something could be better.  We have many times when something will get screwed up or be done poorly and no one fixes it.  There are a number of reasons people will do this…laziness, unwillingness to learn, general blindness.  But maybe it is because they don’t know that there is a better way to do something.

One thing I’ve taken away from this past year of change is the philosophy of kaizen.  “Kaizen is a Japanese word adopted into English referring to a philosophy or practices focusing on continuous improvement in manufacturing activities, all business activities, or even all aspects of life, depending on interpretation and usage.” (Thanks, Wikipedia!)  In everything I do I tell myself that I will do it better than I did yesterday but not as well as I will do it tomorrow.  By doing this, by absolutely drilling it into my brain until it is part of my unconscious, I am ensuring the most quality in everything I do.  If my stories aren’t comprehensive enough and my acceptance criteria not robust enough, I am sure to deeply interpret the next thing I have to write and make it more thorough.

This is how everyone should live.

Software will never be perfect, I will never be perfect, and change is a constant.  These are all truths.  If you can fully ingratiate the notion of kaizen into your life and try to make improvements on everything you do, you’re gold.  You can’t expect to write flawless code every day, but you should expect yourself to see how you made those bugs and why you made them and figure out how to fix that in the future.  If you are thrashing with something, do a little more research on it.  Work a little harder.  Anything you can do to make yourself better, to make your products better, is never a bad thing.

Here’s a thing: broken window theory.  The gist is that if a building in a bad neighborhood has a broken window and it’s left alone, that building is more likely to get vandalized worse because the perception is that it doesn’t matter.  You can find these buildings all over the place in DC in the area of the 9:30 Club (that’s all I can picture when I think of this theory).  These people leave one broken window, and then people start tagging.  And then they break more windows.  And then they have bonfires and pee in it.  Et cetera et cetera.  But say someone boards up that window before the crap happens.  It looks like someone cares.  Maybe it still gets a little graffiti, or maybe people don’t mess with it because someone lives there or otherwise uses that building.

Get it?

Don’t just let bad code sit.  Do the Boy Scout thing.  Leave the campsite a little cleaner than when you found it.  Don’t keep making the same mistakes and letting QA catch them and then do wasteful rework.  Figure out a better solution for what you are doing, talk to someone else who knows it, read blogs.  Do SOMETHING.  Stagnation is the death of everything; do not let yourself become stagnant.  Start improving today.

Maybe this sounds hard.  Well, no one said it would be easy, least of all me.

Do a little introspection and take a look at the way you work.  What are your problems?  What is holding you back from being the platonic ideal of yourself?  Why does your code keep getting kicked back from QA?  If you just pick one thing at a time and lock it into your brain to do, you’ll be there in no time.  Making too many changes at once is a sure way to fail.  Your body and mind are sensitive and need time to adjust; if you want to quit smoking and lose 30 pounds and move to a new place, you’re gonna need to space those things out.  You will fail at one of them.  If you do not, you are a freak of nature and should be burned at the stake (I’m speaking to one person in particular).  The rest of you, don’t feel so bad.  There’s always room for improvement.

Plays Well With Others: Communicate or Die Trying.

So you’ve written some clear and concise user stories with robust and clean acceptance criteria.  Good job.

You’re not done.

Because user stories are placeholders for conversation, simply writing them (no matter how fancy and thorough they are) is not enough.  You need to follow through and talk with your team about what the stories entail.  On our team, Wednesday is Demo Day.  We do a demo of what has been developed so far for our major project, go through screens that have been designed to make sure everyone agrees with the design and functionality (and to make sure they understand what needs to be built), and go through the next MMF to be developed.  At this stage people can interject with additional acceptance criteria that are needed, any concerns they have for the legality or complexity of the system, or anything else they need to voice about the upcoming work.  It’s a great way to make sure everyone is on the same page and have a pretty good understanding as a team about the project as a whole, but even that is not enough.

Last weekend I was emailing back and forth with one of our developers regarding a particular story…the story was fairly confusing, partially because of the way it was written and partially because it is just a confusing piece of functionality.  In the end (after maybe a dozen emails) we realized we needed a higher bandwidth conversation and input from others to really get this story locked in.  When demo time came on Wednesday I found out another developer had taken and worked on the story by himself and the one I had spoken with had not ended up working on it at all.  As the demo went on it became apparent that the entire thing was completely wrong.  Several days of development time had now been lost on this project and we would have to scrap all of that functionality and start over.  This is waste.  Waste is the enemy, to be sacrificed on the altar of agile on the betrayer moon.  Appropriate communication between myself and the team could have avoided this, and this example will serve as a lesson in the future (I hope).

Communication is really the key to everything.  Software development has gotten so good and improved so much because of all of the communication that happens now.  Think about how effective pair programming and user stories are as opposed to one dev holing up in a room with a use case and cranking something out.  Being able to communicate effectively will improve your team and your product, make releases go smoother, and in general keep your life together.  In the past year I have had to make a lot of changes to my life and improving my communication skills (inside and outside of work) has been the best thing I’ve ever done.  If you are thrashing and can’t seem to find a good place to start making improvements, I strongly suggest taking a look at how you communicate and seeing how you can improve that.