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

ZURB has, at any given time, between 12 to 15 clients. On average, we end up creating wireframes for probably ... um, 90% of those. It's a lot of wireframes, roughly 2,200 a year between the entire team, and not counting internal projects. Yeah, you could say that wireframes are important to us.

We've even written about wireframes before, including why we wireframe at all. We've also written about some of the tools we use, especially the very excellent Omnigraffle (read more about Shared Layers in Omnigraffle and Omnigraffle variables). However, we've seen a tectonic shift ocurring in how we wireframe, in large part because of Foundation, realizing that we can't wireframe the way we used to as designers.

Traditional Wireframes Are Dead

Or as close to dead, as it makes no difference. Here's the problem with traditional wireframes:

• They give no sense or insight into flow.
• They have to be created at various different screen sizes to account for how customers will actually see them.
• The client won't see them in their native element. The context is wrong.

A recent hi-fi wireframe we created for Venyu

These aren't new issues with wireframes, and there's a few ways around them. You can link wireframes together into a flow using something like Powerpoint/Keynote or just image maps in HTML. You can make wireframes for desktop and phones and hope that that's enough to get a good idea of how something will work. And you can try and make wireframes look and feel like the way they'll really be seen. But all of that is half-assed at best. We need some new hotness.

Coded Wireframes FTW

For several of our recent clients, we've been creating what we call coded wireframes. The idea of coding up your wireframes isn't terribly new, there've been rumblings about it for a long time, but with the rise of rapid prototyping frameworks (most notably Foundation, of which we're rather fond) it's feasible to do it in the kind of time constraint we typically have with our 12 to 15 clients.

Coded wireframes are possible through a few functions, most of which are in Foundation, but some of which can be pulled in:

• The responsive grid in Foundation lets us very quickly create complex layouts that work on almost any device.
• Foundation's mobile visibility classes let you tailor the interface and experience for users based on the kind of device they're on. Very handing for moving around nav, changing the order of content, etc.
• Several plugins like Orbit and Reveal help us create modal dialogs and image/content sliders without having to muck around in JS.
• Services like placehold.it give us an easy way to drop in image placeholders to block out content. Just pass in an image source like "http://placehold.it/400x300" and get back a 400x300 image. Pretty sweet.

By those powers combined, we can create coded wireframes really quickly, and with a high degree of fidelity. The downsides are fairly minimal but should be mentioned — you don't have pixel-level control without a lot of extra effort, and adding in things like icons or less common widgets is not as simple as it is with the stencil libraries in something like Omnigraffle. We haven't found this tradeoff to be a problem. Now let's talk about what we do get.

Significantly Better Feedback and Iteration

We've always been hounds for feedback, but the feedback we get on coded wireframes is quite a bit better than it is on static screen. The client can get a feel for the flow and have a much clearer picture of how the final product will work, not just what it will look like or what functions there are.

Multi-Device Testing

We live in a world where your products need to work on almost any random kind of device. Static wireframes simply can't represent that kind of world, and coded wireframes absolutely can.

See one of our first coded wireframe projects, for last year's ZURBwired event.

Correct Context

Much of our impression of a service is colored by how we see it, and, in this instance, that means the device we view it on. The feedback we want will vary greatly depending on whether the user sees our work on a phone or a 30" display, and if they see it on the actual device with the affordances and restrictions it carries. Maybe tap areas are too small, or the layout looks weird on a large monitor. All things we want to know.

Try It!

It doesn't hurt to give it a shot and, at the end of the day, wireframing in code leads to a better product. The feedback is better, the feel is truer, and the final implementation is smoother. Download Foundation (or another rapid building framework) and create some wireframes by just hacking on the provided index.html, then let us know how it goes in the comments.

Getting stuck thinking about process is an easy trap for designers to fall into. Sure you'll solve problems, but without effective methods, those results will be … well, uninspiring. That's why at ZURB we focus on methods, not process.

Methods are the backbone of the design process. It's deadly tough to build products effectively without developing a few design methods first. Sketching uncovers interactions, brainstorming sparks ideas, critiquing pushes the envelope of designs, and analyzing discovers what people do with your products. Without these methods, we'd be a little lost.

Which is why we've pulled back a bit, digging deeper into our own design methods. We asked ourselves: Why does brainstorming get our ideas flowing? How is concept testing useful in gathering data? Why do we user test? More importantly, how do these methods help design better products?

It's not enough to ask these questions. We had to keep talking about these methods. We also had to write them down. By writing them down, we can continue to refine and shape those methods. We even went one step further and put them all in a place where we could share those methods with others who are working furiously to build awesome products.

Check out a few of the methods we've published by clicking on the titles below:

These methods aren't the only ones we use and we'll be putting more up soon. By either using these methods or developing methods of your own, you'll be able to build awesome products more effectively.

Well, it finally happened. Facebook dropped its IPO today. As predicted, the articles about how overvalued the company has become started pouring in. It’s interesting to see that even one year ago when we published a blog post asking the Influencers if they would buy Facebook stock many of the quotes and comments sided with the fact that the company is overvalued.

We we're chatting with Robert Scoble on IM today as the IPO news hit and he was rushing to put together his post about the new. He had a very different opinion:

It's undervalued, very undervalued. They have significant revenue engines that are not operating yet. Mobile hasn't turned on at all. And they are expected to build a new kind of advertising for Open Graph developers. I can see them worth a half trillion by 2015.

Comparing this comment to Rand Fishkin, CEO and Founder of SEOmoz, exactly one year ago:

I'm generally on the side of Warren Buffet (and common sense) in these matters. When everyone else is excited about Facebook it's a great time to sell; when they're down in the opinion polls, it will likely be a good time to invest. They are certainly an exciting company and they make an incredibly popular, world-changing product. The issue with buying their stock, however, is not whether these facts are true, but whether the market believes them to be even more exciting than they really are. To my mind, that's almost certainly the case.

Are they overvalued at $100B currently? Are they significantly undervalued? Will they be worth a half-trillion dollars soon? We had a bit of a discussion here at ZURB after the news hit, half a trillion seems like an insanely large number for Facebook, the display advertising market is growing, but not at such exponential proportions. That’s what it seems like to us at the moment anyway. We’d love to know what you guys think. Is Facebook overvalued? Undervalued?

Editors Note: This morning (2/2/2012) we received a follow up from Rand Fishkin, CEO of SEOmoz commenting on the news and his quote from last year which we mentioned in the article. Below is what he has to say:

If we're talking about the 409A valuation from December that put shares prices at $29.33, then no, I don't think they're overvalued. A professional valuation firm performed that, and they tend to be on the low side to benefit employee stock options. As an example, at the beginning of 2011, SEOmoz received a 409A valuation in the $10mm range, but had a buyout offer at 4X that (which we still thought was low) right around the same time.

If we're talking about the IPO price - to my knowledge, that hasn't yet been announced, so very hard to say whether that will be over-valued. The company certainly has massively impressive revenues, profits and growth.

As product designers, we've been conditioned to figure out who our users are, and rightly so. After all, it's a waste of time and money to design a product without figuring out who will use it. But are we spending too much time on users that we're forgetting someone else?

Consider this. You build an awesome product, you launch it, and then wait to see what happens. You know your target demographic will adopt your product, but what about those other people who'll see it — like the early adopters who try a product and aren't likely to become long-term users? We're talking about the journalists, bloggers, marketers, and product junkies who will spread the news, who could easily make or break your product. That's because they are the most vocal with their opinions. So how would you want them to talk about your product?

As pointed out in this video from the folks at Penny Arcade, these "unintended users" can help transform an industry. Check out the video below, noticing the issues that game designers face when it comes to designing with these folks in mind:

Let's take the idea of a spectator from the video a step further. A spectator can also be seen as a potential customer. Someone who comes into contact with a product briefly, observing how it works, and may even take it for a spin. With that in mind, let's take a closer look at a couple points in the video:

1. Accessibility. As the video points out, spectators want to understand how to use something, even if they aren't necessarily at the helm. They want to know the rules, even if they don't intend to play themselves. Another way to think about it is communicating your core value clearly.
2. The human touch. As seen in the video, spectators are in it for the human touch. In the case of spectator sports, this translates into the drama of the game. But in product design, this translates into the "why." Simon Sinek tackled this issue in his book "The Power of Why." Most designers tell others the ins and outs of their products then expect them to pay for it. That doesn't work. Users and spectators both need to know why they should care or why they should use your product.

It's imperative that we know who our customers are and what problem our products solve for them. However, it's also worthwhile to consider those casual spectators. Win them over and you'll be well on your way to transforming them into actual users.

Hat tip to Dre from Wages of Wins for sharing this video with us.

Jargon. It's an occupational hazard. Which is why we couldn't help but chuckle when we read this Harvard Business Review article on the subject. The article got us thinking, what are the buzzwords in our field that simply don't make much sense to us? The one term that kept coming to mind was "User Experience Design."

For us, "User Experience Design" would have to fall into the "meaningless expression" category of the article. Think about it — to truly be a UX Designer you have to be an expert in so many fields. That's because the buzzword of User Experience Design covers too many fields: anthropology, psychology, graphic design, user research, communication design, usability and much much more. How can any one person really be an expert in all that?

Digging deeper, how can you design user experience? To say you're designing an experience that just happens and changes overtime, you're committing yourself to crafting something that's not only functional, but creates the same emotional response from every user. Or as Smashing Magazine points out:

Users are different. Some are able to easily use a website to perform a task. Others simply are not. The stimulation that a product provides depends on the individual user's experience with similar products. Users compare websites and have different expectations. Furthermore, they have different goals, and so they use what you made in different modes.

In other words, user experience can't be designed. You can't [edit: control] the emotions, feelings, and experiences of the user. You can, however, understand them. As product designers, we shouldn't think that we're creating experiences. Our goal is to understand how users interact with our products so we can make them better.

There is a time in every man's education when he arrives at the conviction that envy is ignorance; that imitation is suicide; that he must take himself for better, for worse, as his portion; that though the wide universe is full of good, no kernel of nourishing corn can come to him but through his toil bestowed on that plot of ground which is given to him to till.

—Ralph Waldo Emerson, "Self-Reliance"

That quote has always got me thinking about the difference between innovation and imitation. Take Steve Jobs, for instance. He has been both hailed as an innovator and crucified for being an imitator. Over the years, Jobs has been accused of stealing the mouse and personal computer from Xerox. But Jobs didn't steal what Xerox designed. He saw what opportunities they missed and built off of that, improving the concept. That's innovation, not imitation.

However, imitation remains a trap that product designers fall into. They're dead serious about being the next Facebook for "insert a hobby here." They can't break out of a certain way of thinking, as Brendan Boyle, partner at IDEO, points out in this video:

I was fortunate to start my career as a toy inventor and had the pleasure of working with Brendan. That video has some pretty funny moments and products. His point? Put more fun into the process of creating and building ideas. Look at problems from a completely different perspective.

Product designers in the digital world need to stop taking themselves so seriously — the next great idea isn't going to come from imitating Facebook. After all, Mark's Facebook site originally started as a college hook-up site. And if you find it easier to imitate rather than innovate, remember what Emerson said, "Imitation is suicide."

Lately, we've been thinking a lot about passion around the offices at ZURB. Where exactly does passion come from? How does an aspiring entrepreneur turn a desire into a passion? So it's no wonder that a recently unearthed vintage video of Steve Jobs talking about passion caught our eye:

What Jobs is talking about here is being truly passionate about your work, for your craft. Investing yourself in your ideas when no one else will, when there might not be any financial rewards. We really love his observation, but what really fascinated us was when Jobs says:

Those people that are crazy enough to think they can change the world are the ones who can do it.

Jobs certainly was crazy enough and passionate enough to change the world, the way we interact with products. However, that passion didn't spring up overnight. It came from deliberate practice and hard work, and finding meaning in his craft.

In the past, designers tended to work only with other designers. That's no longer the case in this day and age. Designers who build awesome products need a strong support team. That's something we know firsthand at ZURB, which is why we're looking for a great marketing team to give our designers the support they need.

We're looking for a Marketing Lead and a Product Marketer. The dynamics of these two new roles will shape the way we do things here at ZURB. And we're super stoked at the opportunities this dynamic duo will create.

Marketing Lead

The Marketing Lead will lead (pun fully intended) our marketing and communications efforts, and provide backup for our business development. Not only that, but the lead will book our ZURBsoapbox speakers and set up outside talks for other ZURBians.

Product Marketer

The Product Marketer will be the Marketing Lead's "partner in crime" who'll help drive our product initiatives into warp speed. The person who fills these shoes will have a passion for analytics, crunching the data to help us become better at what we do.

Think You Have The Chops?

So what is ZURB looking for? We want T-shaped people who are optimistic, love problem solving, and are hungry to learn. In other words, can you get scrappy? Roll up your sleeves? Are you passionate about getting the word out about ZURB? Do you feel up to the challenge? Can you go the extra mile or more?

If you think you do, then check out our job listing for Marketing Lead and Product Marketer, and show us you've got the skills.

How many times have you heard this said while you’re building a product:

Listen, a few customers have requested this already, a number of us here love this feature. Let’s just build this and see how well it does. Analytics will tell us if this is a keeper or not. This is the quickest way to learn if people like the feature.

One of our good friends and loyal customers who IPO’d last year (can’t mention their name unfortunately) took this very approach: Build it, launch it, and see how well it does. When I asked him how well this approach worked out for him, three things were apparent:

1. They spend a LOT of money building the new functionality and changes.
2. They pulled a lot off new functionality down and never use it.
3. The spend a lot of time developing and testing new functionality.

”What if you could test out an idea without implementing it, from a mockup or a wireframe?” I asked."After all, why do you have to implement stuff that customers won’t use if they can tell you ahead of time?"

“Oh, you mean like a focus group? That’s too much time and effort," he said.

“No, I mean quickly mocking something up and asking customers a question about it."

People really get stuck when it comes to testing things before building them. Engineers, product managers, and designers just want to build stuff to solve problems then release it. However, a few key decision makers doesn't adequately represent thousands of would-be customers. If you’re building a product for customers (not just for yourself), you’ve got to test your assumptions early on with your potential users.

Testing Your Assumptions

At ZURB, we’re huge proponents of testing any assumptions we might have before we implement a change or the new feature in a product. It’s in our DNA. We saw that there was a hole in the market as far as tools go for this very problem. We built Verify to help ourselves, as well as many others who are building products, test assumptions before implementing features.

One side of the problem is having a tool that you can upload your concepts into, attach a question, and test out those assumptions. The other side is having an experienced set of passionate people that can give you great feedback about the changes and updates you’re thinking of implementing. These are the types of people that have had enough of sucky sites on the web and want to improving the web as a whole.

Helping Others Test Assumptions

We are excited to launch our own service called Enroll to build a community that helps make the web a better place by giving those building products honest and actionable feedback.

Your personal dashboard in Enroll to keep track of tests you've taken.

As you can see from these screenshots, everyone who signs up for Enroll will be able to track the quick 5 second tests they've taken through their own dashboard as well as earn different badges as rewards for tasks completed.

If you are excited about helping big brands solve their product problems then you’re the right type of person to give Enroll a shot. We're looking forward to hearing how all of you like Enroll. You can sign up now by following the link below. As always — feel free to reach out to us at support@enrollapp.com.

Sign Up To Help Improve the Web

We've said it once and we'll say it again, get feedback or fail. Spending tons of money to launch a product only to later learn that it's a flop (we're looking at you, Google Wave) is not only a waste of time and money, but it can damage your reputation. You need feedback while building your product.

That's where user testing comes in. However, many product designers fear putting their work out in front of would-be customers before it's finished. After all, who wants to expose something they've created to criticism? Who likes to hear where they've gone wrong? Then there's all the work — gathering testers and conducting the actual test. Why go through all that effort when you can just put stuff up and launch it? With that mentality, it can be easy to dismiss user testing.

As the folks at Penny Arcade point out in this excellent video on video game testing, your product is competing with dozens of other products, so it has to be prepared for that. The way to do that is user testing. Check out the video below and notice how the folks at Penny Arcade approach user testing and why you can't be afraid of it:

Let's break down three of the major points in this video and see how we can apply them to our approach to user testing:

1. Be willing to admit you're wrong. As the video points out, you're too close to your projects. You'll have a natural bias. Admitting that you don't know all the answers encourages a lot of "why" questions, which leads to solutions to a problem. In other words, it's OK to be wrong because it'll eventually get you to a win in the end.
2. Fully invest in your work without letting your pride get in the way. As creative types, we naturally fear exposing our work to criticism. After all, we pour our blood, sweat, and tears into our projects. They become our babies. So it's easy to have a knee-jerk reaction to criticism. One way to keep from being reactionary is to solicit specific feedback, such as avoiding open-ended questions and seeking feedback that is directly related to moving your project forward.
3. It's never too early to start user testing. OK, you have an idea for a product, might even have a few pixels finished already, but why start early? Remember Josh Levy and Ross Coen, BeenVerified's co-founders? They blew $550,000 in funding without getting a single customer because they developed a product in silence first and tried to find a market later. As entrepreneur Joel Gascoigne advises, throwing up a landing page that talks about your product is one way to test drive the concept. Testing early is far cheaper than building a product in silence for months.

It might be tough to hear the constructive feedback from your potential users, but it's absolutely crucial to see if your ideas and concepts work. However, getting feedback isn't enough, you also have to be open-minded and willing to accept that you might not have all the answers.