ZURBlog is where we discuss product design, business and strategy.

Our friends over at Human Factors International recently posted a great video on the six steps to persuasive product design. Take a look at the video below and notice how those steps can get your users to act on your call to action and take that next step:

What Eric Schaffer is taking about it is a more holistic approach to product design. Let’s take a closer look at Eric’s six steps:

1. Understand our users’ emotional battles. We need to understand our users’ drives, blocks, emotions and beliefs at key conversion points. Interviewing allows us to delve deep into our customers, learning if they are elephants, deers or rabbits. Even a quick conversation can help us understand the blocks that prevent users from taking those next steps.
2. User insights. Collecting insights from a bunch of customers can reveal the stronger issues at work, such as fear or guilt. That’s where thorough user research can be immensely helpful. Nate Bolt gave an amazing soapbox talk on the importance of user research in product design. Check out the transcript and slides of his soapbox here.
3. Pick an emotional strategy likely to work. Product design shouldn't ignore the power of emotion to drive engagement. Designers can even use the seven deadly sins to generate momentum among users.
4. Create a frame for the theme. Focus on a theme, creating a framework or meme for it. This can be central to your product or products. For instance, our apps are centered around the idea that you can design great products faster. In other words, we need to understand the what, why, who and how of our products.
5. Methods of influence. Along with creating a framework, the method of influence, such as testimonial or scarcity, is crucial to communicating the theme. What is the method that’s going to best evoke a user’s emotions? After all, numerous studies have highlighted how emotions drive our decisions.
6. Study the flow of interactions. We have to study how users move through all the interactions through to the very point of conversion. Think of it this way: What grabs a user's attention? What sustains a user through the interactions? Is your call to action clear? Does it give the user that emotional push to take the next step?

These six steps, however, aren't a one-time thing. This is an ongoing process and doesn’t end once a product is launched. Keeping in touch with regular users can key you in on when there is a breakdown of any of these steps and where you might need to reevaluate your approach.

The smartphone as we know it today is not a phone. It's one of the earliest, but clearest, examples of human augmentation through technology.

Think about it. 83% of young people sleep next to their phone. Generationally, we always have them near us or on us. Through them we are, constantly and wirelessly, connected to almost anyone we choose. We can talk by voice, by text, by video. We can find out what's happening in our social circle, or around the world. If someone asks us a question, we can almost always provide the answer. We are smarter, funnier, more interesting and more connected with these devices than we ever could have been in the past.

If you don't think that's a sea change for society, you're blind.

Heads Up, The Future Is Coming

The future is creeping around the corner, and we could be wearing it on our faces. Google's already on it with its augmented-reality glasses. The video below gives us a sneak peek at the future as seen by Google:

While they're only being tested (and the video example seems more like fantasy than reality) the sheer fact that wearable heads-up displays are something we can actually create now is astonishing. Look up, and see who wants to meet you, and where they are, and how to reach them.

On this blog and throughout our publishing, speaking, and design efforts we talk about how we're in a multi-device world. We are, but not for long.

Image via Google

The devices themselves are already evaporating, ready to be replaced with more and more integrated means of interaction and data display. Siri is an example of this — a means of communicating and computing that has no screen component requirement at all, and these (possible) Google glasses are the newest example of human augmentation.

The time is coming when we'll all have to design for the ubiquity of data, and design interfaces that are much more natural to access it. The Web is almost entirely a visual medium, tied to screens we surround ourselves with. Just look at how quickly technology is moving and ask yourself, in a few years will we be tied to a purely visual medium? Almost certainly not.

Google's Project Glass is fascinating, even if it is a new way for us to run into things or fall down stairs. When you're thinking about your products, think about how they'll interact with something like a heads-up display, or an audio interface. These things are much closer than most people think.

Last week, we highlighted our objection to UX design as a discipline. It's not the first time we've been defiant in our cause. That's caused many people to ask, however, "what do we stand for?"

If you recall from our previous post, most of the examples of solid design work could be summarized into a few general ideas:

• Prototyping and building things — not documenting or "strategizing"
• Rapid iteration — working through the problems with tangible products
• Building strong teaching cultures — successful products requires design literacy
• Project inspired, not project managed — great products happen in-spite of project managers or program managers
• Loose contracts or specs — design thinking requires flexibility

ZURB over the last 15 years hasn't spent much time worrying about how to shape our industry — instead we kept our heads down learning and practicing with our clients and customers. And the funny thing is, when you look at that summarized list, ZURB has been preaching those exact principles from day one. Even as a consulting practice.

There are limitations, however, with being a consultant and having a lasting impact with the companies we help. However, instead of looking at our services as insufficient, we decided to chart a course three years ago that brought together a complete solution to help our customers succeed. At the time, I'm not sure many of our employees believed we could truly pull it off. Today, we have expanded our efforts to include products, events and publishing — all to help our customers design great products faster. Now more than ever, design companies now need to be even more invested in their customers needs.

Helping People Design for People

Our purpose remains constant: Help People Design for People. When you put the needs of users first, the business goals often magically fall into place. It's not a tradeoff, but a healthy exchange of value.

Early in my career as product designer of toys, I learned successful hits couldn't be predicted, but they almost always had some combination of delight and crowd backing. An aha moment. The perception of value was important, but not always grounded in beneficial "features." The experience couldn't be predicted, but the principles of good product design, which have been around nearly a century, could still be applied.

When I started designing websites in 1998, I took most of the same methods I had honed in school, and applied the techniques to web development. It wasn't a perfect match, but I found that approach set ZURB apart from all those designers that came from graphic design backgrounds. At the time, calling myself a product designer seemed a little out of touch with people who just wanted a website.

But as the years have passed and more people have become aware of the business value of design, it's become apparent that solving an interface problem on a tablet or phone truly is a product design problem. It's no longer just a desktop screen and the form factor of the actual device is rather secondary to the interface. Companies can no longer easily justify focusing only on desktop interfaces. We have to prepare for the future.

Product Design is the Future

The next 15 years should be just as exciting as the last 15. At ZURB, we've committed ourselves to challenging the status quo, whether it's releasing an open source framework for multiple devices or building product design apps that even a marketer or executive could use. We're committed to furthering the discipline of product design and we think it's important to study the lessons history has taught us.

So in so many words, we're all in with product design.

In this blog post on the subject of ux design, we were blasted by a group of people suggesting that we were committing heresy by even suggesting the term doesn't mean anything. We've been steadfast in our view that user experience design isn't a discipline at all. I believe more people will start to see the problems with trying to form a career path based on the end result of successful design work. Heck, even Peter Merholz gave us validation, and he's been a practitioner of user experience for over a decade.

So why bring this up? A recent thread on UX clients services by Ryan Freitas had us chatting around the office. The question he raises:

How well has the UX client services model adapted to the way products are built today?"

Now if you don't actually believe UX design exists, it's a funny question to ask. But given that smart people are answering, including Peter, it's apparent that the conversation comes full circle to what successful product companies have been doing for decades. Such as:

• Prototyping and building things — not documenting or "strategizing"
• Rapid iteration — working through the problems with tangible products
• Building strong teaching cultures — successful products requires design literacy
• Project inspired, not project managed — great products happen in-spite of project managers or program managers
• Loose contracts or specs — design thinking requires flexibility

The discipline of design is complex and a bit vague — but it's that openness that allows great product teams to make amazing things happen for people. It's both a noun and a verb, and can't be looked at as simply a result or a process. Product design does require creating tangible results, though, and those people who can influence the final result with good old fashion elbow grease will get an upper hand in shaping the vision of a product.

The user experience is a shared responsibility of all those who contribute and support a product. Modern product design has been around for centuries, and successful products have come in droves without the need of a person or group of designers responsible for the customer or user experience. It's a shared responsibility.

So can we just drop the term? That or I'm going to call our controller, UX controller. She does a great job collecting money.

When author Harlan Ellison would get asked where he got his ideas, the award-winning writer would joke that he’d send a check to a little shop in Schenectady, NY. In return, the shop would send him a fresh pack of six ideas. Joking aside, truth is that writers, like designers, get their ideas by paying close attention to the world around them and seeing what others are doing.

But as more and more companies turn to design to grow into different markets, different avenues, it can be exhaustive to churn out idea after idea. No longer does it become just about generating a billion ideas. It becomes more and more about narrowing in on the right idea. Finding exactly what matters most to people, what solves their problem.

So how do designers hit on that idea? How do they ferret out the gem among a stack of coals? How do they get the confidence to get it right and keep from being paralyzed by fear of getting it wrong? The real challenge to those questions is trying to solve the human problem, according to this video by the folks at Continuum, a design strategy firm that works on everything from industrial products to household products like coffee makers. Check out the video below and watch how the designers narrow down on the right idea:

Notice how the designers in the video use many design methods in their hunt for the right solution, such as brainstorming, sketching, and interviewing. They even collaborate along the way, exploring dozens of ideas together to get to the right one. That being said, let's take a closer look at three points from the video.

1. Understanding users’ needs and values. User aspirations tell us more than past product choices, the video points out. It’s not enough to know just who our potential users are. What separates a great designer from one that just moves pixels is the person who delves deep into the drives, beliefs, feelings and needs of their users. If not, the consequences could be dire. Remember Josh Levy and Ross Cohen, co-founders of BeenVerifed, who burned through $550,000 in funding without getting a single customer? That’s because they spent months developing a product that didn’t have a market, that nobody wanted to use.
2. Getting ideas quickly into the wild. Tinkering with a prototype gets the idea out into the wild quickly, so we can user test and refine the prototype. More than that, putting work out in front of would-be users as soon as possible can prevent a lot of heartache in the end. Take Google Wave for instance. Sure, it was a pretty technically impressive application, but it was a big flop. That’s because Google didn’t learn how users would respond to Wave before they released it.
3. Good design strategy is actionable. As one designer says in the video, sometimes things that are called design strategy actually end in user insights rather than ideas. The key is turning those user insights into meaningful action. Take for instance our work with Borealis, a software company for managing environmentally responsible oil and gas projects. Insights from frustrated users led us to the actionable idea of centering the application around the users' profiles. More than that, we struck upon the idea of mini-apps that were easier to build, maintain, and would excite users.

Getting to the right solution to a human problem requires deliberate practice, digging deep into the problem, asking tons of questions and sifting through dozens of ideas. It requires understanding users inside and out. By doing so, designers can strike upon the right idea without fearing they'll end up with a flop.

Remember how yesterday we told you about refining your designs in-browser quickly? Well, that was only part of the story ... really, the tail end of the story of how we used Foundation to code up a prototype in the browser for our new ZURBword front page. Take a look at our old page:

As you can see, there wasn't much to look at. It was nothing more than a directory, a list of words with not much going on. We wanted something a bit more eye-catching that would encourage people to click around and check out our thoughts on some hearty design concepts. So around November last year, we started sketching out some ideas to take the site to the next level.

But did we want to take those ideas and put them into Photoshop? Or did we want to go straight to code, designing in the browser? A lot of designers debate whether they should design in browser or not.

However, the one big advantage to prototyping in the browser is that it's faster, trimming off several steps in the design process, especially if you already have an established visual style. Since we wanted to get the new ZURBword up as fast as possible, we decided to prototype it in the browser.

Getting It in the Browser

We started playing with a few ideas, trying to figure out what would actually work. Take a look at some of our early ideas below. Click on the images to see a larger image.

Here we lost a bit of focus on the content. There was too much line work going on and everything felt too structured and boxy. Overall, it felt too much like a beefed-up directory. So out these ideas went and it was back to the drawing board.

Playing around with the lines and images, however, we came up these next set of images. Take a look (click on the images to see a larger image):

The design on the left, however, felt too forced, an island of stuff in a sea of text. The one on the right broke things up, which was kinda awesome. But there was that darn line problem again. Everything felt trapped, contained too much. However, we played even more with the blocks of content seeing where it would take us.

Our exploration led us to the designs below. Click on the images to see a larger picture:

In the end, we did something like 10 iterations to get to our final design. But we weren't quite done yet.

Refining Our Design with the Inspector

As we said yesterday, we refined our designs by opening up the Chrome inspector. In less than five-minutes, a group of us, including myself, were able to quickly critique the design and suggest changes, which the inspector let us see instantaneously. We were able to change the background from white to gray and even add a drop shadow to the boxes.

We also reversed engineered Foundation to add a couple more columns on the side for wider screens. One other nifty touch was having the images rotate each time you land on the front page.

With those final changes in place, we were able to launch shortly after that. All in all, it took us a few weeks to get the new ZURBword up and running. And all thanks to in-browser prototyping.

Our days can be pretty busy at ZURB. Sometimes we don’t have time to stop everything and do a full-blown design critique. Sometimes we just want quick and dirty feedback. That’s where in-browser prototyping comes in handy, especially when we’ve got a design that’s nearly there but not quite there yet.

In-browser prototyping came in handy while we were putting the finishing touches on the rebooted ZURBword. The original site wasn’t up to snuff. So we put Arthur to work on a swank redesign. As he got closer to the final design, four of us huddled around Arthur and his computer, giving him a speedy design critique in about five minutes. To do it, we simply opened up the Chrome inspector to see some instantaneous changes. How we did it is something we wanted to share with you.

Getting Dirty with Chrome Inspector

The original white background of our nearly-complete page wasn’t quite working. So Bryan suggested using gray. That’s when we opened up the Chrome inspector, searching the left-hand DOM for the body element. Take a look (click on the image for a larger view):

We then went into the right-hand style box and started fiddling with the CSS, changing the color of the background. Click on the image below to see a larger picture of what we did:

Next we decided to add a drop shadow. So we moved in the DOM to the class we used for each of the containing boxes, to find the box-shadow in the style-box, double clicked on it, changing it to “0px 2px 5px rgba(0,0,0,0.15)” to add the shadow. Check out the larger image of what we did by clicking the image below:

Not An Excuse for Backseat Design

The changes only stick around as long as you don’t reload the page. Once you reload the page, the changes will vanish. So you’ll have to go into the actually CSS to make the changes permanent. Take for instance the box shadow, we used CSS3 to make it permanent on the actually code. (So that particular change might not show up on older browsers.)

In any case, in-browser design critiques aren’t an excuse for backseat designing. It’s meant to be really quick, really dirty so you can be scrappy and prototype your ideas instantaneously.

Spacing in visual design is crucial. Too much space and it looks like you could drive a truck between the text and pictures. Too little and it seems that everything is just smashed together haphazardly. But we have a little trick around the offices at ZURB that makes sure we get the spaces just right.

There are several tips and examples of why spacing is important. So how do you make sure everything is laid out on the page correctly? Anthony, one of our designers, usually fixes the spacing on visual designs by creating equally-sized blocks in Photoshop and placing them in the gutters, kinda like a Gauge block for visual design.

It’s a trick our designers use. So we thought we’d take you through the trick to show you how to make sure everything is balanced.

A Quick And Dirty Way To Reduce Visual Noise

When laying out a visual design, the first thing we do is put in all the content — text, images, etc. — where we think they should go. However, things aren’t quite finalized yet. This is quick and dirty, and things are unorganized and all over the place. So we have to start playing with the spacing, evening things out.

A 40px block being used to check the spacing between text.

First, we space blocks of content out. Usually, we start with a bigger block, say a 40px block. We take that block and use that to even out space between one section and another. By having a number of equal-sized blocks, you just put them in all the gutters and can quickly see what the spacing is like.

A 20px block near a 40px block.

We can then use multiples of that 40px block, halving it into a 20px. This lets us even out the spacing for places that need less space. However, we don’t have to limit ourselves to just using multiples of a larger block. We can use different blocks, say a 15 px or a 30 px or whatever. But don’t go crazy and start using a whole bunch of different blocks. If you do, you could find yourself with a very lopsided design.

Balanced Look and Feel

These blocks are extremely helpful in giving a design a balanced look and feel. Better still, it’s a quick and dirty way that makes sure there’s very little visual noise that becomes noticeable when the spacing doesn’t feel right.

The trick has worked so well for us that Anthony thought it'd be pretty neat to have a similar feature in Spur. So now it's possible to grab a design, slam it into Spur and use blocks to check out the spacing.

Check Out The Spacers on Spur

Amazon is really pushing the Kindle and when you go to their homepage, the Kindles are front and center with the Kindle Fire being the most prominently showcased. But have you actually looked at a Kindle Fire? It's not exactly easy to use. So when it comes to usability, the Kindle Fire just plain sucks.

Jakob Nielsen recently trashed the Kindle Fire’s usability, calling it disappointing from a user standpoint. Here are a few of its faults:

1. The browser is awkward and not at all easy to navigate.
2. Buttons are too small for fingers to easily click on, leading to a lot of tap errors.
3. Reading magazines are tough to read and flip back between pages.
4. Lack of a home button and up/down volume button when using apps or browsing the web.

Yet the Kindle Fire is on fire, selling like hotcakes. Millions were sold last year. What is about the Fire that makes people snatch them up? If it’s not usability, then what is it? We all know usability is important, but it seems Amazon has gone beyond that. They’ve managed to tap into the drives, emotions, and beliefs of their users. As Eric Schaffer, of HFI International, explains in the video below, the Kindle Fire is solid proof that usability is not enough.

This is something that's been brought up by Simon Sinek in his book "The Power of Why." When it comes to our products, most of us tell others what it does and expect others to buy it. This doesn't work. Sinek says that every inspiring leader from Martin Luther King Jr. to companies like Amazon is that they think and talk the same way. They start with asking “why.” The Kindle Fire is proof of this.

By asking and answer why first, Amazon has managed to convert people into thinking that they need a tablet that isn’t just a book reader or movie viewer, but that’s a portal into the world.

Over the years, there has been a jihad over whether to use spaces or tabs when writing code. It’s a holy war we fought ourselves at the ZURB offices, until we came up with a truce in 2009, saying spaces were for back-end development while tabs were for front-end development. But recently the war was reignited and we found ourselves fighting it out again over whether to use spaces or tabs.

The problem is that a lot of hackers are insanely passionate about the amount of screen columns that the code indents, as pointed out in this excellent blog post. Some prefer it to be two column while others like it to be four columns. Then there are the folks who prefer more complicated and context-dependent rules.

At ZURB, we had hackers on both sides of this battlefield — some for spaces and others for tabs. Spaces, however, slowly took over. Code kept getting written with spaces, and the backend folks mostly ignored the truce. However, the war heated up again when Tanya used tabs for some front-end code, which piqued the ire of our contractor, who fired back and reformated the code manually with spaces.

So we decided to put an end to the war once and for all, and make everything consistent all around with spaces, but not before delving deeper into the problem.

The Problem with Tabs

Because most arguments on the subject were esoteric, we asked our contractor why the tabs were problematic and why spaces are better.

Tabs wreak havoc, he told us, because they’re so wildly different on different editors. On some editors, tabs show up as two spaces, on others it shows up as four spaces and on a few editors tabs will actually show up as an entirely different character, he said. With a multitude of editors and hackers, these differences can cause some pretty whack alignments.

It gets even worse if you mix spaces and tabs while coding. Your code will only look good on your editor, but could look like crap on another editor. Here’s the example our contractor gave us:

Say we hacked this using two spaces for the div open and end tags, then used two tabs for the span tags, it could end up looking like this in an editor that interprets tabs as four spaces:

So, yeah, mixing tabs and spaces is bad, way bad. Don’t do it.

Spaces for the Win

As you can see, there’s no real benefit to using tabs over spaces because of the inconsistency of tabs. Around ZURB, spaces won because they're more consistent with the communities we work with and admire, such as Rails and SASS. However, whether you use spaces or tabs, the key is to be consistent so you don’t end up with some funky code that you’ll have to go back and reformat.