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

A month ago, we finished our initial efforts of redesigning ZURB.com. It took a lot of work and we had to overcome many challenges, but the outcome is totally worth it! We now have a site that we’re proud of and that does a great job of telling our story, sharing our beliefs and showcasing our work.

Our beliefs are told through the ZURBmanifesto, which outlines the core values of our company in a clear and concise way. it’s used to shape how we do business from every angle.

One goal we set for our new site was to showcase our Manifesto in a way that would get people excited when they stumbled upon it. We made sure the page looked like it had the same visual language as the main site, while also standing alone.

By looking at a single slide, you can tell that this is a ZURB page. We used color, typography, sketches and iconography to add dimension to the slides (both visually and metaphorically). To accomplish all of this visual candy, we used and abused CSS and jQuery a bit. We’re going to focus mainly on the CSS side of things for today. Follow along as we take a miraculous journey into the source code of our Manifesto.

The Manifesto features all the colors from the ZURB palette.

Capture Attention Quickly

We really wanted the transition between each slide to be memorable and eye-catching. We used multiple backgrounds that changed position as the user scrolls down the page, creating an effect of depth and movement. We also used sketches that were specific to each section to help add to the story in a visually fun way. These were animated, but aren’t affected by scrolling, just triggered by the position of the scroll bar. This way, they act as little surprises that reveal themselves in a unique way for each slide, even if the user stops scrolling.

To create the animations, we used CSS transitions that were triggered at different times by injecting new values via jQuery at specific increments on the page. The challenge was that we needed to constantly know the size of the screen, even if people resized it in the middle of their visit. This required lots of JavaScript to get right, but the CSS was relatively simple.

We made a container for each animation that had a fixed height and width based on the window size. The sketches were positioned within these containers and moved around by changing values with jQuery. The trick to making the sketches actually move was using only a few lines of CSS:

// A basic transition effect written in CSS
.animation-container img {
  -webkit-transition: all .3s ease;
  -moz-transition: all .3s ease;
  transition: all .3s ease;
}

To handle a lot of the animation states, timings and positions, we had to rely on jQuery so that we’d be able to know the window size and calculate our positions and timings accordingly.

Blur the Boundaries of What You Thought Was Possible

Another key factor in making the transition between each slide look and feel really awesome was how we handled the main text. As you scroll down the page, each slide overlaps the previous one, adding to the illusion of depth. At first, the text just stayed still, but it needed something more. We fiddled around with a couple ideas and decided that making the text fade into the background as if it was moving on the z-axis of 3D space would be best.

Resizing the text to make it look like it was fading into the background was pretty easy, but we really wanted to sell the illusion by making the text blur as well.

You can see how the text slowly gets smaller and blurrier.

Sizing the Text

To handle the effect of resizing the text as the user scrolls down the page, we strapped on our good ol’ CSS transform tool belt and its friend jQuery. Styling a static piece of text is simple with a transform, but we needed some logic to handle the change in size based on scrolling.

// A basic transform effect written in CSS
.scale {
  -moz-transform: scale(.5);
  -webkit-transform: scale(.5);
  transform: scale(.5);
}

// Written in jQuery, using a variable to change the scale
$blur.css({
  '-moz-transform': 'scale(' + blurScale + ')',
  '-webkit-transform': 'scale(' + blurScale + ')',
  'transform': 'scale(' + blurScale + ')'
});

We created an equation that outputted a percentage (blurScale). This percentage would change as the user got closer to the next slide. Now we had our text scaling and partially looking as if it was moving in a 3D space.

Blurring the Text

The blur effect in the manifesto isn’t really a blur at all, it’s text that has the color attribute set to transparent and the text-shadow attribute set to different amounts. The higher the spread of the text-shadow, the more blurred the text would look. We employed a similar jQuery technique to handle the logic we needed to change the blur effect as the user scrolled.

// CSS Needed to create the blurry text effect
.blurry-text {
  color: transparent;
  text-shadow: 0 0 30px rgb(255,255,255);
}

Our JavaScript simply changed the “30px” value depending on how close the text got to the next slide to create the awesome blur effect that is shown.

Design For Any Device

With the number of devices being used to surf the web these days, we just couldn’t pass up the opportunity to make this puppy responsive. We utilized parts of the Foundation grid, jQuery conditional statements and media queries to render different effects and layouts at different screen sizes. One of the concerns we had was performance. Mobile devices aren’t known for handling lots of animating objects happening at the same time. This has to do with how they handle the code and the size of the load.

To ensure that people viewing on mobile devices had a good experience, we removed most of the fancy JavaScript effects and made the slides stack down the page in their normal flow. The animated images were made static and the backgrounds simplified. We wanted it to be easy to flick down the page without performance slowing people down. The changes were handled using media queries.

// Media query example
@media only screen and (max-width: 768px) {
  .row { 
    overflow: hidden;
    padding: 0 20px;
  }
  …
}

Venturing Into New Territories

We had our heads down in the code on this one for awhile, but we’re really happy with how it turned out. It was a new type of responsive challenge for us, handling such complex animations and logic while mixing so much CSS and jQuery. The parallax effect of the page helps to add excitement to our beliefs and conveys them in a unique and creative way. Sometimes the best way to teach yourself a new technique is to just jump into an idea full-force and not think about how hard it might be to complete. There are always solutions, you just have to find them.

You can take these techniques and come up with something awesome too. Be sure to post it in the comments for everyone to see. The best way to push boundaries is to venture into new territory and let others challenge your assumptions. Take risks and run with your ideas.

Check out the ZURBManifesto »

We looked at the current state of responsive tables, and we weren't happy. Today we've released a new playground piece, with a new, awesome take on responsive tables.

If you've ever tried to make large data tables work in a responsive design, you know what a pain they can be. Tables have a magical property that says they can never be so small that parts of a word have to be cut off — they can't overflow. That means that, when your design shrinks down for the width of, say a smartphone, large data tables will ensure your design doesn't actually shrink all the way down. It sucks.

We wanted to try and do better, so we got to work on a responsive table implementation that would meet three criteria:

• Doesn't break responsive layouts
• Doesn't unnecessarily hide table data
• Still allows you to compare rows with a key column

A bit of a tall order but with some crafty CSS/JS, we cooked up something we think is pretty nifty. You can go ahead and check out our new responsive tables, or stick around to hear more about how it works.

How it Works

As we looked at tables we realized that, most of the time, the first column is the unique key for a table. That provides the reference for the other columns, while the column headers provide the legend for what everything means. With that in mind, we wanted our responsive tables to have that first column available at all times.

This is a schematic of how the table changes from a larger screen to a small one. Basically, we take the first column and pull it out of the table element, positioning it over the table in its own element. Then we allow the table itself, minus that first column, to scroll under it horizontally.

What this allows is for the user to see the entire table (albeit not all at once, they have to scroll) while still seeing that first 'key' column. We don't have to flip the table axes, or hide data, or break the layout, we just rely on the user's ability to swipe across to see all the data and compare the rows and columns.

There are a couple caveats here. First, for the small device format we have to restrict cells to a single line (for a consistent height). The separate left-hand column and other column elements don't impact each other, so they can't correctly dictate an arbitrary height. Second, this doesn't work in Android 2.3 and below as it doesn't support scrollable DIVs. Android 3+ should be good to go.

Built for Foundation

We developed these to drop right into Foundation, our responsive, open source front-end framework. They're great if you're working on a responsive prototype, or responsive production code, and need a way to manage large sets of tabular data. While they're built for Foundation, they should work in any responsive front-end.

Try it out, give us feedback

You can check out our responsive tables or you can go right to the code on Github.

If you're interested in other approaches, Chris Coyier did a great round-up a while back on responsive data tables — there are some fascinating approaches in there, but none which met our criteria.

If you have some other ideas to either improve on this approach, or something else we should check out, sound off in the comments. Have fun with this new code, it was fun to work on and hopefully fun for you to use!

Success is the ability to go from failure to failure without losing your enthusiasm.

Winston Churchill said that. He's quoted time and time again when it comes to failure. Churchill certainly knew about failure, having weathered his country through its darkest hours to a hard-earned victory. But Churchill’s quote has always had people thinking about what it means to fail and whether he was talking about complete failure or those smaller failures that help us win in the end. And the concept of failure is something that many startups struggle with.

See there’s a popular perception that once a startup crashes and burns, its founders will quickly raise from the ashes and make a comeback like Elvis from the dead. In other words, as Google Ventures partner Joe Kraus says, entrepreneurs tend to think that they learn more from the failure of their companies than if it they were ultimately successful. But that’s not the case, Joe argues.

Joe doesn’t quote Churchill, but a 2008 HBR study instead. And the numbers are telling. The success rate for first-time, venture-backed entrepreneurs is 18%. If they fail, their rate of success jumps up by only 2% — to 20%. But if entrepreneurs win in their first venture, their chances of success in their next one is 30%.

For Joe, we learn more from our successes than our failures, that those who've won before are likely to win again. In other words, when you win, you’ve learned what it takes to win. When you lose, you’ve only learned that your choices were wrong. OK, that’s probably a little too simplistic, but Joe is onto something when it comes to seeking failure.

We’re Not Seeking Failure, We're Seeking Wins

We shouldn’t be seeking failure, but, at ZURB, we accept that it’s part of what we do. All of us, at some point, are going to fail. Failure, however, is not an excuse to throw up our hands and admit complete defeat, give up and quit entirely.

Sure, there are train wrecks behind every success. Even Steve Jobs had a flop or two. But those flops didn’t cause Jobs to give up on Apple as a whole. When NeXT failed, Steve didn’t give up on the software, which eventually became the basis of the MacOS.

Rovio didn't give up on itself even though it had 52 failures before hitting gold with Angry Birds. All those little failures added up into one big success.

Same with us. When we tried to get into the stock photo business about six years ago, making it a “business within the business,” it didn’t mesh well with our mission — to help people design better products for people and faster. We worked hard for three years to make it work, people were interested, but it wasn’t building any momentum for us. So we made the call to shut it down. However, we didn't call it quits on ZURB and applied what we learned to the larger business.

In so many words, we're in it for the win, not the loses, even if we hit a foul ball every now and then. We want to win and keep winning. That’s what fail fast is all about and that’s what Churchill was really talking about.

If you hadn’t heard, bigger monitors are in, small ones are out … at least for desktops. The 1366x768 has ousted 1024x768 as the supreme screen size. Now we hope you’re not thinking that means we should stop designing for small screens, even if it is for desktops, despite what Jakob Nielsen might be saying. Because when it comes to designing for the web — size shouldn’t matter.

Nielsen makes it a point to carefully say that “small screens are finally so rare for desktop computers that we don’t have to design for them.” Then he goes on to cover his bases, saying we still have to consider small screens anyway. Nielsen seems stuck in a desktop world, a single-device myopia. When it comes to mobile devices, Nielsen seems to begrudgingly consider them and lays out these option:

• Build a separate mobile-optimized site: Only if you have the time to do so, then auto-direct them to the site and provide the appropriate links to toggle between the full-blown site or the mobile site.
• Mobile apps might be better: That’s because studies show that users perform better on mobile apps, says Nielsen
• Design for smaller tablets separately: Full-blown sites look good on 10-inch tablets, such as the iPad. Ideally, says Nielsen, you’d want to design a third option optimized for mid-sized devices, like Amazon’s Kindle Fire.

That last bit of advice seems really foolhardy. We can’t ignore that more and more people are using mobile devices to access the web, be it for tablet or smartphones.

Nielsen does make some good points about larger screens (like optimizing for widescreen monitors around 1,440px wide), something we considered when it came to images for the new ZURB.com homepage. But like 960 grids, we can’t get stuck in one screen size or device.

Four Corners, Not Devices

Don’t get us wrong, we agree with Nielsen that the desktop is far from dead. Tablets and phones are very much consumption devices (for now). It’s very easy to say that mobile will kill the desktop or the laptop as we use our mobile devices more and more everyday. When it comes to writing long pieces or editing/writing code or text, desktops are still where it's at.

For the time being, we’re still going to use a variety of devices for different tasks. It’s not devices, however, that we’re designing for — it’s four corners, no matter the size.

So it’s a waste of time to develop sites specific to each device. What’s needed is a modern grid system, which is why we developed Foundation and why we’re on the road to Foundation 3.0. Once completed, it will be one of the most, if not the most, modern responsive grid system in the world.

The Road to Foundation 3.0

We’ve already released a taste of Foundation 3.0 and another taste is planned for later this week. But what does it take to build a modern grid system that meets the challenge of building a robust site and still look good on hundreds of different devices and browsers?

In other words, what is it that we need in a modern grid system. Let's take a look:

• Flexibility: There needs to be enough columns that covers the majority of our layout requirements.
• Nesting: We have to have something that can nest down into a single column, right down to the N levels to give us the flexibility we need.
• Responsive: Since we’re no longer designing for devices and designing for four-corners, no matter the size of the screen, our grid needs to be responsive, fluid (percentage-based) and configured to scale down to smaller devices. And a fluid design is something even Nielsen sees as a good thing.
• Modifiable: Modifying things such as gutter size are a pain in the butt. So we want something that’s modifiable.
• Backwards compatibility: That’s because not everyone in the world uses Chrome or iOS5 Mobile Safari. We’d need support for Android, iOS 4+, Webkit browsers, Firefox and IE8+.

Here’s what such a grid would look under the hood (take a close look, it’s a sneak peek under the Foundation 3.0 hood):

OK, this looks great for desktops, but for smaller devices, we’ve added additional styles wrapped in this media query:

But there’s some overriding we have to do, to basically tell the browser on a small display to: don’t float the columns, don’t give them a min-width, don’t give them margins:

There’s more to building a modern grid system than just these two bits of coding. In fact, Jonathan goes completely under the hood to show us step by step on how to build such a grid system in a recently published .net Magazine article.

When it comes to being a responsive designer, remember what Yoda said, “Size matters not.” What say you?

Last week, we were excited here at ZURB to distribute new iPads to every member of the ZURB team: design, operations, marketing and engineering — even our interns. There's plenty of companies in Silicon Valley that kit their employees out with nice gear, but this wasn't just about everyone having shiny toys (though it doesn't hurt).

Multi-Device is the Future

You've probably noticed that it's not just laptops and desktops people are using these days. Other classes of device, like smartphones or tablets or eReaders (etc, etc) are beginning to dominate how people access the Web, or talk to each other, or capture and share things in their life.

We believe that, given this inevitable shift toward more disparate devices, it's important to put more of our eggs in that basket. That's why we developed Foundation, our responsive framework for developing sites and apps for any device. That's why when we relaunched ZURB.com we did so in a way that worked across devices, and it's why we develop sites and apps for our clients responsively.

We Need Multi-Device Design Literacy

There's plenty of reasons to have iPads in an office. We use them for QA, we can use them to present work to clients (or each other) ... but the biggest reason we kitted out each and every ZURBian with an iPad was to foster an environment of multi-device design literacy.

It's not just our designers who need to understand how Design works in a multi-device world. Our marketing team needs to be immersed in these devices so they can talk about it. Our engineering team needs to know about them so they can build new apps and services to cater to it. Our operations team needs to understand the multi-device world so they can plan for it, and work with it, and find new talent to drive it. We all have iPads because each and every member of our team needs to intuitively understand the multi-device world (we all have smartphones, too) and understand what it means for our business and our industry.

The Practical Effect

Here's an example of how this is already helping our team. The new iPads, with their retina displays, make for a great reading and browsing experience. We also recently relaunched ZURB.com with a visually rich design. However: we did almost nothing to cater to retina displays (it didn't even exist when we started the redesign). No high-resolution imagery, no consideration for the improved readability when it came to font sizes and the like.

We could simply serve up giant images and scale them down for everyone else, but something else the iPad teaches you is that while the resolution might be enormous, often the bandwidth is not. Even on 4G LTE Retina-sized background images are a seriously large file load. We're still working on this problem, but without team-wide exposure to this we might not have even bothered and we have to bother. These devices aren't going away, and they're not going to get less capable.

That's a technical example, but the effect is spreading already. When we evaluate new services to drive operations, we consider whether they work on different devices. We're already planning for TVs with connected AppleTVs in our breakout rooms, because our iPads can present directly on them without messing with cables. And so on.

Consider how immersed you are in a multi-device world. Smartphones, tablets, notebooks, eReaders, glasses (hehe), TVs, cars ... to work on what we all work on we need to understand these things.

Curious to learn more about the ZURB culture? If you’ve been following our posts from last week, we gave you a nice look into how a new designer adjusts into a new environment as well as our approach to failure. It’s different, and we embrace it!

Culture aside, we had two other posts covering entrepreneurship and customer service topics. Grab that cup of coffee and enjoy our Week-In-Review.

Breaking In A New Designer

One of the most exciting times in a ZURB designer’s career is joining the company, but it doesn’t come without a few bumps in the road. Alina, one of our new designers, shares her experience joining the company and the issues she encountered early on in her time here. We’re excited to share some insight into how ZURB “breaks in” a new designer — and how our approach for doing this differs from most other design companies out there.

Read: "Breaking In A New Designer"

Don’t Underestimate the Importance of Customer Service

Customer service is an important part to many businesses, but is it crucial? Forrest examines customer service from ZURB’s angle and says it’s not just important, it’s of core importance for product gut reactions and long-term company strategy. Don’t underestimate the importance of day-to-day customer interactions in helping your business excel in an increasingly-competitive world.

Read "In Product Design, Customer Service Is Much More Than A Simple Q&A"

Embracing Failure and Fostering Success

We’re not perfect. At ZURB, we embrace failure as a core component to our creative process. We foster success through failure, but just how do we go about this? Ryan shares our point of view on a topic many people like to put off to the side, and references personal and business examples to give context to the point.

Read "Rewarding Failure? Actually, We're Fostering Success"

The Scientific Method and Startups

Not all of us were biology majors in college, but many of us actually can apply a useful tool: The Scientific Method. Ryan breaks down the method and discusses each step in great detail from a startup perspective. Testing out your ideas are crucial for success, whether or not you use the Scientific Method to get there.

Read "How Startups Can Apply The Scientific Method "

Customer service is a core part of ZURB’s day-to-day operations. We spend a lot of hours ensuring that each of our customers can take full advantage of the apps that they invest in.

In the most traditional sense, customer service is actually quite basic. A customer has a question, gets in contact with the company and gets their question answered. Perhaps it’s not always this easy, but at its core, it’s a transactional exchange of information for a time.

When it comes to ZURB (and product design), however, customer service is a completely different animal. No longer is it just a transaction — it has to be a fruitful conversation. A customer service advocate must not just answer the questions of the customer, but understand the bigger picture about how the issue translates to the broader business goals.

Customer inquiries differ greatly, but we gather valuable information from every interaction that helps shape our business. On the most basic level, bug reports turn into bug fixes. Two other key insights include curated feedback that lead to gut reactions on product, as well as feedback that helps shape our long-term business strategy.

How Customer Feedback Helped Us

Let’s look at two examples about how our customer feedback helped contribute to change in one of our products, Notable.

Louis, our customer service advocate, noticed early on in Notable’s lifecycle that several customers were confusing Workspaces with standard Notable posts. The recurring issue was confusion between how posts and Workspaces differed given they were all integrated into a single dashboard.

Understanding this feedback, we separated Workspaces into a new right-hand nav, keeping only Notable posts in the upper navigation bar. While customers continued to have some questions about Workspaces functionality, the design change clarified how users should view posts and Workspaces as separate entities. Take a look on the image below (click for a larger picture):

We integrated CSV export functionality into Notable results because of customer feedback as well. Several customers requested an export option so they could store their Notable data, so we developed a small browser hack to meet their needs. By simply adding .csv to the end of the HTML link of the Notable results, a user could now download results for offline use.

Through identifying CSV exporting requests as a trend in customer interactions, we developed a solution that would fill that common user ask. Collectively, user feedback led to a gut feeling, which resulted in making this change for the users. It’s just another example of how listening can have a positive impact on your product.

It’s important to not just address customer needs, but gather feedback through fruitful conversations with our customers. Through this, we build better products that help people design faster and better than before. Don’t underestimate the value of customer interactions in helping your business meet and exceed business objectives.

How does your organization think about customer service?

Alina highlighted something the other day that caught the attention of a few people — that part of our culture is to encourage our teammates to get crazy and throw out some pretty wild ideas, even if it means failure. She rightfully called it opportunity and outlined three good reasons why we do it:

1. To get bad ideas out of our system
2. To make sure no creative stone is unturned
3. And, occasionally, to gauge the customer’s wild side

But there’s also another reason we do it — to learn and to do so quickly so that we can move on. We call it “fail fast.” When you enable people to take risk, try things and fail, they learn faster and their productivity skyrockets. Think of it as autonomy to fail by not putting up a barrier that inhibits employees. In a way, it pushes them to master their craft.

Truth be told, everyone of us has failed at some point. Recently, I took a chance and pushed the envelope on some copy for our website, taking a more hard news slant. After having a spirited debate over the content with a fellow ZURBIan, I realized that I hadn’t just pushed the envelope — I'd blown it apart. But I learned how to better balance my journalistic instincts with the needs of the business. I learned to find the happy medium. That’s not to say I won’t take another risk again. But I learned from this one.

Productive Failure

Don't get us wrong, it’s not that we’re seeking failure. It’s what Eric Ries calls productive failure, where you learn something really important from it. Take Josh Levy and Ross Cohen, BeenVerified’s co-founders. They burned through $550,000 in 11 months because they failed to figure out who would actually use their product.

Sure that’s a hard lesson to learn and they could’ve prevented it by doing some user testing and getting feedback as early as possible. But hindsight is 20/20. The important thing is that Levy and Ross learned to not waste time developing a product without a customer. Now that’s a productive failure and the duo were able to eventually turn BeenVerified into a success (it made $11 million last year).

Rewarding Failure or Fostering Success

To go back for a second to Eric. He was recently asked at the Wired Business Conference if startups were being rewarded too much for failure. His answer:

We’re rewarding failure not enough.

Eric’s got a point, but we’d add that it’s not that we’re only rewarding failure. We’re actually fostering success. Failure is the means by which we get there and get there at breakneck speeds.

There’s a lot of talk about applying the scientific method to entrepreneurism. It’s at the heart of Eric Ries’ Lean Startup, which he talks about recently at the Wired Business Conference. But exactly how do you exactly apply it to a product?

First, let's take a look at what Eric is really talking about. He's really advocating learning. To learn as much about your products as possible, to learn whether or not there is, in fact, a customer at the other end willing to pay for it. After all, he learned the hard way the damage not figuring out who your users are can cause. His early startup crashed and burned because he didn't figure out who would use and pay for his product. He says building a robust product and having a splashy launch could sink your startup if there isn't a customer to pay for it. Which is why he urges startups to apply the scientific method and view learning as a measure of progress.

Like a scientist, he suggests, you’ve got to test your ideas and continue to test them through hypothesis and experimentation, gathering feedback along the way.

The Scientific Method Break Down

While it’s not something we use all the time here at ZURB, we have applied the scientific method in our approach to product design. Let’s delve a bit deeper, looking at how we applied it when it came to eliminating a feature from Notable:

1. Make an Observation — Notable once had four features that allowed user to provide annotations for not only captures of websites, but code, copy and SEO content as well. The SEO tool let managers or SEO experts provide feedback on SEO data of a website, breaking out the metadata. However, we had observed that not many people were actually using the feature and preferred leaving notes on screen captures. Which lead us to ...
2. Ask a Question — We asked how many people were actually using the feature, along with the coding and copy annotation feature.
3. Form a Hypothesis — Our hypothesis was: "No one was using the SEO feature. Now we had to test it."
4. Test Our Hypothesis — To test our hypothesis, we looked through the database of users, separating those from paid accounts and free accounts. We found that a small percentage of users were using the SEO notes with 98% of users preferring to leave notes on screen captures.
5. Prove or Disprove Hypothesis — The data proved our hypothesis that no one was really using the SEO feature. It also showed that more people preferred annotating screen captures. So we decided to drop the SEO, copy and code features and focus on the visual feature of Notable. We decided it was more important to make one really good feature that everyone would use rather than four features, of which only one was really used.

As you can see, the scientific method was helpful in solving a particular problem. While it is really useful for testing out theories and hypothesis, the one thing we hope that you remember the most is that you have to test out your ideas. The scientific method isn’t the only way, but it’s one of the tools at your disposal to learn if your ideas will work out in the wild.

I’m one of the newbie designers here at ZURB. It’s an exciting place to be and I’m so grateful to have joined this powerhouse team. But even with all the joy of coming to work everyday, there are still some growing pains every new designer experiences here. That’s because ZURB is a very special place and we do things quite different here. More than anything else, the pains come from getting up to speed on ZURB’s unique approach to design and breaking some of the (bad?) habits we’ve picked up along the way in our careers up til now.

We Want to Prove Ourselves

As a new addition to the team, there’s a lot of pressure to make yourself of value and validate being added to ZURB’s awesome team. (Honestly, the pressure is just in our heads, not brought on by the team.) We desperately want to be “worth it,” which means that mistakes are really hard to get over. Even a small mistake can feel like a huge letdown — a failure.

But failure is a really big deal here at ZURB. In fact, we have a special word for it — opportunity. That’s because every half-baked idea and every inept solution is our chance to find out something new about the product we’re working on. We always throw out a ton of ideas to our customers, knowing fully-well that some of them are too out-there and a few are just plain wrong. But there are three good reasons we still do it:

1. To get bad ideas out of our system
2. To make sure no creative stone is unturned
3. And, occasionally, to gauge the customer’s wild side

We Want Our Work to Speak for Itself

When new designers, such as myself, join ZURB, we use our experience, judgement and best practices to present solutions that we can recommend with confidence. We just want the customer to look at our work and instinctively fall in love with it, without further explanation, of course — after all, it’s all in the layout, right? The trouble comes when the customer starts asking questions and challenging our recommendations.

The truth is that work doesn’t sell itself. A great concept can be easily scrapped by the customer who isn’t going to read your mind about its merits, while a mediocre idea can be a wild success when positioned correctly.

We often work on very complex products, which require sophisticated solutions. And that means our customers expect us to have the answers on all of their hows and whys (and rightly so!). Which is where I found myself recently — stumbling to explain an elaborate interface and defend even the simplest element, all because I didn’t think through the justification ahead of time. Having a clear point of view is valued greatly at ZURB, but learning how to articulate that point of view is as important, if not more.

We Want the Big Ta-Da!

When most agencies get projects, they hole up in their offices for a few weeks to do research, put together strategies and comp up layouts. Next, they assemble an impressive presentation and have “the big reveal” meeting with a customer. There the customer-agency relationship is simple: customer provides a project, agency provides a solution. And it’s really the only process designers know before joining ZURB.

Things are really different here. We don’t do big reveals. Our process is not mysterious. We’re very transparent about how ideas turn into concepts, which turn into solutions. We present one small idea at a time, which our customers can easily grasp and believe in. We then combine several small ideas, and they magically become solutions that customers feel invested in and fully appreciate. It’s one small “aha moment” after another, that in the end amount to a big “wow factor.”

Trying to present a solution right from the start can actually backfire! Recently, I worked on a project where I tried to bite off too much too fast. I presented too many new ideas in one little neat layout, which just left the customer confused — we could actually hear their eyes glaze over on the phone. But had I showed all those pieces individually, the customer would have been open to them and felt like they were part of the creative process.

What’s more interesting is that, after working with ZURB, customers often adopt these methods of creative exploration and iteration within their organizations. We love hearing that marketing directors are picking up Sharpies and shopping around sketches to their team. That’s actually one of our schemes for world domination.

It’s been an exciting and challenging couple months. I can only imagine how much I have yet to learn!