Our ZURBevents explore the intersection of product design and business. →
Come to ZURBsoapbox:
ZURBexpo is an exhibition of product design ideas to help you design great products faster. →
Our latest blog post:
Joining ZURB has introduced so many changes to my life. It was my first time in the United States, my first time being away from home for an extended time and my first time working with a team of designers. The change was mostly seamless, thanks to the awesome ZURBians that helped make the transition as smooth as possible.

While the transition certainly had its challenges, I realized from day one the extent to which ZURB embraces the notion of the Unicorn Designer — someone who could do more than envision spectacular visual designs. More importantly, I learned quickly that I'd have to not only have a good design and do it in a set amount of time, but I'd have to tell a good story as well.
There's no hand-holding, and I had to learn things the hard way. On my first day, I already had a project assigned to me and was ready to go, and that marked the beginning of the learning process. I spent my first day scrumming with the other ZURBians on various processes such as marketing, sketching, and email writing. This helped me understand that design thinking shapes every ZURB process.
It takes a lot of dedication and focus to become a ZURBian designer. It's a long journey toward being a master of all trades, that fabled unicorn designer. Designers at ZURB sketch (a lot), wireframe, create stunning visual designs, and code their designs.
Design skills aside, working with a team and getting quick and frequent feedback on designs is the most essential skill I had to learn as a new designer at ZURB.
Teamwork is effective at ZURB because of the transparency between all team members. During our morning scrums, we outline our tasks for the day while passing around our Angry Bird toy. This leads to frictionless collaboration, as well as more control over our own time. There’s no need for a project manager to schedule every minute of every designer’s day. This means that it’s the designer’s responsibility to actively seek out feedback from team members and design leads.
The feedback/iteration loop is the cornerstone of the ZURB design process. Over the years, we've developed a few techniques for getting feedback and iterating on designs fast. Of these techniques, the most important one has been timeboxing — the process of assigning specific times to tasks, and working to achieve awesome results within that limited timeframe. Timeboxing came in handy when I had to step back and reevaluate my work on a recent customer project.
At the start of one of my projects, I was tasked with creating quick sketches for a new marketing site. I dived right into sketching and forgot to step back and look at the bigger picture. I wanted to perfect each individual sketch before we’d framed the problem. Even worse, I made the mistake of not seeking feedback from Bryan quickly or frequently enough.
These mistakes culminated into a pile of fragmented sketches that represented pages and not a system that solved the customer’s problem. I realized that I’d gotten too prescriptive too soon, trying to solve the problem with buttons and forms, when I should have been thinking of people and stories.
With an hour left to go, I started from the top, framed the problem as a story. That helped give structure to the sketches. The ideas started flowing afterward into a stream of quick sketches that were connected and told a story that solved the client’s problem.
Without that clock ticking away, I would have kept trying to shotgun the problem with more fractured sketches. Timeboxing helped me become more conscious of my time, and frequent feedback helped me identify my own problems with my design approach and quickly improve on it in time to deliver awesome work to our customer.
That experience and learning the ZURB process has completely upgraded my approach to design. Unicorn designers sketch, wireframe, visual design, and code, but a ZURBian designer is also a great storyteller.
Last week was an exciting one for us. We launched a Playground piece that should help product designers with a nagging issue in their responsive designs and discussed the CSS behind our Manifesto. We’re excited to share both of these awesome resources with you.
Without further ado, the Week In Review:
We released our latest Playground piece last Thursday — Responsive Tables. If you’re tired of tables breaking your responsive layout, here’s your fix. Jonathan breaks down how exactly it works and puts out a call for feedback. We want to hear what you think!
Read: "A New Take On Responsive Tables"
Curious to know more about the CSS behind the ZURBmanifesto? Chris breaks down the exact techniques we used in the creation of this resource and offers insights to help you construct a page very similar to ours. If you haven’t already, check out the ZURBmanifesto.
Read "The CSS Source Code Behind Our Manifesto"
ZURB bought iPads for every single ZURBian — and it’s much more than just carrying around a cool device. We live in a multi-device world and because of this, we need to have design literacy on these new platforms. Jonathan runs down the rationale behind equipping the team.
Read "Why Every ZURBian Carries An iPad"
What does a modern grid system need to be? Ryan looks at our approach on what needs to be included by listing out five specific components. We’re designing for four corners — regardless of the size — and a modern grid system is the best way to approach our design challenges with designing for multiple devices.
Read "Size Matters Not: The Road To Foundation 3.0"
Ryan breaks down a blog post arguing for learning more from successes than failures. ZURB believes in the concept of “failing fast,” and we win because of it.
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.
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.
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.
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.
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.
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; }… }
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.
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:
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.
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.
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.
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 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:
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.
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.
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:
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).
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.
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.
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.
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"
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"
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"
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.
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.
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:
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.
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).
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.