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.
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?
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.
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.
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.
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.
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.
The act of learning indirectly through watching and imitating others is called Observational Learning in psychology ...
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.
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
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!
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.
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.
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.
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.
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.
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.
The final countdown to the release of Foundation 5 has already begun around ZURB HQ. And we can't wait to hear what y'all think. Whether it's via email, tweet or Github, we enjoy hearing from those using our framework. We also love it when we can meet face-to-face like at our Foundation meetups. Which is why we're really excited that next year we'll be going on a World Tour. We'll meet with our global audience and learning how they use Foundation to solve product design problems.
For two months in 2014, we'll pack our bags and jetset to 15 or more international locations, such as Melbourne, Buenos Aires, London and Munich. We're taking product design on the road so that we can go where our customers are. And with the global attention Foundation has garnered since its initial release in 2011, we could no longer sit still in our comfy chairs from little ole Campbell anymore.
Something Magical Happens When Meeting in Person
Airbnb's Joe Gebbia told us a fantastic story once about the importance of meeting your customers. One day, Y Combinator's Paul Graham took a look at the plans for Airbnb and told Joe and his fellow founders that it wasn't going to work. Then he asked them a simple question, "Where is your market?"
The founders said New York. Paul then gestured wildly and said, "Your users are in New York and you're here in Mountain View. What are you still doing here?" So Joe went to New York and met with his customers, learning more about his own product than he could've learned sitting in Mountain View.
Meeting other product designers, whether individuals or large teams, gives us more opportunities to learn about the problems their trying to solve. We also want to learn how Foundation fits in people's workflows. And we've found over the years that when we go speak somewhere and meet people sparks even more ideas on how to improve our products. Magic happens when you can directly see how your customers use your tools.
On the Road Learning
We built Foundation and our product suite to help others build better products that work faster on any device. One aspect of our latest Foundation release is faster learning. We've rewritten the docs with more detailed and new code examples, a new Getting Started guide and a forum to get help from other Foundation users. Why? Because learning is very much who we are. It informs everything we do.
One of the reasons we're going on a World Tour is to have a product design exchange with other companies. We want to learn how other people practice product design, and show them how we approach it. We're also game for on-site product design training, including tips on Foundation, as part of our ZURB University efforts. Or if we want, we can tackle a practice three-day project that accomplishes design goal using our Design Process.
We'll also host meetups for both Foundation and our new responsive email framework, Ink. We'll chat about where we're going next and give tips on using our frameworks.
Want Us to Come to Your Town?
We've got a handful of cities already on our hit list, and we're looking for a more. We'd love to drop in. Tell us a bit about your company and the type of event you're interested in, so we can start planning our time together.
We're pleased to see Foundation continue to grow by leaps and bounds. And as we're poised to launch Foundation 5, we're happy to announce that we've added a new ZURBian as our second Customer Advocate who'll be working with our Foundation fan base.
Without further ado, we'd like to introduce you to ...
Rafi Benkual, Customer Advocate
You can blame Rafi's great passion for cutting-edge technology on his dad, a hardware engineer. Rafi was born in Israel but spent much of his life growing up in Silicon Valley. His love for technology really blossomed in high school and he never looked back!
Before joining ZURB as our new Customer Advocate, Rafi managed people, stores and small organizations. You can say that Rafi has been helping customers for a long while now. In fact, he's quite passionate about it. And he's happy he's found a place at ZURB, which shares his passion for customer advocacy.
I have learned so much about design recently and love the industry. I can't wait to be involved in exciting and challenging projects at ZURB!
As a Customer Advocate, Rafi will focus on Foundation. He'll answer any questions you have about Foundation and solving any problems you might encounter. You can chat him up on @foundationzurb or at [email protected].
Rafi keeps himself occupied outside of work. He claims he's never bored. That's because he's always active. He plays soccer, and when he's not kicking goals, he mountain bikes and rock climbs with his fellow ZURBians. His favorite movies are anything to do with science fiction or espionage. And he's quite a handy fella, building computers, portable speakers and furniture.
So please everyone give a warm welcome to Rafi!
Today we updated our Studios website. For those who hadn't noticed, we changed the generic name from "services" work to Studios this past summer. With the evolution of our business, it was a great opportunity to highlight our core competency and reinvigorate our team.
The video that greets visitors to our new ZURB Studios site.
Why the Name Update?
We're four years into the evolution of our business strategy. As we push to build out the remaining parts of this strategy, it's important to focus on what got us to this point. "Services" didn't quite capture that. Studios does. It better reflects how we think of our work. Why? Because we're collaborative and creative, working alongside clients at every step of our design process. We don't do big "Mad Men" reveals at the end of projects. Services doesn't imply that close, collaborative, creative relationship. But Studios does. It's where good stuff happens.
At ZURB, we enjoy tinkering with technology, exploring paths that could lead to the next big thing, like our upcoming responsive email framework. A studio is where you toil over your passions like we do. It's where great things can happen. Where a chance conversation can ignite sparks. And a studio feels small, more intimate, which mirrors our project dynamics. Our consulting projects are typically teams of two people — a lead and a designer — and rarely have more than three.
But the biggest boon of the name change: it reflects our ability to get stuff done. A studio implies focus, and that is central to our growth. As we grow, we want the focus on this ability to remain a lynchpin of our business. And Studios, as a name, just felt right.
We got positive reactions whenever we talked about the Studios name internally. The name evokes a place as much as it does a concept, and that's important. That's because unlike some businesses that push for remote workers, we opt for a place where people want to visit and collaborate. A studio you can visit. Santa's studio, a recording studio, a movie studio — all are magical places where great things happen.
Finally, it allows us to clarify our consulting and differentiate it from our training and education, which is now called ZURB University. As we grow our Foundation business, it helps to differentiate design projects from the support and implementation help we give to customers.
A Site Update That Further Gives Identity to Our Consulting
With the site update, we wanted to make clear what we do as a Studios service. We wanted to highlight how our process works and outline what makes our projects strong. We gave new polish to our case studies, which we haven't been good at keeping up-to-date. Since product design can be a bit messy, our new case studies reveal more about the sparks our work creates.
We've also put a ZURB face to the work we do. Sprinkled throughout are quotes from our team, bringing out the human quality in our consulting. A video montage captures the mood and feeling of our Studios, so you can get a sample of the magic we create.
With the update and the new name, our consulting service has solidified into a place as much as a concept. A place where great things have happened and will happen for years to come.
This summer we were thrilled to have an amazing group of design and engineering interns. But now, as September approaches, many of them have gone back to school. One or two went on to full-time jobs.
But sometimes our interns won't go away. They keep working on projects, happily showing up each morning and staying after hours. Their time at ZURB ends but they still want more. That's when we stop calling them interns, and start calling them ZURBians.
Eric Morris, our newest developer, is such a dedicated new hire. Born and raised in the snowy expanses of Upstate New York, Eric migrated to California in search of a place where he could build things and change the world with product design.
Prior to arriving at ZURB, Eric had worked as a designer, a developer, a social media marketer and a freelance photojournalist (not all at the same time). He loves building things and solving problems — almost as much as he loves working with people.
While at Cornell, Eric helped run POPSHOP, an entrepreneurship co-working space serving the Cornell community (he also designed their website, which is featured in the Responsive Gallery). His fascination with entrepreneurship extended to working for a few startups, as well as helping to found one.
When he's not programming, designing or dreaming of a better future, you can find him hanging upside-down off a rock wall or biking — but not too far. We need him to carry on the project he started in May.
Design is in the DNA of our newest designer. She was pre-destined to be a designer since her pre-school days when she was awarded "Most Cheerful and Dramatic Artist." Of course, she told us that she would get in trouble for drawing and doodling rather than paying attention in class. Now, as a full-fledged ZURBian, she doesn't have to worry about sketching. After all, it's part of the job.
So without further ado, please welcome Jessica Phan to our team!
Jessica was born in San Francisco, but spent her childhood in a small South Carolina town. She came back in the Bay Area for high school where her biology teacher encouraged her to study design and illustration. That's because her lab results weren't great. However, the teacher thought her chromosome sketches were spectacular. With that motivation, Jessica ended up at San Jose State to study design. She briefly worked to get her MFA in Graphic Design, but dropped out because she wanted to expand out of print and explore the wide world of the Web.
She then became a Photoshop wizard and ecommerce nerd for an internet retailer company, but eventually made her way to us. So everyone say hello to Jessica!
Read up on the latest