Balsamiq

Meet UX Apprentice

Hello friends of Balsamiq, we have a very exciting new resource to announce today!

Balsamiq Mockups has helped democratize interface design in the communities who use it. A broad range of people coming from different roles and fields have adopted sketch-style wireframing. Making ideas come to life quickly with wireframes is a revelation. Your newfound power to create user interfaces is exhilarating!

Soon enough though, all beginning UX designers realize that creating products that are easy to use is actually quite hard! You have to know about information architecture, interaction design, copywriting, and lots more.

Meet UX Apprentice, a new site we created for people learning about User Experience Design.

We worked with Theresa Neil on developing a learning resource that covers some of the basics of the practice, and provides links for digging deeper and perfecting the craft.

We feel very lucky to have joined up with Theresa, who wrote the content and helped us design this site. She is a design consultant, and author of two O'Reilly books on interface design—Mobile Design Pattern Gallery: UI Patterns for Mobile Applications, and co-author of Designing Web Interfaces: Principles and Patterns for Rich Interaction. We called on her depth of teaching experience as an author and as a consultant who educates companies about UX Design to bring this knowledge to our awesome customers in the Balsamiq community.

We hope UX Apprentice helps many people who are getting started with interface design to both broaden and deepen their knowledge about UX Design.

Ready to dive in? Let's go!

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.

New Keyboard Shortcuts Cheat Sheet

We've updated the Mockups Keyboard Shortcuts cheat sheet to reflect new shortcuts in 2.2.

You can view the HTML table or download the printable PDF here.

Refining the roughness of 2.2 controls

If you've been following along with updates to Mockups, with 2.2 out we now have a UI Skin switcher that allows you to use either sketchy controls or straighter wireframe controls.

In preparing the skins to work well with each other, we had to optimize the rectangle shape that’s the basis for many of the controls. This makes it so the transition was smoother when switching between skins—we needed less variability in the positioning of controls, and we needed to remove the artifacts around the edges of shapes that resulted from the bitmap rendering of the hand-drawn graphics. The downside to this is that in doing so, we cleaned up the sketch skin too much, and we've heard a lot of feedback that it should go back.

We agree on that point. The sketch skin is too refined now. I think I was waiting to hear more feedback during the beta and just waited too long rather than roughening up the lines, and we shipped it as it is now. I've been spending some tweaking the rectangular shape to roughen up the controls again and I think it's closer to what we have before.

Here's some screenshots to give you an idea. It's subtle, but the boxy lines have a slight bit more jitter and are thicker. Click the thumbnails to view larger.

If you compare it to the controls from 2.1, I'd say it's pretty close. We'd love to hear your feedback. You can try this now in the Next Release Preview.

Wireframing Responsive Designs with Mockups

Responsive layouts using media queries and CSS on the web are exciting. Many Mockups users are doing responsive layouts on their projects or are planning to. We've been talking with the Balsamiq community about how Mockups can work with responsive web design concepts, and we thought we'd explore some techniques that might help.

We wrote up a short tutorial with some techniques that may be useful if you're exploring how you will approach wireframing with responsive design in mind. I used the Bootstrap Symbols Library I blogged about previously as a grid system. Check it out and if you have other ideas, let us know!

You can find out more about responsive design, check out the post by Ethan Marcotte in A List Apart, or more generally in the Wikipedia entry.

Bootstrap Grid Layout Symbol Library

This is a Symbol library with a set of grid layouts using the Bootstrap framework. The different layouts correspond to min-width and max-width media queries for different viewport dimensions, to help people doing responsive layout wireframes.

Toggling Markup visibility (CTRL+K/CMD+K) hides columns, notes, and top bar to reveal only the square rectangle of the viewport.

To use as a symbol, click the Download BMML link under the Mockup on the page above and save to one of your assets folders to use as a Symbols library, or you can download the BMML file directly from here:

https://mockupstogo.mybalsamiq.com/projects/layout/Bootstrap+Grid+Layout.bmml

In case you're unfamiliar with Symbols, they are re-usable components that you can customize. You can find documentation and tutorial for using Symbols here. A tutorial for using this symbol library is forthcoming.

Ideas for indicating content outside of viewports (browser windows, iPhone screens, etc.)

Sometimes you want to mock up a box, but show it at a fixed size, or the content of the box gets too long to fit in your wireframe. But you may still want to show what the overflowed content is outside of the visible area or viewport. The typical case that we get asked about is how to show a fixed browser container or iPhone, but show that there's content that's not visible, that must be scrolled into view.

I typically use a breakline if I want to indicate continuation on a fixed box. The technique is to show one end of the box with a jagged edge, as in the Breakline symbol below.

Here's another Breakline Symbol library on Mockups to Go that might help:

If you want to do this using another container, for instance a web browser or mobile device you can also crop the container like I've done in this Custom iPhone symbol library:

To change the screen area, you'd then edit the group and resize the geometric shapes used there.

Hope this helps someone. Click the images above to go to the Mockups to Go pages and download the symbols libraries for these examples.

Preview the Mockups application chrome redesign

Hi, everyone. This year we're working on some projects to polish Mockups, and we want to give you a preview of one of them—the redesign of the application interface or app chrome.

Application chrome refers to the user interface elements of the application window outside of the canvas. This includes such things as the menu bars, toolbars, progress bars, ui library browser, dialogs, and inspectors. Essentially what we're doing is polishing the design of Mockups itself.

With the release of myBalsamiq, we've started introducing some new interface elements in the app, especially the app bar. The chrome design hasn't changed much since Mockups was released, but with myBalsamiq, the accretion of elements has become noticable, and the changes more drastic. We wanted to refine this area, see what could be cleaned up or removed, and prepare for the future.

Goals

Now is the right time to focus on these:

• Fix usability issues related to visual design (contrast of scrollbars, for example).
• Making the myBalsamiq editor chrome match the design of the html views.
• Create a coherent design language and style that works across the Desktop, myBalsamiq, and plugin versions.
• Create an aesthetically pleasing experience that we want to look at every day.
• Prepare for desktop/myBalsamiq integration, and Mockups for Desktop Pro(jects).

On the surface you might say it's just a re-skinning of the chrome, and you'd be right. We're starting by cleaning up the current functionality.

If you look closely at the design for mybalsamiq you'll also see that the interface includes a project (and symbol library) browser sidebar. As we move towards our goal of bridging Desktop and myBalsamiq, some of the design elements of the myBalsamiq editor will make it to the Desktop app.

Preview

Here are some design comps of what we've started implementing. Click to view larger.

Desktop App Preview

myBalsamiq App

Interface elements
For the documentation fans out there, here's a closer look at some of the design elements.

That's a quick preview at where we're headed. We hope you'll agree that the direction we're taking is a sensible one at this time. As always, we welcome your feedback with open eyes and ears. Leave a comment or email me at mike@balsamiq.com.

We know we have a long way to go. Every day we take another step.

You can try the pre-release here on the web or download the latest 2.2 candidate here. Bookmark that page and check it daily! ;)

Mocking up physical objects

Who says Mockups is only made for interface design? Tennis player and Balsamiq friend, Gabriel Coch posted some great images of a cool chair made from recycled tennis balls.

Here's the concept he illustrated in Mockups.

And the finished product.

Looks pretty darned comfortable too! Love it, Gabe!

Balsamiq Interview on IATV

We took some time out to talk to Jan Jursa on the IATV podcast. Peldi, Jan, and I discussed Mockups and myBalsamiq, wireframes and prototyping, and what's happening right now with our little company.

You can listen to the podcast at IATV Radio. It's Show 6 recorded on Feb 19, 2012. Our interview starts at 16:05.