Balsamiq

Using Mockups in your Agile User Stories

Hello, blog readers!

This is my first blog post for Balsamiq. Anyone who's worked with me knows that I have been a user and fan of Balsamiq Mockups since the beginning, so I am super excited to be a part of this awesome team.

Before coming to Balsamiq, I worked as a User Experience Designer and Business Analyst in Agile software development environments, so I thought I'd focus my first blog post on some tips I developed for creating Agile User Stories that served me well.

First off, I think that Agile and Mockups go great together. Agile is fast, embraces change, and doesn't require precision. Just like Balsamiq Mockups!

In this post I'll explain my Story writing process by describing the steps I'd go through to create a User Story for a made up feature. These steps are: break up the design; order, prioritize, estimate; and write the recipe. I probably deviate a bit from the suggested formula and format for User Story writing, but I feel that it's still true to the principles of Agile.

Side Note: This post is written from the perspective of, and primarily for, someone who writes User Stories in an Agile Development environment. I'm thinking mostly of Product Managers, UX Designers, Business Analysts, and any other people who are primarily non-technical, but work closely with software developers who are the recipients of User Stories.

Introduction

I'll start at the point that the mockup is finished. At this point a lot of the work is actually done, but it's important to take the next steps to craft a good User Story out of your design.

Let's say that you've come up with a design that allows users to view a list of customer demographic information. Something like this:

Now, it's tempting to just drop this into a User Story and say "build this". But it's important not to discount how much information is in your head about how this relatively simple page should function. There are some gaps that need to be filled in for the developer who's going to be building it. But don't under- or over-think these gaps. My Story writing approach is focused on "the art of maximizing the amount of work not done", which is one of the reasons I use Balsamiq Mockups.

This approach is all about taking advantage of the 80/20 rule.

The trick here is to combine the 20% effort that gets you 80% of the detail in a visual representation with the 20% effort that gets you 80% of the detail in a text specification.

There's no question that developers need detail in User Stories. Mockups is great because it will get you 80% of the information that you need to communicate with 20% of the effort of a more interactive or pixel-perfect tool. Now, don't spend 80% of your effort on that last 20% of the detail, just describe it using plain language in the User Story (I'll describe how later). The goal is not to have a huge, impressive-looking specification or prototype, the goal is to ship a product that allows your users to accomplish their goals.

Your User Story should be just enough to get it built successfully. Any effort beyond that is waste.

Step 1 - Break up the design

What often surprises product managers is how long it takes to develop user interfaces. A lot of that frustration is due to a lack of understanding about how user interfaces are actually built. There is rarely a correlation between how long it takes to design and how long it takes to build. That's why I like to take the time to divide up the design into smaller chunks.

Even this simple design can be broken down into pieces. Pieces, mind you, that can be delivered individually (as long as an order is obeyed). You can't deliver an incomplete feature, but you can deliver a small part of a larger feature. There's a difference. A button that doesn't do anything when you click it is incomplete. A data table that you can view but not edit, for example, can stand on its own.

Here's how I might break this feature up into pieces:

1. The table and its content
2. The search field
3. The edit and delete functionality
4. The ability to export

Note that, in that order, they can be delivered, and even released, in pieces. A table that doesn't have search may not be as useful as one that does, but it's still contributing towards the original feature requirement. Each Story should add some amount of value, however small, for the customer.

Side Note: Just because you're going to break up your work doesn't mean that you should think this way during the design phase. The value of Mockups is that it allows you to easily get what's in your head onto the page. And, more often than not, what's in your head is at a high level. So, go with it, and design what's in your head. Don't worry about the Story writing when you're designing.

Step 2 - Order, prioritize, estimate

A note about the ordering of the Stories. The important thing when breaking up a design into pieces is to find the foundation, the piece that other pieces will be built upon. In this case, I chose the table itself. You could argue that this is also the most important piece of functionality. The foundation often is. That's why I write this Story first. Writing the most important Stories first helps ensure that the most important features get delivered. With fixed release dates and shifting agendas, never assume that everything will get shipped. Start with the important stuff and you'll at least be maximizing the value of your time.

When I insert the mockup into the User Story (as an embedded image, attachment, etc.) I don't necessarily remove the peripheral information once I've decided how to break the design into its components. One of the things I like to do is show the full mockup that I created, but obscure the parts that don't apply to the specific Story. That way, it's clear what the objective of the Story is, but you're also keeping in focus the end goal.

I might do something like this, for example:

I've greyed-out the peripheral pieces, yet left them visible for everyone on the team to see where we're headed. The numbers refer to the Story numbers of the other pieces.

One real benefit of breaking up the design like this is that now you can get estimates on each of the pieces (and the mockups alone should be enough to get estimates), which should not only be more accurate, but can be divided up across sprints. Let's say that after the estimation meeting the point values end up something like this:

1. Table with customer data - 2 points
2. Edit and delete functionality - 4 points
3. Search - 1 point
4. Export - 3 points

This will allow the product owner to make better cost-benefit decisions about the overall set of features. Maybe the export function is something that one noisy customer keeps asking for but that you know won't be used by most of your customers. Seeing that this piece is relatively more "expensive" than some of the other pieces might prompt you to put it off until the next release. This wouldn't have been possible if all you had was a 10 point estimate for the whole design.

We've actually come a long way already at this point. But don't stop there, there's one more step!

Step 3 - Write the "recipe"

The final phase is to use the mockup to help you figure out the details that the developers need to know to build it. A trick I learned to do this is to imagine yourself using it. Mockups is awesome because it clarifies the picture in your head of what you're building and allows you to picture its use. I've found this process to be extremely helpful in providing the details that the developers want while building it.

Creating a mockup is kind of like cooking something. Think about cooking your favorite dish. Now, think about writing a recipe for how to cook what you've made. It's a different process entirely. It's shifted from creating to communicating. It's all about putting yourself in their shoes and not making too many assumptions about their level of understanding or knowledge.

The lesson here is that the process of creating the mockup is actually more for you than for the developer. It helps you figure out what you want to build, which, in turn, makes it easier to communicate how to build it (even if you're completely non-technical).

The structure of a User Story that I was taught is the following:

1. Summary/Story Narrative
2. Mockup
3. Acceptance Criteria

Side Note: I like to include the "why" of what we're building in the Story Narrative section and explain what value this feature provides. Believe it or not, developers care about this. And this explanation should pass their "smell test" too. If you can't get them to "buy it", maybe you should revisit why you're doing it.

The third part is Acceptance Criteria (also called Conditions of Satisfaction, Acceptance Tests, etc.). This section is both for the developers and the testers. Here is where I think I take a bit of liberty with the traditional format. I like to think of this section as the recipe part. Here is where you, to the best of your ability, tell the developers how to bulid it. Don't worry if you have a hard time with this at first, one of the benefits of this process is that it helps you learn what information developers need to build things. It opens the window into the development process, which benefits everyone.

Again, here we start with a foundation. Don't be afraid to get very basic. I might start, for example, with "Create a table with the following columns: Last Name, First Name, Address, Phone". Small pieces make it easy to check things off, and often actually correspond to the chunks of code the developer has to write.

Now that you can see this table with customer information in it, picture using it. Aside from the features that you've deliberately split off into other Stories, what might you, as a user, see and do here? Can you sort columns? If so, all columns, or just some of them? Anything that you can come up with along these lines is most likely information that the developer needs to know.

As a bonus, if you're somewhat techincally savvy, you might be able to think of other things the developer might want to know. You might know that address data is stored in separate database fields (street, city, state, zip, for example). If you don't specify, the developer may create separate columns in the table for each of these, because that's how they see "address". But, you may know that users prefer to see these fields together (maybe so they can easily copy and paste them all at once). So, add to your recipe that the address field should include street, city, state and zip together. Trust me, stuff like this is important.

But, also, realize then that users probably won't be able to sort the table by city, for example, because "city" is not a distinct column in the table. Product managers often want it both ways. Being forced to write the recipe yourself doesn't allow for that. It's a trade-off: do you want a more human-readable address field, or do you want to be able to sort by each part of the address? It's up to you. This is not the developer's problem.

For this particular Story, here's what my acceptance criteria might look like, just to give an idea of some other possible details I might include.

Acceptance Criteria
1. Create a table with the following columns: Last Name, First Name, Address, Phone

2. Add a level 3 heading title for the table above the table with the label "Customers"

3. The Last Name, First Name, and Phone columns should include the last name, first name, 
and primary phone number fields, respectively, for each customer

4. The Address column should be comprised of the following fields (in this order): street, 
city, state (abbreviated), and zip code (5 digits only). Wrap the text to the next line 
at 100 characters.

4. By default, order the table by customer last name (ascending)

5. Allow the table to be sorted by last name or first name

6. Add pagination at 25 rows

See how many details there can be for a simple 4-column table?! The take-away here is not about how hard it is to build this table (it may take only 30 minutes if you already have a table framework in place), but how many decisions need to be made when building it. And that, if you don't specify them, those decisions will either be made by the developer or the framework you're using. As in many cases, not making a decision is making a decision. Now, if you don't care, that's another thing. But I would argue, as would many others, that details matter.

At this point, I would show the Story to the development team for a reality check, make any modifications necessary based on their feedback, and put it in the development queue. That's it! Then, on to the next Story… ;-)

A few final tips:

This process has been successful for me. What's your Story writing process? What tips have you developed for writing User Stories? If you have any thoughts on the process I've described or your own tips for writing User Stories, feel free to share in the comments.

Creating eBooks with Pages.app

iBooks on left and Kindle on right.

We sometimes get asked for downloadable versions of our Mockups documentation to go along with the online version we publish on our support site. We now publish the Mockups Docs in PDF, and additionally in the ebook reader formats EPUB (for iBooks) and MOBI (for Kindle). It's nothing fancy, just a version of our Documentation that was prepared in Apple iWork's Pages.app, and exported in all of these formats.

Since we took the time to figure out how to do this, we thought other small companies who may want to do the same may save some time by seeing the notes we took when we set up our templates and migrated our content. These steps are only useful if you're using a Mac, obviously.

Download our eBook

If you want to get an idea of what we've published, you can download the eBook for the Mockups for Desktop Documentation in the following formats.

PDF
For viewing in Acrobat reader.

EPUB
For iBooks app for iPad, and other ebook readers that support the EPUB format.

MOBI
For Amazon Kindle and other eBook readers that support the MOBI format.

Notes about downloading
Instructions for installing the EPUB and MOBI files vary depending on your device.

• iPad: On iOS 5+ iPads, press the links to open, and you'll be prompted to Open in... the appropriate app (EPUB for iBooks and MOBI for Kindle).
• Kindle: On Kindle devices, download the MOBI file and sync with your USB cable.

Download the Template

We learned how to publish to EPUB using the Apple article, “Creating ePub files with Pages”. We used a sample template they provided and modified it to suit our needs. Then we used a tool called Calibre to convert our exported EPUB file to MOBI, to make it available to Kindle users as well.

First start by saving our template file: eBook.template

You can simply open the file and select the menu File > Save as template... to save it on your Mac to ~/Application Support/iWork/Pages/Templates/My Templates/.

Writing and Editing

Set up your workspace:

• Styles Drawer should be visible. If it is not, select View > Show Styles Drawer.
• Inspector Should be visible. If it is not, select View > Show Inspector.
• Use Layout mode. View > Show Layout.

Start your file

• Start by opening a new blank document by select File > New from Template Chooser...
• If you added the eBook.template file above, you will see it under My Templates. Select it and click "Choose."

Set up title page

• With the first page selected, check the Layout Inspector > Section tab. "First Page is different" should be checked.
• Change the title and subtitle.
• To add a new image select the image box. Select the menu Insert Choose... (or use CMD+SHIFT+V) to place a new image.
• Change the author and edition text if necessary.

Table of contents

• Leave it alone, it gets generated automatically.
• If for some reason you have to force it to update, right-click the TOC and select Update Table of Contents from the context menu.

Adding Content

• Chapter title
  • Insert the cursor at the start of a new chapter and select the Chapter Name style from the styles drawer. Enter your chapter name or paste it via Right-click > Paste and match style.
• Headings
  • Use the Heading style for headings, Subheading style for subheadings.
• Body
  • Select the Body style. Start entering your content.
  • If you've worked on the content outside of pages, select the content you want to paste, right-click at the insertion point and select Paste and match style.
• Images
  • Use Insert > Choose (CMD+SHIFT+V) to insert images at the insertion point.
  • Images must be inline to work properly in EPUB an MOBI format, so be sure to check the Wrap Inspector. Make sure you have the "Inline" radio selected images they flow with the text. Check "Object causes wrap."
    
  • Use a hard return after images.
  • Use the Caption style if you want to place a centered caption below an image.
• Lists
  • Put each list item on a new line, select the entire series and select the list style (bullets, numbered).
  • Use CMD+\] to indent.
• Code
  • Code Blocks: Use this style for blocks of code. They'll be shown in a block with a fixed-width font and yellow background.
  • Inline Code: Use this style for code that's shown inline in a paragraph. They selected code will be shown in a fixed-width font and yellow background.
• Chapter Breaks
  • After the last line of the chapter select the menu Insert > Section Break. This will start the next chapter on a new page.

Header/Footer

• We use the header and footer for the PDF version only, since EPUB and MOBI will strip these out, and use the document properties instead to get this information.
• The header shows the Document Title on every page except for the title page. On the Table of Contents page, double-click in the header to replace it with your document title.
• The footer shows the page number. You can leave this alone.

Exporting and Testing

First, save your Pages document, obviously. For PDF, simply select File > Export PDF. Follow the instructions below for exporting EPUB and MOBI formats.

Exporting to EPUB using Pages

• Select File > Export.
• Select the EPUB tab, and enter title and author information.
• Check the "Use first page as cover image" checkbox, and click Next.
• Ignore the warning about floating images, because you set the image wrapping properties if you followed the instructions above.
• Save.
• You have a few options to test in iPad: 1) Email the file to self as attachment and open to iBook, and 2) Open iTunes, drag to Books on left side of iTunes window under Library and Sync.

Exporting to MOBI using Calibre

• Use the Calibre app to convert EPUB to MOBI
• The process is pretty simple. Add your EPUB file to Calibre.
• Click Convert.
• I make sure that Output format is set to MOBI, and I add our company name to the Publisher field. I leave all other settings at defaults and click OK.
• After the file is converted, you can right-click the eBook in the app and choose Open Containing Folder to browser to the file on your file system. It's saved to the ~/Calibre Library/ folder.
• If you attach a Kindle you can copy the MOBI file to the Kindle.

That's all there is to it. Hope this helps.

New Tutorial on Specifying Interaction with Mockups

We've aded a new tutorial in the support section to suggest some best practices for specifying interaction using Mockups.

Software designers and developers designing for the screen have an arsenal of well-known practices for communicating interaction in static documents. Many of the techniques have been borrowed and adapted from motion designers, filmmakers, and animators.

Read the tutorial to learn more about doing interaction design with Mockups.

Sketching in Mockups

Interface sketching is a path focussed on generating ideas and finding solutions.

I feel good when I have a drawing pen or pencil in my hand. Doodling, sketching, and drawing has always made me happy, whether it's trying to be artsy in life drawing classes, imagining characters while drawing with my son, or capturing ideas for interfaces. I'm not the most skilled with a pencil, but I enjoy it. It's the quick and spontaneous creation that I've always loved, and I love being able to sketch as an interface designer.

Sketching interfaces is a path focussed on generating many ideas, and to borrow from Bill Buxton, is an activity that leads to finding the right design. It's focussed on finding solutions to problems. Lately I've been thinking about how to further take the activity of physically sketching on paper, to get the same results in Mockups.

Sketching in the physical world

I think there's something interesting about capturing interface design ideas in sketches as a disposable, spontaneous action. After the conversation and research about the problem you're solving, there is always the need to visualize the solution. The quick sketch is the right tool at this time because it can be focussed on the idea without becoming attached to how it's represented visually—form is rough and function is usually the focus.

Here are some key things to keep in mind when doing interface sketches.

• create quickly
• create a lot
• don't worry about how it looks
• don't become attached

A lot of interaction designers and information architects make this part of the ideation phase easier by creating templates with small spaces for teams to create sketches within. These look like little storyboards. They're compartmentalized sheets of paper, usually 6-up or 8-up for thumbnail sketches. The idea is to produce as many ideas as possible at this stage and at this scale, and progressively add information, select, iterate, and refine.

Brandon Schauer and Leah Buley at Adaptive Path talk about using Sketchboards as a way of generating ideas with sketches and quickly performing iterations on many possible solutions. Todd Zaki Warfel of Message First also has a similar sketchboarding technique that he calls a the 6-8-5 method, where individuals produce 6-8 sketches in 5 minutes.

I've done most of my intertaface sketching on paper, but I've been wondering how to do that same sort of rapid-fire sketching early on in Mockups.

Sketching in Mockups

Over the past year I've continued to sketch on paper, and occasionally scanned and shared them with my team. But when the myBalsamiq beta/gamma matured and became more stable, I started finding myself experimenting with how to use it to do nearly everything.

Our design process at Balsamiq is a bit like a conversation that can start from any point, but which usually flows down a similar path. Here's one typical design/dev cycle for me.

• A feature is introduced from somewhere, internally or externally. A feature might be discussed in Pivotal Tracker, our issue tracker, or a quick Skype conversation may start it. From here, the story is described more completely.
• Ideas are are mocked up. We set down broad strokes. Traditionally, this is where I sketched. It's like the beginning of a conversation about a new topic, where one person introduces the topic and the dialogue ensues.
• The idea is iterated, a solution might be selected. We quickly select the idea with the most merit and iterate over it, filling in details about the flow and interaction required by the feature.
• The mockup becomes a UI Requirement when we finally all approve, and we build.

Previously I was doing all the sketching on paper, but now I'm starting to do some rougher, sketch-style ideation in Mockups using myBalsamiq. We're also doing all of our Mockups work in myBalsamiq now, so the critique and review sessions are happening there. And since myBalsamiq is much like using a wiki with version control, alternate proposals and the iterations are happening there too. All the ideation is being moved into the ecosystem we're building for ourselves.

What's a thumbnail Mockup?

Mockups has the low-fi aspect of sketch-wireframing covered. But we're still dealing with wireframes when we work in Mockups. There's already a level of detail working at wireframe scale, and when you work too early at that scale, there's the danger of diving deep before you're really ready.

It's hard to imagine that low-fidelity wireframes made with Mockups can become precious documents. The thick, crooked, sharpie-like lines and the unattractive hand drawn font are there to keep you from fussing and making things pretty and real. But they can become precious, and for many people they will. It's natural. You work with something for long enough and you become attached. This is especially why I think there is a step that you might consider before diving into full-scale Mockups, where you're even further from sweating the details, so you can see the bigger picture.

This is where thumbnail sketching steps in. I hardly ever start full scale on a wireframe. Before I have the chance to even think about the details I work with thumbnail sketches. It's like zooming 20 feet away from the thing you're designing, blurring your eyes, and just seeing the major elements of the page.

The idea with thumbnail sketching is to draw a smallish representation of your design, roughing out boxes and greeking lines of text to get an idea of what your interface will look like. You actually don't even need text to sketch the interface, just scribbled lines. You can use text captions to describe what's happening in the story.

Here's a picture to give you an idea of what I create on paper.

Ryan Singer of 37signals wrote a nice article in 2004 that illustrates his interface design approach, and shows some nice sketches like this if you're interested in seeing more sketches at this kind of scale.

Now here's a screenshot to give you an idea of how I've been doing the same thing with Mockups

I think this give you an idea of how I'm trying to make it close to the same experience in terms of speed and fidelity.

How to make thumbnail Mockups

To create our Mockups at this scale, we start out with two simple shapes: the box and the line (straight and squiggly). With these two, you can pretty much draw most of what you need for web and app interfaces, although you occasionally need other basic shapes like ellipses and triangles. Then, of course, you will probably need arrows to show directional flow.

I've created a thumbnail sketch symbols library that includes 2 sets of templates for 6 up or 8 up sets of thumbnail sketches, and a thumbnail sketching elements library. Download the "Sketch Templates" symbols library here.

Here's the basic set of sketch elements in the sketch library:

There's not much to it. These are the basic elements I used. There are straight and squiggly style lines for the text elements.

• Title/Heading
• Subtitle/Subheading
• Paragraph
• Sentence
• List
• Label
• Text Input
• Textarea
• Checkbox
• Radio button
• Button
• Horizontal rule

I can combine these with whatever geometric shapes and rectangles might be needed. I start to build up layouts quickly by dropping these blocks into place and annotate as I go.

Next you step through parts of the interface or entire views, by sketching the interaction and flow through some functionality, either in story-board form or by breaking out parts of the page into a sidebar, or what Dan Brown calls page description diagrams, illustrating state changes.

It might help to get an idea of how I do iterations on a single sketch board, so we've made one of our internal myBalsamiq projects for redesigning the Mockups heads-up-displays available for you to look at here. In particular you might want to check out the history page for my sketchboard to see how I stepped through iterations on that sketch.

Finally, you can look at how we started to work at the right resolution once we selected a concept from the sketchboard that represented the direction we wanted to go in. The wireframes for the HUD are worked on at 1:1 scale or something close to it when we're ready to start considering more than just abstract gray boxes.

What do you think?

Mockups gets faster for me when I focus on doing the right thing at the right time, and this idea is working for me for making quick sketching, or sketch-like activity more collaborative. I'm going to keep experimenting with this technique and updating the sketch library as I continue to evolve it.

Here's a bonus. If you haven't seen Dave Gray's Forms Fields and Flows video, you should check it out. In it, he writes about how sketching is just combining forms and lines, and all you really need to be able to come up with pictures is to see and use these basic shapes. This is what I'm doing most of the time when I'm designing outside of the intended use of Mockups' UI library.

Have fun!

Creating a Mac Menubar App for Pivotal Tracker

I spend a lot of the day answering questions in GetSatisfaction and logging bugs in Pivotal Tracker. I also spend a lot of time on a Macbook Air these days when I'm shuttling my son around and working in coffeeshops, and I've been obsessing over keeping the machine light and clean inside and out.

Inspired by this clever idea about using the Basecamp Mobile site as a Fluid menubar app, I decided to do the same with Pivotal Tracker. There isn't a mobile view, but if you keep your columns collapsed, you can use it with relative ease, and you won't have to keep it open in a browser tab.

The result should look something like this:

Here's the instructions for doing this yourself if you have a Pivotal account.

Prepare

1. Download and launch Fluid from here: http://fluidapp.com/
2. Download a Pivotal icon. I found this one here on sneaky.me to be good, but if you want a black and white icon, you can click on this one I made and save it instead:

Create App

1. URL: https://www.pivotaltracker.com/
2. Name: Pivotal
3. Location: Applications
4. Icon: Select other and browse to the icon you saved above.
5. Click Create.
6. Success dialog window appears. Cick "Launch Now."
7. Sign in.
8. Select the menu: Pivotal > Convert to Menu Extra SSB, and click OK in the dialog window.

Pivotal icon should now appear in your menubar and you can click it to open Pivotal in a drop down window. Drag the grippie in the corner to change the window size. Use two-finger scrolling to move in the window, because window scrollbars will be supressed.

Advanced Set Up (if necessary)

1. With Pivotal App launched, select the menu: Pivotal > Preferences.
   Select Advanced icon.
2. Second radio button should be selected, "Allow browsing to URLs matching these preferences patterns."
3. If not in the list, add: *pivotaltraker.com*

Hope you find it useful? I think it's an efficient way to keep it available all the time, while still keeping my browser tab count down.