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.

1 comment so far

  1. G Valentino on

    Primo: Loved the post and this series.

    Deux: We’re also dealing with what the right mix of text to mock-ups is. It’s also complicated by the fact that most of our developers have English as a second (or third) language. They’re all grand, don’t get me wrong, but there are little nuances in language and culture that can get lost.

    What we’ve been doing lately is a hybrid approach:
    1) I draft the workflow and screen progress in our whiteboard room, since I can do this quickly and it helps me make decisions on the fly.
    2)Once that looks sensible, I create a high level story explaining the workflow. This gives us the need and the happy path solution.
    3) Our developers do a prelim tech analysis and estimation. This way the devs aren’t surprised, and it helps us refine the scope so it can fit into our iteration.
    4) I refine the story, translate my wireframes using pen and paper, scan those in, send to devs for full estimate. This gives them something more tangible to work with, and I can do this faster so they have more time to ask questions
    5) Our UI guy in Moscow takes my screens and makes high-fidelity mock ups. He’s a genius with UI, and also speaks both Russian and English perfectly so he can field a lot of questions/notes without having to involve me for every one.

    By this point we have a story that
    1) Describes the need/problem
    2) Has a high level overview of the solution so they have a goal
    3) Text to describe the basic workflow, with screens to provide as much detail as possible. The only descriptions for the screens are either for (1) validation or (2) non-typical events.

    Also the story has gone through a few iterations at all levels, so there’s a nice shared history of the experience which helps with answering questions that arise at design time.

    It’s not perfect, but hey, you gotta start somewhere.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: