Posts About
Zurb sticker

All Your Mock Copy, Mocked Up.
Introducing Laura Ipsum!

Ryan wrote this on April 01, 2014 in . It has 51 reactions

Just when you thought we were done at Foundation. Just when you thought we couldn't get any better than "Lol and Order: CSS". Now we're mocking ... up your copy.

We're proud to announce, Laura Ipsum, our newest service and the latest in all your prototyping and mock-up needs. We've even hired a Laura Ipsum (what are the odds?). A 20-something with the wit to write all the Lorum Ipsum you ever wanted for your prototypes.

Totes McGoats! Lorem Ipsum is my fav!

Laura will be writing in her own unique voice, from the perspective of a 20-something living in the high-paced, high-tech world of Silicon Valley. Or is it just the Valley? Doesn't matter. It'll be words to tickle your prototype. Here's what she has to say about her new job:

Totes McGoats. ZURB is total amazeballs. So sauceome. Can't wait to do Fireball shots with the ZURBians. OMG. Right? So cray cray. Turn up, a'right. Hashtag twerksies4lyfe.

A recent graduate of Claremont High School, Laura is an expert in all things Lorem Ipsum. She was all A's in her dummy copywriting class. Here's an interesting tidbit: she can type nonsense at 100 word-per-minute. Whew! That's really fast. Only a room full of monkeys can type faster.

Get Laura Ipsum Today!


An Irish Import Who Loves a Challenge
Introducing Our Newest ZURBian

Shawna wrote this on February 24, 2014 in . It has 24 reactions

We don't have to look far for new opportunities here at ZURB. Sometimes they arrive at our doorstep, even from as far away as the Emerald Isle of Ireland.

It's with great pleasure that we introduce you to our newest ZURBian, an Irish import who loves a challenge. Everyone say hello to …

John Leenane, Business Development and Partner

John Leenane

John may have originally come from across the pond, but he's been in the Bay Area for about 14 years. He's worked with companies, big and small (read: startups). He recently founded two companies of his own, but once his path led him to ZURB, there was no turning back.

John's our newest Partner and Business Developer. And he's already gotten his hands dirty, opening up new opportunities for ZURB. He's focused on growing our business and finding new ways to bring ZURB to the next level. As part of our Connections Team, he'll continue to foster relationships, both new and old, sharing our mission of "Design for People" to anyone within earshot. And he can't wait to do so:

I'm really excited about helping all of us at ZURB, our community and all the companies we work with to reach their potential.

Not to worry, he's not all business. John knows how to have a bit of fun. He's a snowboarder, a windsurfer and a concert goer. These days, however, most of his spare time is spent with his wife and four boys — the latter which provides its own unique fitness regime.

Everyone please welcome John to the ZURB team!


How to Lose All Your Content Search Ranking: A Cautionary Tale

Matt wrote this on January 07, 2014 in . It has 121 reactions

Not too long ago we gave our Playground page a brand-new responsive polish. The Playground is one of the last ones we made responsive. And when we finally released its update, something horrible happened — our search ranking evaporated until nothing was left.

screenshot of Google Analytics that shows our search rank dropping off

A screenshot of Google Analytics showing our search rank dropping off.

When launching a new product or a redesign, we usually mind our Ps and Qs. We have a laundry list of things that we check, double check and, sometimes, triple check. Since Playground gets a ton of search traffic, we tripled-checked all the SEO things we knew, such as:

  • Titles
  • Keywords
  • URLs and redirects

We even fixed a number of things broken in the previous site. But that due diligence didn't seem to be enough. Week after week, we watched in horror as our search ranking dropped and dropped and dropped to nothing. We didn't even rank for some of our more well-known Playground pieces, such as Orbit and Reveal. What the heck was going on? Where did we end up going wrong? Was there something we missed? We were scratching our heads.

Whittling Down the Problem

First, we combed Google Webmaster Tools, which showed no errors. Bing and Yahoo still worked as expected. The problem was only in Google (read: the only one we care about). To figure out what happened, we went through all of the things that we could've messed up:

  • Duplicate URLs
  • Broken URLs
  • Bad redirects
  • Cloaking
  • Content being loaded via AJAX
  • WWW vs. no subdomain
  • Page load time
  • Invisible text
  • Service disruptions
  • Bad robots file
  • All of this stuff here from Google

We did all these things. And like we said earlier, we had even fixed most of them with the redesign. We even reached out to Google to figure out what happened, and they finally gave use a short response explaining the problem:

Hello Matt,

Thank you for your email.

It appears that you're serving Googlebot a different content type than you're serving to regular users. This is preventing Google from correctly interpreting your site. If you use the Fetch as Google tool in Webmaster Tools, you'll notice that Googlebot sees pages like http://zurb.com/playground/ajax-upload with "Content-Type: application/zip; charset=utf-8". Googelbot is unable to interpret the content type of your page which is preventing your page from being crawled properly.

What does that mean? Well, the root cause of the problem was that our server was setting a content-type that Google didn't like, so they stopped indexing our pages. All browsers were either not getting this content-type, or just ignoring it and figuring out to us the right one. If you knew exactly what to look for in webmaster tools, you could ferret out that Google was getting this content-type. But no error was reported anywhere. In fact, the page was indicated a "success".

Eventually, the problem was fixed with the correct content-type on our back end code. Everything was back to normal within a week. And Google gave us a curt response to our questions about why this happened in the first place. We asked how do we get the content reindexed now and why webmaster tools didn't show this crawl error.

Hello Matt,

It might take some time for Google to start reindexing URLs on your site depending on a number of factors like how often Google is able to crawl your site. These pages most likely did not show in Webmaster Tools as crawl errors because the pages were live and able to be crawled returning an HTTP 200. However, when Google tried interpreting the data on the page, it was unable to convert the file type and may have chosen not to index a page that did not have any content on it.

A Cautionary Tale

But this isn't about the solution or the resolution. This is a warning. You can't just launch something and not pay attention to your traffic. You might find out something horrible went wrong, long after it's occurred.


Building a Learning Organization: Top 10 Things We Did in 2013

Ben wrote this on December 27, 2013 in . It has 36 reactions

We always look ahead to new ideas, new events, and new ways to help people make great products. But as we close out 2013, we also stop to look back — and what a view it is. This was the year we brought into sharp focus our educational efforts with the launch of ZURB University, a better strong Foundation, new apps and improved ones. So let's take a look at 2013 ...

1. We Acquired Forrst

forrst acquired

The design and developer community Forrst joined our family in January. We acquired this feedback community because we wanted to help people iterate through their work and learn from helping others. We saw an opportunity to build upon what founder Kyle Bragger started and make Forrst a place of active learning.

2. The Smartest Foundation Yet!

Foundation 4

We launched Foundation 4 in February. This was the Foundation that changed everything and helped product designers build responsive websites faster and smartly. We retooled the framework to be Mobile First, made it more semantic and added faster JavaScript plugins.

Yeti Progression

The Yeti also got a makeover this year.

3. Teaching Product Design Through ZURB University

ZURB U

We began holding live, online Product Design training sessions in April. We felt, and still do, that it's crucial for every business to understand product design, especially with the proliferation of mobile devices. We've poured our 15-year experience into each of the ZURB University classes. We've held more than 30 webinars so far, held several in-person workshops and even sent our designers abroad to help hundreds of people learn our approach to better product design.

4. Creating a Library Resource for Product Designers

books

Education as a product designer is ongoing. There are always new things to learn. And we're happy to share our what we've learned, whether it's through a new Playground piece, a new pattern or an interesting factoid. Over the years, we've built several resources for designers, but they'd all been their own separate ventures. With ZURB University, we organized some of our properties — including Playground, ZURB Word, Pattern Tap, Friday 15, Design Quips and Behaviors — into one Library resource. There are also weekly product design lessons. This resource helps product designers learn the many facets of product design under one umbrella.

5. So Long Painful Images Loads on Small Devices

interchange

Images in responsive web design have long stymied designers. Many have proposed solutions, but none quite fit every need. In May, we tackled the problem and released Interchange, our solution for sending the right images to the right browsers. This new technique inspired people to design sites that look great across any platform while saving bandwidth and time for end users. So much so that we took this and baked into the next version of Foundation with some additional changes (see number 8).

6. Beating the Clock for ZURBwired

ZURB Wired

In August, we worked with nonprofit Rebuilding Together Peninsula to create an entire marketing campaign during our sixth ZURB Wired. They learned from our 15 years in a marathon 24-hour sprint. We do this every year to help nonprofits learn the benefits of design thinking and not getting stuck in details. The philosophy behind Wired is that anyone can learn product design to break through barriers and create something wonderful.

7. A Mobile-First Forrst

new Forrst

Eight months after we acquired it, we unveiled the new Forrst site. The focus of the redesign was to make it easier for Forrsters to give contextual feedback and truly make Forrst a place of active learning.

The new mobile-first design makes it easier for designers and developers to give constructive critiques on the go. Notable-style comments help people give contextual feedback on every screenshot. Versions, our most recent feature, helps people see the progress of each post over time. The end result: people can iterate through projects with outside opinions that provide new insight.

8. The Fastest Foundation Yet!

Foundation 5

A new Foundation blasted off in November. The fastest version of our popular framework ever was also the most downloaded at launch. Foundation 5 brought a whole new game with Interchange, which can now work with any type of content, improved speed overall. We also switched from Zepto to jQuery 2 for greater compatibility with the web design world. Designers and developers can now spend more time designing and developing than reinventing grids and UI components, making it even faster for them to use..

9. Strengthening the Foundation Community

Foundation tforum

We also placed an emphasis on faster learning with Foundation 5. Along with that, we launched a new forum for Foundation users to discuss issues, get help, and swap tips. This gives designers a central venue to learn about the CSS framework from each other. Since launching, we've had more than 550 posts!

10. Launching Ink, Our Responsive Email Framework

Ink

We introduced Ink, a responsive design framework for email, in November. We built upon our previous responsive email templates, but this time we created an entire responsive framework not just another series of templates. Why? Because frameworks give you a consistent code structure and styling that makes it easier to modify layouts in the long run. Better than just a single template, Ink allows designers to build complex layouts tailored to their needs.

It wasn't easy to create a framework that works across any email client, but we found a way to create a mobile-, tablet-, and desktop-friendly framework that makes emails look great, even on Outlook. We learned so much from developing Ink that we started an online course to share our experience with others.

2014 ... and Onward!

This was the year we strengthened our education services. From Foundation 5 (faster product development) to Forrst (smarter iterations) to University (formal design education), we've dedicated ourselves to building a learning organization that helps us and others improve their design skills. But our work doesn't end with the year — you can count on more resources and services to further your design education in 2014!


15 Days of ZURBmas: How a Flexible Process Helped Us

Shawna wrote this on December 19, 2013 in . It has 14 reactions

On the first day of ZURBmas, a ZURBian gave to me … an hour-glass with cards. OK, we won't bore you with our caroling. But it's pretty amazing to see our annual gifts get into the hands of our customers and friends who've supported us over the years. And wouldn't have been able to get them there without the entire team helping and applying a flexible process. And the last part is what got us over humps in the project.

gift images

A collection of photos taken by our friends and customers.

This year's gift was based on Friday 15, which are creative challenges that our entire team does every Friday afternoon. We started doing these fun exercises a while ago to hone our product design and problem-solving skills. It's become part of our culture and allows members of the team that don't usually work together team up (pun intended). While we had a concept, we needed to approach the problem of creating something special the same way we'd do for any project. Having that process made us get the gifts out the door in a tight (really tight) timeline.

On the 1st Day of ZURBmas, Build a Prototype

We got the idea to make a card set because we spend a lot of time playing card games after work. But would the idea fly? With sharpie and paper in hand, we whipped up a back-of-the-napkin sketch to estimate costs. Having a ballpark cost allows for better-informed decisions and helps manage the iterative process. It allowed us to answer: was the concept technically feasible? Did it meet our goals? How would our customers interact with the card set?

prototype cards

Our card-set prototypes next to the final product.

Prototyping also helped figure out these questions, including what exactly we needed to order, and costs. We constructed two prototypes: 2×3 (playing card size) and 4×6 (a bit bigger than an index card). Having something physical allowed us to investigate different ways of constructing the cards. We got a feel for how the cards felt in someone's hands. The winner: the playing card-size set. The 2×3s fit nicely between the fingers and was much easier to flip through. With that decision made, we could now make other decisions — like the design and who was going to be on our ZURBmas list!

On the 2nd Day of ZURBmas, Get Everyone Invested

Sending out an annual gift takes an entire team. But to get the elves into the workshop, they have to be invested. Storytelling was key to this. We had to tell the team the story of ZURBmas. They needed to understand the why of sending gifts — the benefits to ZURB, to themselves, and to the customers. And that was important to help the team visualize the end goal — getting the gifts in the hands of our recipients. Or else they might not give a Dickens. (See what we did there?)

We started telling the story of this year's ZURBmas gifts with the leads, then spread out to the rest of the team, like concentric rings when you plunk a pebble in a pond. This also allowed us to get feedback on the concept as well as on the prototype, and the designs for the card set, the greeting card and everything else. With the team onboard, we were able to divide the labor because no one person can do the holiday list, order the materials, create the designs and then box everything up for some 1,000 people. And the more people involved, the more we were able to open up problems.

Jingle Bells, Jingle Bells, Timeboxing All the Way

The timeline for this project was tighter than Santa's suit after he's had a few Christmas cookies. Starting in November, we had to ship everything by Dec. 13. And our sled hit a bump in the frost with our mailing list. We had to open up the problem and having others involved helped get us to a better answer.

For instance, our mailing list. It was collected from various sources: our clients, our close friends and those who signed up for our monthly newsletter. Not everyone was going to get the 15-minute hourglass. We had to decide who was going to get that or get the card set. We enlisted our Connections Team and our accountant to help divvy up the list, and our leads and interns contributed by pruning it of old or out-of-date addresses. Having those folks participate in the list allowed us to explore why only one group would get the hourglass/cards while others would get a card-set and a special holiday ZURB sticker. Our solution: clients, customers and close friends would get the former while everyone else would get the latter.

We took a similar approach when it came to figuring out the vendors for printing the cards. Creating burndown lists the entire team on target. And as the old adage goes, two heads (or many, in this case) are better than one when it comes to solving problems.

Let's Build a Gingerbread House

But that wasn't the only problem we opened up. We explored what else we could do to make ZURBmas special, especially for those who weren't getting the hourglass and those not on our holiday list. After exploring different concepts, we came up with the idea of creating an interactive game related to the "Gingerbread Tower" Friday 15 challenge.

sketch of gingerbread site

Sketch of the gingerbread site.

gingerbread house

A gingerbread house created on the site.

This game was another way to get other people on the team invested — this time our engineers. They were able to create the site in JavaScript. But it was tricky. Our engineers used Parse, which helps integrate an interface with your data, but can't handle relational queries. However, they found a workaround to get the site working. They also used touchpunch.js to for the drag-and-drop feature. Try it out for yourself, then share your creation!

'Twas the Night Before ZURBmas …

… And all through the house the ZURBians were packing. Having solved the project's problems, the entire team spent the last few days before our shipping deadline stuffing boxes and envelopes or filling out customs shipping forms. That's because they were invested. Like we said, they got the story of ZURBmas and wanted to be part of it. And they were all excited to see people tweet out pictures of the gifts they got. And we wouldn't have been able to sell that story or get the gifts in their hands without a flexible process. It allowed us to load up the sleigh, hitch up the reindeer and deliver the gifts to all our good friends and customers.

And with that, we want to wish a Happy Holidays!


Like Ninjas, Great Ideas Aren't Always Visible at First Glance

Alina wrote this on December 13, 2013 in . It has 26 reactions

Conventions tend to turn invisible. Like ninjas, they blend into the background. We blithely accept that privacy policies, for example, are long blocks of indecipherable, dull, gray text. They don't encourage people to understand what tapping that "I agree" button actually commits them to. As a result, few people read fine print thoroughly.

But privacy advocate Michelle Dennedy wanted to make her company's policy more engaging. Doing so would explain how would make privacy policy more than just an obligatory legal form. As she put it in a ZURB Soapbox:

Not just write policies, but to build fabric, and build culture and build passion, and build architecture and engineering behind human rights."

Don't be Afraid to Suggest Outlandishly Creative Ideas

Michelle said most agencies took the traditional route to learn project scope, asking questions about format and branding requirements. They talked about typography for pages of text, and gave professional — though standard — presentations about making the policy more digestible for people. We took a different approach.

"Pirates or ninjas?" Our first question to Michelle set the tone for our relationship and, as we learned, helped define the project.

Our design process always begins with opening up problems, exploring opportunities, and focusing on the concepts that stick before closing down on solutions. Long before we touch code or Adobe products, we reach for sharpies and paper. So we explored many ideas that we could pitch to Michelle. Such as:

  • What if we presented the policy as a video?
  • What if we offered "legal" and "human" modes?
  • What if we arranged the policy in Q&A format?
  • What if we formatted the policy as a storybook?

screenshot of the storybook format with helpful explanations

Screenshot of the storybook format with helpful explanations

Half-jokingly, we threw a ninja into the presentation. "A comic ninja who explains the legalese — wouldn't that be hilarious?" Maybe it would be too flippant. McAfee was a serious company, after all, and privacy isn't a trivial subject. But the ninja stayed. Why not?

To our surprise (and her delight), Michelle loved the ninja idea most.

New Ideas Need Extra Development

This format was the first of its kind, and by risking something new, we had to discover new conventions. So we took an extra week to second-guess the ideas and test assumptions. Several iterations later we settled on a storybook-like format. It was easy for users to learn and — most importantly — approachable.

The more we riffed on the concept of a fictional privacy ninja, the more unusual — yet plausible — our ideas became. The project became more than a single document. We explored:

  • A "build your own ninja" tool
  • The option for users to choose a character to defend their rights — super hero, ninja, or security guard
  • Using the ninja as content, not decoration. More infographic, less clip art in the margin.

Examples of the ninja art evolution. First, a pencil sketch with a face-concealing mask. Second, a red-suited ninja with a simple eye mask. Third, a refined version with stylish hair.

We went through a few iterations before finalizing on the ninja illustration.

Versions of the ninja became less cartoony, more realistic. But in the end we opted for our original simple cartoon that almost didn't make it into the presentation.

Unusual Ideas Need Support Before and During Iteration

While Michelle loved the unorthodox idea, we wondered how to propose it to others. How would they take it? Once again, we found that wondering about rejection was needless worry.

When Michelle presented the ninja idea to her boss, she was careful to explain that the "cartoons" were a means of communication, not a means of making the policy seem childish.

Illustration of a browser cookie explained with a chocolate chip cookie. There's also a cartoon ninja eating cookies, used elsewhere in the policy.

More than extras on the side, cartoons illustrated important concepts to users.

She also took the idea to the Federal Trade Commission. She said companies preemptively telling the FTC, "I"m taking a risk," was unusual. In this case, it worked. The FTC had never seen anything so creative in a policy — and they liked what they saw.

Michelle returned to McAfee with outside acceptance. The risk of a cartoon ninja — an afterthought and half-serious cartoon — was paying off.

Risks Pay Off in Unexpected Ways

Originally, we agreed that concepts and mockups would be our final deliverables. But later McAfee asked us to build out a working prototype storybook. Over two weeks we created a single-page microsite with animated, jQuery-based "pages." At the time, no one else had created reliable animation for the particular look we wanted, so the project's lead engineer took a risk and wrote his own.

Part of taking risks in design is knowing when they're appropriate. Storybook or not, the policy was a legally binding document. The legal team was adamant on certain phrasing. But while the legal text remained essentially the same, our new format organized it into easily digestible chunks. Graphics showed what text meant. And the ninja illustrations made the document approachable.

It pays to question assumptions. Even if the ninja hadn't panned out, it got us thinking. By suggesting "crazy"'ideas, we were able to open up the problem, break away from convention, and deliver something unique. You never know when a bad idea will lead to a great one. Like ninjas, great ideas don't appear unless you're willing to risk looking for them.


Pull the Trigger on User Experiences With Design Triggers

Alina wrote this on December 10, 2013 in . It has 55 reactions

Design is iterative. And much of product design is iterating on someone else's ideas. Strictly speaking, successful products are built (and innovated on) using patterns that have proven to be successful in other places — say, traditional marketing. And as it turns out human motivations work in similar ways online and off.

a couple of triggers

There's an almost unlimited wealth of research and data about human psychology, behavioral tendencies and intricacies. It's widely available to curious designers everywhere. And that's the challenge — it's literally "everywhere." The research is scattered across hundreds of resources and only the bravest of design souls are ready to dig through it.

Reining in the Research

If not brave, we're definitely zealous. We set out to collect psychological motivators in a resource library and, like much of everything else we do, make it available to anyone in search for product design literacy.

We call them Design Triggers.

We've spent about a year collecting materials for this newest addition to ZURB University Library. It turned into a unique collaboration between three product designers, each with a perspective on what the library needed to convey.

  • A designer with a Masters in Human Computer Interaction fleshed out the library's taxonomy, making it easy to navigate.
  • An engineer with a Masters in Applied Anthropology made sure our evidence was sound.
  • A Design Lead at ZURB was making sure we provide valuable and tangible advice and product design examples.

Making Triggers Make Sense

So here we were with a ton of really useful information, goodies that we wanted to share with the community, but not a great way to go about it. We had an epiphany after interviewing a few of our own ZURBian designers. They reminded us what we already knew — the best place to start a design concept is with a goal. That gave us the spark we needed to create a complete taxonomy around design goals and triggers.

We outlined a couple dozen goals designers may need to tackle in their interface, for example:

Showcase a New Product

We then highlight a set of triggers that can be applied to achieve this said goal. Triggers are tied to each goal through user scenarios to help designers explore ones suited best for their use case.

Demonstration, Conceptual Metaphor, Storytelling, Familiarity, Keywords

Each trigger has been meticulously researched. The evidence comes from sources in behavioral psychology, cognitive linguistics and consumer psychology, so designers can feel confident speaking to the value of each motivator in their next presentation.

Demonstration
The act of learning indirectly through watching and imitating others is called Observational Learning in psychology [1]...

Then, to give designers a starting point of applying a trigger, we outline some suggestions on how to use each trigger in product design.

Frame the demonstration from the viewpoint of the user and give a variety of examples, showing both what they should and should not do. Make the examples visual and interactive …

We take showcase libraries one step further by explaining why a particular example works, describing how a trigger is applied in real world.

"How to" from Indochino
Users are shown exactly how measurements are done with this service.

Triggers, examples and design goals all come together to give designers the background they need to make smart product design decisions and have the facts to back them up.

Another Tool in Your Arsenal

Being a product designer, among many other things, means understanding how users make decisions. That's what makes Design Triggers a really exciting addition to the ZURB University Library.

Unlike a design trend that may change in less than a year, triggers can provide decades of value. Be it skeuomorphism or flat design, providing the right hooks at the right time will create a meaningful experience for customers. Customers don't care if their achievement badge has a gradient or not, they are just excited to earn one.

Achievement is one of the better known motivators and is one of the design triggers we're starting this resource library with. Be on lookout for more triggers and design decision ammunition continuing to stream in and see how you can start pulling the strings of your customers' motivations with Design Triggers.

Check out Design Triggers


What Does the Fox Say? Introducing Our Newest ZURBIan

Shawna wrote this on December 10, 2013 in . It has 13 reactions

After hearing that song a lot at ZURB HQ, we've finally learned what the fox says. He says he's glad to be our newest ZURBian. Without further ado, let us introduce you to …

Alex Fox, Designer

photo of product designer Alex Fox

Our newest ZURBian is an industry-hardened design cowboy from Dallas, Texas. So of course he loves good music, better barbecue and harbors a reputation for awesomeness.

As far back as Alex can remember, his life has revolved around technology. The many ways that devices enrich our day-to-day lives has always fascinated him. The best part for Alex — design is at the forefront of it all. For the past five years, he's sailed the high seas of agency life as a designer in print, web and everything in between. That experience helped him craft his arsenal of design skills.

Design has always been a huge part of my life. Even as a wee lad, I had a deeply profound passion for building new and interesting things. As I grew, so did my passion for design. Legos became logos, web apps and so much more.

When Alex's not mashing keys, he enjoys exploring the various eats and activities in the Bay Area. So please everyone welcome Alex!


Upping Our Ante on Visual Design

Alina wrote this on December 06, 2013 in . It has 70 reactions

We've been talking a lot about frameworks lately, whether it's a responsive front-end one like Foundation or an email one like Ink. One of the advantages of a framework is that allows product designers to worry less about building across devices and spend more time improving their skills. After all, for a designer, there's always a new skill to learn or improve on.

For our team of product designers, the skill to keep pushing has been visual design. Our projects have always had a simple set up: one designer, one design lead. Since each designer owns the whole project from start to finish, they owned the visual exploration phase as well — until about a year ago. That's when we decided to spice things up and split the exploration between three designers, giving the team an opportunity to learn from each other. Which incidentally allowed us to show a greater variety of options to our clients. Everybody wins.

visual design

It was a great idea. We saw a big increase in the overall level of visual design skills here. Though to be fair, the improvement was mostly evident among the designers who volunteered themselves the most.

Now we're iterating on this process again. To see how we can level up the entire team. We're mixing a bit of the old with the new — putting the pressure back on project's designer to own the majority of the exploration process, but giving fellow designers an opportunity to inject a bit of creative spark into it.

Keyword: Exploration

Clients always want options. Distinct, viable, amazing options. Creating distinct, awesome options is hard. Many designers tend to fall into their own comfort-style and getting out of it means to challenge your skills. It's difficult. And absolutely necessary for the first exploration pass.

Our new approach has the project's designer creating six to eight quick-and-dirty layouts — we call them directions — in about three hours. This pushes the designer to think in broad strokes, keep moving and not fixate on details that don't create value. In the end, each direction must have a unique point of view, a story.

explorations
Explorations from a past project

We found that when a design direction doesn't tell a story, it becomes impossible to defend and get buy in from stakeholders. When the only distinction between options is the color of the top-bar or header font, you can find yourself in a debate over personal taste versus what the visual says about the product or user you're designing for.

Bit of Healthy Competition

Somewhere deep inside every designer just wants validation that he's good designer. We want to see how another designer solves the same problem (and gauge our solution against theirs — we know you do that too). We saw that when we pitted designers against each other, they pushed themselves hard to design something the others would admire.

We also noticed work getting better overall. Our visual design rockstars were teaching others their craft without even realizing it. Simply by explaining their process and how they made design choices — typography, color, imagery, all the little details that make a design unique — they were influencing how less experienced designers tackled their next project.

From the first exploration of six-to-eight directions, we pick the three most promising and divvy them up between three designers. They are asked to iterate on the direction, not start from scratch. Why? Because the story has to hold up after they're through with it! After a day or so of work, we reconvene and review the work. We talk about it, are brutally honest with each other about what works and what doesn't. Then we go back to make it better.

Dishing It Out and Taking It

We have become super adamant about using design terms and principles when giving each other feedback. We can't just say "This typeface doesn't work." We have to say why. This forces us give concrete reasoning for our feedback — maybe the font is illegible or doesn't complement some of the iconography — that actually gives the designer something to work with!

By looking at each other's work and critiquing it, designers started seeing their own layouts in a new light. After you comment on someone's margins a couple dozen times, you start paying attention to yours. It's just natural.

Plus, giving each other feedback has given us ammunition for presenting work. We have trained each other to validate design decisions and preempt questions the viewer (say, a client) may have. We have fun practicing these skills too. During our weekly design team scrums we often play a feedback game, changing up the rules every time, like:

  • Two teams take turn giving feedback on a layout. Team who uses the most design terms wins!
  • Paired up designers have to give feedback together. One person starts and the other has to finish their thought.
  • Break designers into two teams. One has to defend the design, the other has to tear it apart.
  • Designers randomly pick flashcards with design terms, which they have to use in their feedback.

Hey, we like to have a bit of fun with our work. Well — a lot of fun.

We play pass-the-pig, as we take turns giving feedback during design team scrum.

It's Not Always Talent. A Lot of It is Just Practice.

If we had learned anything from changing up our visual exploration process is that designers can have tremendous growth by practicing visual design skills. That's because design is not art. Design is solving problems through a visual language. And you can get really good at solving design problems by tackling a lot of them, and often.

The only way you can improve — well, just about anything — is to get feedback, iterate and get feedback again. Being open to other designers' opinions and practice actually makes you a better designer — we've seen it work wonders in the last six months. We have a super passionate, committed team. We encourage and push each other. And every single project is upping the ante on the one before.


Companies Need a Responsive Front-End Framework

Bryan wrote this on November 27, 2013 in . It has 50 reactions

foundationbusiness

The response to our Foundation 5 launch has been incredible. Over the first 36 hours, we had 190k visitors to our properties and 800k pageviews. The average time on Foundation was seven minutes. We reached 180 countries and territories in that time. Keep in mind, this is an open-source code project! It's amazing to be part of a project that millions of designers and engineers use on a daily basis.

What We Learned From Foundation

We've learned quite a bit about frameworks over the course of five Foundation releases. The first, and most valuable, is that creating something of value takes time. Lots of time. Foundation is now over two years old and we've committed and removed thousands of code bits. We've answered countless emails. Since April alone, we've answered over 3,000 cases via email. The ZURB team has been incredible and stepped up to support the community. And that's just email support. We've made over 5,000 code commits with the help of the community, toured the globe speaking at events and hosted lots of meetups for our fans.

The second thing is that we can provide even more value by creating revenue streams that support its growth and ensure its success (all the while continuing to keep the project open for the millions worldwide that depend on Foundation). Projects like Drupal, Wordpress, Ruby on Rails, and Node are examples of open-source projects that have companies who are heavily invested in the code and community. Based on our experience, we believe most companies would prefer to use an open-source framework and pay for services, instead of managing a costly solution of their own.

HTML and CSS Still Rule

With the proliferation of devices over the last couple years, companies understand that they need to create products that meet the growing demands of users — sitting in front of a desktop computer won't be the primary use case for customers. Heck, looking at a phone may not be either. iOS and Android are exceptional platforms that companies will need to invest in, but the open web will continue to be a huge part of what users expect as well.

HTML is now over 20 years old and CSS is not much younger. Technologies have come and gone, but these two have continued to survive. With more "dumb" and smart devices emerging, we're firm believers that companies will depend on these proven technologies for their visual interfaces. Which means that companies need a way to manage how they produce their interfaces across all these devices.

Front-End Frameworks to the Rescue

It was clear when we developed Foundation that we needed a way to standardize our coding approach across our company. As early as 2007-08, we were starting to standardize our approach to make it easier for everyone on our team to contribute to a project. Standardization and speed were two huge benefits. Our style guide also encouraged best practices.

By early 2011, we had built the first version of Foundation and collected a lot of feedback. It was clear this was huge for people who built applications and websites. But with mobile growing, we knew that our framework had to be responsive. Foundation 2 was the first responsive framework. We followed this up by introducing Sass, semantic markup, and a mobile-first approach in the next versions. We learned a lot — what to do and not to do when it comes to standardizing our approach. Creating a code base wasn't just about the code, it was an operational problem that required getting people to accept a solution. Now that frameworks exist, it's much easier to get a team onboard with the concept.

It's clear from our experience that companies need a framework for their front-end development. It's simply too costly and painful for companies not to have a standard. Whether it's a custom implementation, pattern library or pulled code from an open-source framework, it really doesn't make much sense to hand code everything. And yes, we understand the purists will shout out. But we believe the need for most people to create front-end code may not even exist in the not-so-distant future.

Providing a Professional Solution

Creating a framework can be a costly endeavor, it makes sense to adopt an open-source solution for most companies. Open source is a choice many companies make, but that's an argument that you either believe in or not.

With our latest release, we're making it easier for companies to invest in the Foundation framework as part of their development stack. Our Foundation Business group is now providing support, training, consulting and products to support these companies. As part of this effort, we're also supporting our new responsive email framework, Ink.

We understand that for many companies making technology decisions aren't easy, but for those companies who are already invested in Foundation or want to make the switch from their own set-up, we're giving companies the peace of mind that they're not going alone. If your company is interested, please check out our Foundation Business site to see how we might be able to help you.


Get a job, nerd!

via Job Board from ZURB