Latest Tweets

A Designer’s Quick-Start Guide to CSS Preprocessors

| 11.13.2014

CSS can be a hot mess to write and read. I am here to repair your relationship with it by introducing you to your new secret weapon.

I once hand-wrote over 300 lines of CSS to style one lousy navbar, and I know I’m not alone. Writing CSS by hand, as many designers do, is an exercise in repetition. Reading CSS is a real workout for your scrollbar and your patience. Nevertheless, we’re stuck with it. How else could we round those corners or drop those shadows?

Writing code to style a website does not have to be (quite) this tedious. Preprocessors are the missing ingredient in your HTML/CSS workflow.

Lots of articles about preprocessors target developers, but this one goes out to UX and UI designers. A lot of designers I know – good ones! – have a solid basic understanding of HTML and CSS, but are cautious and awkward around improving their workflow. No wonder – with all the frameworks and libraries available, it’s hard to know where to start. Many developer tools are overkill for designers, not to mention their documentation assumes a lot of prior knowledge and a high level of server access.

While they may look like developer tools, preprocessors are a fabulous addition to a designer’s workflow. Even if your HTML/CSS is pretty basic, there’s something for you here. I’ll tell you about my favorite features and how they help me as a designer.

(This article assumes that you’re somewhat familiar with CSS. If you’re not there yet, try a tutorial at treehouse.com, lynda.com, or Codecademy.)

What’s a preprocessor?

A preprocessor lets you write CSS in a language that feels like a better, more sensible version of CSS. Then it creates, or compiles, a browser-readable CSS file. You don’t touch that compiled CSS file. You work on a nice tidy file with the extension “scss”. SCSS files are written in a preprocessing language.

preprocessor-wide

Naming note: Many people call this language both SASS and SCSS, but that’s not quite accurate. The language, called SASS, actually has two syntax modes. SCSS, the newer syntax mode, uses brackets around chunks of code. SASS, the older syntax mode, has the same name as the language and uses indentation and whitespace instead of brackets. Of the two syntax modes, I prefer SCSS – the brackets are foolproof and don’t get screwed up in different text editors.

Which preprocessor should you use?

I use SCSS, but you might also want to use a preprocessor called LESS. If your coworkers use one or the other, just follow their lead – both SCSS and LESS are great. If you’re on the fence, here’s why I recommend SASS (Chris Coyier at Treehouse agrees):

  • It has more logic built into it. You can do for-each loops and if-then statements right in your CSS. As long as you’re using a preprocessor, why not pick the one with the most features?
  • Adding the Compass library to SCSS adds a ton of useful reusable patterns.

So what can you do with SCSS?

Nest Now, Thank Yourself Later

Have you ever written CSS that looks like this?

.navbar {
	// styles
}
.navbar ul li a {
	color: red;
}
.navbar ul li a:hover {
	// styles
}
.navbar ul li {
	// styles
}
.navbar ul {
	// styles
}
.navbar ul {
// styles
}

You have to cram selectors into your CSS in order to make sure your rules have the right scope; you don’t want to make every link red, only the links in the navigation bar. The only thing more annoying than writing this structureless, repetitive code is trying to read it later.

With a preprocessor, you can write this instead:

.navbar {
	// styles
    ul {
		// styles
        li {
        	// styles
        	a {
	        	color: red;
				&:hover {
						// styles
				}
			}
		}
	}
}

In SCSS, “&” refers to the current selector: the selector just outside the surrounding bracket. So, in the example above, &:hover compiles to a:hover.

The nested code is far less repetitive and easier to read. Just don’t nest hundreds of lines deep, or (if you’re anything like me) you risk misplacing a bracket or two. I try to keep nested chunks of code small enough to fit on my screen.

Use Variables as a Style Guide

We designers truly want to be open to feedback at every stage of the process. But it’s hard not to groan when responding to feedback means hunting through thousands of lines of CSS. Where’d you put that color? How wide was that column? Why is one button’s border radius refusing to change?

If you think ahead and define those properties in variables, making major visual changes is a breeze. You can define yourself a style guide that dynamically updates your entire site.

In SCSS, you define variables with $ signs. Once you’ve defined a variable, you can use it anywhere you’d use the text you’ve stored in it.

$orange: #f64212;
$subtle-light-gray: #efafef;

a {
	color: $orange;
	background-color: $subtle-light-gray;
}

Colors are only the most obvious way to use variables. These are all variables I’ve written in SCSS:

$orange: #f64212;
$help-text-size: .8em;
$total-width: 1024px;
$menu-width: 25px;
$main-content-width: $total-width - $menu-width;
$mobile-breakpoint-width: 468px;
$logo-height: 2em;

SCSS knows how to do math even with quantities that aren’t exactly numbers. It’s even smart about mixing units.

width: 11px + 2em + 50% + $menu-width;
color: $orange - rgb(25,14,14); // yes, you can do math with colors!

“Make the logo bigger”? No problem.

Mixins and Partials: Variables on Steroids

A mixin takes the idea of a variable one step further. It’s a collection of rules that you know you’ll want to reuse. I often use them for UI elements that appear frequently, like labels, tooltips, buttons, and dropdowns.

Define a mixin by using the word “mixin” and an @ symbol, followed by the name you want to call the mixin.

mixin @tooltip {
	border-radius: 5px;
	border: 1px solid $lightgray;
	background-color: #fff;
	box-shadow: 2px 2px 3px 0px rgba(20, 20, 20, 0.16);
	cursor: pointer;
	padding: 10px 19px;
	font-size: 90%;
}

 

Then include the mixin with the word @include , followed by the name of the mixin.

.onboard-tooltip {
	@include tooltip;
	color: $orange;
}
.premium-user-tooltip {
	@include tooltip;
	color: $darkgrey;
}

You could define these mixins at the beginning of your SCSS file. But if you have more than one SCSS file, copying and pasting variables into all your various files, you’re living dangerously.

Partials will help you keep your mixins and variables in one place. A partial is a snippet of SCSS that gets included before a file is compiled. To mark a SCSS file as a partial, give it a name starting with an underscore, such as _variables.scss . Then, to include it in your main file, write @import ‘variables’  at the beginning of the document. That partial will not get processed into CSS. Your file structure will look like this:

Partials are also great for chunking out well-defined bits of CSS, like my aforementioned 300-line navbar.

Are you processing locally or remotely?

The preprocessor can work its magic either on your local computer or on a server.

You’ll probably want to set it up on your computer, so that it creates an upload-ready CSS file right next to your SCSS file. If your processing is happening locally, keep the SCSS file and its compiled CSS together at all times. Upload them together, download them together, and if you delete one, delete the other. (And, if you’re using git, add the CSS files to .gitignore.)

You will also want to protect your computer by a VPN (virtual private network). I suggest looking up some VPN ratings and see what would be best for you.

If your workplace is technical, you may have a preprocessor already installed on the server, so that this conversion happens after you upload your files, not before. Ask around if you think this might be the case.

Setting up your text editor

If you’re working locally, you need to set something to “watch” your SCSS file and, when you hit save, turn the SCSS into matching CSS.

Coda 2:
Install this plugin, and any .scss files you create will be automatically compiled to a .css file of the same name in the same folder whenever you save the file.

Sublime Text:
This is a little trickier; there’s no one add-on that does it all. Here’s how to get Sublime Text supporting SCSS.

Text editor not supported?

If you’re using Dreamweaver, BBEdit, or another text editor that doesn’t have a SCSS plugin or add-on, no worries. You can either use the command line, or you can use a standalone app that watches your SCSS files for you. At Sliced Bread, a lot of us use Koala (free). Other popular options are CodeKit ($29) and LiveReload ($9.99).


 

That’s it! A preprocessor does take a little time to set up, but it’s eminently worth it. SCSS took me 30 minutes to figure out, but it saved me hours in the first month I was using it.

The one downside? I can’t live without it. On the rare occasion when I do need to write vanilla CSS, it feels like I’ve downgraded from a Tesla to a Buick LeSabre: slow, unattractive, and retro (not in a good way).

So, make your next CSS file a SCSS file, and join me in writing faster stylesheets – let’s make time for the fun part of design.

Be Experiment Smart

| 01.30.2014

Experimentation has hit the mainstream. It’s become de rigueur to sprinkle references to “A/B testing” into job descriptions, business plans, and company websites. But let’s look past the buzz for a moment. How you experiment is as important as whether you’re experimenting. Productive experimentation means picking the right experiment for the right phase in your project.

I’m teaching a class at the Stanford d.school this quarter that’s all about experimentation: we’re calling it Prototyping and Rapid Experimentation Lab. Along with my co-teacher Pam Hinds and our course assistant Nik Martelaro, we’re helping advanced design thinking students learn their way around how and why to experiment.

There are two core principles at work here. First, test any idea that you’re considering with as little commitment as possible. You want to learn on the cheap, before you’ve invested a lot of time and money going down the wrong path.

Second, experiment along multiple axes. You’ve heard of “A/B testing” – but there are many, many kinds of A/B tests. What exactly are you hoping to learn? You need to know how your idea stacks up according to these dimensions:

  • Interest – would people want this?
  • Use – does this solve a real need in a way that people want it solved?
  • Usability – is this easy, sensible, and efficient to use?
  • Implementation – can this be done?

 

I’m borrowing from some ideas proposed by Houde and Hill in their seminal paper for search engine optimization What do Prototypes Prototype? (1997), and giving these ideas a spin to be more relevant to what and how we design today.

Here, I’m focusing on the first three axes (interest, use, and usability). Keep in mind, though, that you’ll eventually need to launch experiments about feasibility as well.

Let’s take a look at each axis independently to understand how to dive in.

Interest: would people want this?

Asking people “would you buy this?” is not going to give you an accurate sense of what they think of your idea. You need to be sneakier about assessing their interest for like best waist corset. Create a situation where somebody happens upon your idea passively, and let them tell you whether they’re interested in this first taste. This is a great place for quantitative data – you want to prove objectively that there is enough potential to push forward.

Advertising

Run an ad (or several) and see if people click. Try Google ads, Facebook ads, or ads on community sites that your target user might visit (a foodie message board if your product is for restaurant diners, say). If you’re feeling especially sly, start chatting about the prospective product in forums where your users hang out and see what people think!

Landing pages and painted doors

To get more detailed feedback on your concept, link those ads to an actual landing page that describes your concept and link the ad described above to it. Create a button or other affordance on your site that is a doorway to the functionality you’re considering, but don’t build out the functionality yet. Gauge visitor interest by tracking page views, clicks, and/or sign-ups to learn more.

These quantitative approaches will show you what’s not working, but not why. For more qualitative feedback, go to a cafe (or wherever your potential users hang out) and show your design around for some quick guerilla feedback.

Create content

If your idea has to do with a certain kind of content, try starting a bare-bones blog, twitter feed, or pinboard. Driving and observing your traffic will teach you a lot about what readers are interested in. For example, if you’re hoping to make an app related to vegan eating, you might experiment with recipes, photos, restaurant reviews, travel guides, and nutrition advice, just to see what seems to catch on. Alternatively, try Hidden Radio’s approach – submit a description of your product idea to a well-trafficked blog and see if people seem interested. The team learned, in a week, that they’d hit on an idea worth pursuing.

Us or them?

Create a landing page for your product. Show your product to users, then show a competitor’s product (switch up which product you show first). Ask people to compare them. Which do they prefer? Which do they think looks most practical, most fun, most valuable?

What about surveys?

Surveys are notoriously poor at gauging interest. They can work well for getting factual, quantitative, objective data about real events (as long as respondents don’t feel social pressure to pick a particular answer). But you can’t learn much from a survey if you’re asking open-ended or hypothetical questions – people will say yes to anything. If you must ask a survey question about a nonexistent offering, create a quick prototype and ask about people’s reaction to the prototype.Web Design located in Southend, Essex were recently awarded with the best website design company.

Use: Are we solving the right problem?

So people are interested in your idea, and you’ve built a prototype. Now you need to figure out if you’re really solving their problem – and if you’re doing it in a way that makes sense for them.

Testing in context

Your product doesn’t exist in a vacuum. To get a sense of how context impacts how people use your product, build a prototype using one of a million tools out there and test it in context – or fake the context as closely as you can for testing purposes. For example, say you’re making an app that helps people troubleshoot their internet at home. To test it in context, you might start by instructing your user to do something engaging on the internet. Next, you, the tester, could artificially cause the network to fail, and see if your user can successfully use your product to fix it.

Wizard of Oz (WOZ) Tests

WOZ tests use low-tech workarounds to make it look like a computer is doing work. Create a working front end, but then set up a human-powered kludge for the backend. If you’re building an experience for online takeout, build the interface, complete with “place your order” button – but have people behind the scenes call-in orders to restaurants. You’ll learn a ton about your product without investing time or money in an order automation system.

In her book UX for Lean Startups, Laura Klein describes how Airbnb used WOZ testing: they had a sense that better photos increased a rental property’s desirability, so they hired a few pros to take photos of a few selected properties. The properties with the professional photos did much better – so much better that Airbnb now offers professional photography as a free service to people listing properties and has an automated backend to support it. A web designer Miami guru cleverly re-purposed this very tactic to cater to his existing real estate agent clients with great success.

source: airbnb.com

Usability: Can people use it?

After interest and use has been assessed to determine if you have a good idea to being with, you can start to “debug” your prototype. What’s unclear, what’s hard to find, what needs tweaking?

Moderated usability testing

I’m sure you’ve seen this technique before: make a prototype, ask people to complete a task using your prototype, and see if they can do it. If they can do it, congratulations – your prototype is easy to use. But don’t forget to test its usefulness as well as its usability. I’ve seen plenty of products that are beautifully simple, exceptionally clear, and completely pointless.

At Sliced Bread, we conduct a variation on the classic usability test that we call a Fast Insight Test. We usually run 3 to 5 tests of around 30 minutes each, and we test early sketches, not just finished prototypes. These quick tests give us a treasure trove of information, without all the expense and overhead of a usability testing lab (we often test in context or through screensharing) or a long study. Often we squeeze even more value out of tests by iterating between sessions, or even on the fly. For more info on how to do it yourself, see our previous post on Fast Insight Testing.

Unmoderated usability testing

A whole industry has sprung up around automating user testing. You’ll have no trouble finding a service that will recruit users and run them through a task for you, then give you results: try Usabilla, usertesting.com, Mouseflow, Five Second Test, or Loop11. These tools will help you gather quantitative feedback on the usability of very specific aspects of your site. They’ll show you where the fire is, but not why it’s burning.

Now go out there and do it

There’s a lot of subtlety to experimentation, but at its core, it’s about doing. Whether you’re looking for information about interest, use, or usability, you can frame an experiment to help you out – you can get started this very afternoon. In my next post, I’ll talk more about how to develop the questions and hypotheses that drive a good experiment.

Why I Hate Paper Prototypes

| 09.16.2009

Ok, maybe hate is a little strong. Paper prototypes and sketches have their place in interaction design. For example, they’re great for helping to quickly brainstorm various different approaches to a problem at the beginning of a design process. They’re also a very fast and cheap way to illustrate a new idea, since most people can draw boxes faster than they can build interactive prototypes. But, in my opinion, they have several serious drawbacks.

Before I get too far into this, let me define what I mean by a paper prototype, since I’ve heard people use the term to refer to everything from sketches on actual pieces of paper (or cocktail napkins in a couple of cases) to full color printed mockups with a polished visual design. In this instance, I’m referring to a totally non-interactive screen, mockup, or sketch of any sort of application that is meant to be shared with customers, test participants, or team members. It can be printed on actual paper or shown on a computer screen, but whatever the viewer does to it, a paper prototype is not interactive.

So, what don’t I like about them?

Screen vs. Paper

This first couple of peeves apply to screens that are actually printed out or drawn directly on paper. With a few exceptions that I’ve listed below, I’ve found this approach to be really counterproductive.

Iterating On a Design

One of the biggest problems with hand drawn sketches on paper has less to do with user interactions and more to do with my work flow as a designer. Sure, sketching something quickly on a piece of paper can be quick, but what happens when I realize that I want to swap two sections of the screen? I can draw arrows and lines all over it, but that gets messy pretty fast. Whenever I want to make any changes to my design, I need to create a whole new sketch. This can mean redrawing the entire screen quite a few times.

If I’m creating a design in HTML or any other prototyping tool, the very first version might take a little longer than a quick sketch, but the second through nth iterations are a whole lot faster. And, as a bonus, I can check them into source control, which means I’m a lot less likely to lose my work than if I have dozens of pieces of paper scattered all over my office.

Interacting With Paper

Whether they’re sketched out by hand or printed out on paper, people interact with paper screens differently than they do with computer screens. They view them at a different angle. They focus on different parts of the screen. They use their hands to interact with them rather than a mouse and keyboard. Any feedback that you get on a printed design will be colored by the fact that people are fundamentally interacting with it differently than they would if it were on a computer screen.

Given all of these drawbacks, there are a few situations when designs printed on paper can be used effectively:

  • You are at the very beginning of the design process, and you want to explore a bunch of different possible directions with other team members very quickly before committing yourself to fleshing out one or two specific options.
  • You’re designing material that is meant to be printed, like brochures, user manuals, books, etc. In this case, you want to know how people will interact with the printed media.
  • Your product is an interface for some sort of embedded or small screen device that would be very difficult to replicate in a quick interactive prototype. For example, a screen for certain mobile devices or the heads-up display for a car dashboard might be hard to show interactively in the appropriate context.
  • You have several different visual designs, and you’d like to show them all to users at the same time in order to see which one is the most attention-getting. You’ll still need to show the designs on screen, of course, since colors can vary so much between screen and print, but it can be helpful to lay out several pieces of paper so that the various options can easily be compared.
  • You need to share screens with people in an environment with absolutely no access to a computer whatsoever. You know, maybe you’re in the middle of a meeting and need to sketch something quickly, or the rest of your design team is Amish, or you are designing in a post-apocalyptic wasteland where the computers are trying destroy humanity.

On the other hand, if you’re designing desktop or web applications for standard computers, at the very least, show your prototypes on a computer, even if they are not interactive!

A few reasons why it’s especially important to show interactive designs on a screen:

Animations and interactions

I am an interaction designer. A big part of my job is to determine what happens when a user interacts with a product. Sometimes that’s obvious. For example, if I click on a link with some text that reads, “Contact Us,” I expect to be able to communicate in some way with the people who have created the product.

But is it so obvious? Back in the day when links could only take you to another static web page, sure it was. But now, all sorts of things could happen. I might have different behavior on hover vs. on click. I could be given the option to have a live chat with a rep. I might be presented with an inline contact form so that I don’t have to leave the page I’m visiting. The contact form could have some information already prefilled for me based on my present location or account type. There could be animation involved in displaying the contact information. There could be some sort of contact wizard that would change later screens depending on choices the user makes initially.

All these interactions are much harder to convey with paper prototypes than with interactive wireframes. Sure, you can make a different screen showing each stage of the interaction, but with anything more complicated than a few steps, your observers can get lost pretty fast shuffling through papers. Having it all working in an interactive prototype allows users to click through and explore naturally. They can also discover things like hover interactions or animations on their own, which are particularly unsuited to paper.

Testing

What? You don’t need to test your designs with users? Your designs spring from your brain fully formed and perfect? Well, good for you. The rest of us mortals actually like to show our designs to test participants and get feedback from people who aren’t familiar with the product.

Now, I’ve run a lot of user tests. I’ve run them with working products, interactive prototypes, pictures of screens displayed on computers, pure paper prototypes, and physical mockups of products. I’ve used prototypes built with everything from HTML to Visio to cardboard. The one constant was that the closer the prototype mimicked the final product interaction, the fewer problems we found once the product was built. And since we recommend iterative testing during development rather than waiting  to test until the product is 100% built (you know, just in case your design wasn’t entirely perfect the first time around), an interactive wireframe is the best trade off of speed for functionality.

Communicating the design

You can have the best design in the world, but if you don’t communicate it effectively to the engineers who have to build the thing, it doesn’t matter one bit. Of course, once you’ve designed all of your static screens, you could paste them into a big spec with extensive documentation about what each button on each screen does and how many seconds an animation is supposed to take and blah blah blah. I’ve done it when it’s been specifically requested by a client. I’ve also never met an engineer who was particularly happy to read through one of those three hundred page documents. Besides, just the thought of making changes to every screen in that document every time there’s a change makes me tired.

An interactive prototype, when built intelligently, is a different story. It allows engineers to see exactly how every element of the design is supposed to work. What happens when you click on a link? Click on it to find out! Is the animation supposed to sweep horizontally or vertically? Take a look! Of course, you’re free to add notes to screens as necessary to fully communicate absolutely everything, but the difference between using this lightweight approach and a full design document for reference is night and day.

What’s the alternative?

So, what should you use other than paper prototypes? I’ve mentioned it throughout the post, but I’ll be perfectly clear. Your best bet is an interactive wireframe that mimics the behavior of the actual product as closely as possible. It doesn’t have to be hooked up to a database on the back end or use real data. It doesn’t even have to be fully functional if you’re only testing parts of it or if you’re annotating it with notes. But it should make the user, whether they’re a test participant, an engineer, or your design manager, feel like they’re actually performing tasks with the product.

Luckily, you’ll find plenty of products out there that will help you build interactive wireframes with very little technical expertise. You don’t need to be an engineer or a Flash expert to make your screens clickable. My favorite tool is Dreamweaver for creating quick HTML prototypes with basic animations and interactions, but other people have had good luck with applications like Axure and or even PowerPoint (although, that has some serious limitations).

There is, of course, one quick caveat. I know I’ve been harping on how closely your prototype should match your eventual product. However, you do not need, and probably shouldn’t have until quite late in the design process, a full visual design for your interactive prototypes. Why is that? Well, I’ve found that making the visuals look too polished can actually focus the user on the aesthetics rather than on whether they can accomplish a task. A lovely or flashy visual design can distract the user from interaction problems that you’d rather find early in the process.

For best results, focus on creating a simple, clean wireframe with as much interactivity as you can possibly give it. Your users will thank you for it.

Balsamiq vs. HTML Wireframes

| 05.4.2009

Recently, I discovered a new prototyping tool for creating rough, sketch-style UI designs called Balsamiq Mockups. It’s basically a lo-fi mockup tool with a built-in library of sketch-style UI elements that can be easily dropped onto a workspace and edited.

After test driving this tool on my own,  I decided to see how Balsamiq Mockups sketches compared to rough HTML wireframes in the context of a user study.

First impressions using Balsamiq

mockups_fpa

After demoing the tool for only a few minutes, I thought, “Wow, nice job!” It was fun to play with, drop dead simple to use, and required no tedious application tutorials or programming knowledge in order to just dig right in.  I liked how quick and easy it was to drag and drop library items into the workspace and quickly adjust and rearrange them as needed.  After only a short time using Balsamiq, I could create simple mockups just as fast (if not faster) than I could in Dreamweaver, the tool I use most frequently for rapid prototyping.  I also found it very easy to export my Balsamiq sketches as static files and add interactive behaviors on top of them using hotspots.

However, the real strength of Balsamiq comes from the fact that the tool does not simply emulate other prototyping tools that make realistic-looking mockups (such as Visio, PowerPoint, GUI Design Studio,  and MockupScreens). Instead, Balsamiq takes an entirely different approach and deliberately uses a rough, hand-drawn look and feel — presumably to better communicate that these designs are just early ideas in-progress and are not fully fleshed out yet.   I hypothesized that Balsamiq Mockups would be especially good for communicating early design concepts, to keep users focused on the high-level ideas, rather than on the details.

Balsamiq vs. HTML usability test

To test my hypothesis, I conducted a comparison study to find out if the sketch-like quality of Balsamiq mockups had any effect on the type of feedback that users provide in the context of a study.

The research process

For the study, I used an A/B test format. First, I mocked up the same high level design using two different methods:  version one was created in Balsamiq, and version two was a very rough, grayscale, HTML wireframe created in Dreamweaver.  Then, I showed half the participants the version one Balsamiq sketch;  the other half of the participants saw the version two HTML wireframe. (See images below with text blocked out for client IP reasons)

Version 1: Balsamiq sketch

balsamiq_lorem

Version 2: HTML wireframe

html_lorem

In both cases, I told users to share their initial impressions about the design. I explained that the designs were still a work-in-progress and I was looking for high-level feedback regarding the concept and overall functionality, rather than the specific language, details, or look and feel of the page. I then noted their feedback to see if there were differences between the two groups.

The results

All participants were able to provide high-level feedback about both types of mockups. However, participants who saw the Balsamiq sketches were slightly less concerned with the details and specifics of the design. They tended to comment less on the colors and appearance of the design, as well as the particular language and text used.  They were also more aware of the fact that they were looking at an in-progress design, making comments such as, “I don’t really like the way this dropdown menu works, but know the design for it might change later anyway.”
In both cases, users still made comments on specific page interactions, but the Balsamiq participants were more likely to be aware that this type of feedback was overly specific, as one participant qualified his feedback by saying, “I guess that’s not really the kind of feedback you’re looking for right now.”

Overall, I found that the participants who saw the Balsamiq sketches did a slightly better job of keeping their feedback more conceptual than the participants who saw the HTML wireframes. However, participants in both cases still commented on some of the details of the mockups as well, and it was necessary to use the moderator questions to guide the user’ focus and attention back to the level of feedback I was looking for.

Conclusion

Balsamiq Mockups is a useful new prototyping tool. It’s perfect for sketching quick ideas and sharing with others, especially if the mockups are fairly simple in layout and overall complexity. It’s also a great tool for concept testing with users, as the sketch-like quality of the designs works well for gathering high-level feedback on initial design ideas.