Posts About Business and startups sticker Business and Startups
Business and startups sticker
Posts About Business and Startups

Stuff Isn't Culture

Shawna wrote this on February 20, 2015 in . It has 174 reactions

perks

Perks don't create loyalty and those things don't get people invested. When we talk about perks, we're talking about stuff. You know: the pool tables, the cell phone, the fridge full of beer. But those are "benefits," not culture.

And that's exactly what dozens of articles focus on when it comes to culture — the stuff, the nice-to-haves, such as an inspired workspace and healthy food options. But focusing on perks might not keep your workers from fleeing for greener pastures. Take a look at Google. The search engine giant has one of the best perks in the Valley hands-down but one of the highest turnover rates with the average employing sticking around for a little over a year, even with pay in the six figures. Google isn't the only one. The average stay at any job is nine months, according to a Payscale survey. Even Amazon employees bolt after a year. Although a few have called shenanigans on Payscale's methodologies, saying it's focused more on tenure than actual turnover. But whatever it is, folks are leaving the building.

Is it just a symptom of the current generation of workers? Where people don't necessarily commit, where a date (or new job) is a swipe away? Possibly. Another study shows that the current Silicon Valley workforce is committed, working long hours. But they remain independent, and the name of the company isn't all that important. And 57% of those surveyed say they constantly receive offers to work elsewhere.

So perks may not be what keep someone around. Even if those jobs perpetuate a culture of distractions, where it attracts talent solely by showering things upon them. Yet then why aren't those people staying long? And are those cultures really creating value when the next big thing is a recruitment call or LinkedIn mail away?

Values is Culture, Not Things

Building core values and core purpose can have lasting effects. Let's take a step back. What are values? Values are company expectations of how you want the company to be, or better yet how your team interacts with customers and each other, which then need to become socialized within your culture. They set the bar as a baseline that spells out everyone's roles within the organization.

We're not talking about motivational poster stuff here. We're talking about things that matter to an organization. Twilio avoids putting its values — the Nine Things — on the wall because it needs to be articulated. As Jeff Lawson told us at his Soapbox:

You don't create them, you articulate them because they have to be something that's already there. If you create them, then they're just nonsense on the wall. If you articulate them, they're real and all you're doing is stating what's there. Because if you don't put a spotlight on them, you're at risk of losing them.

A value that works for Twilio is "Draw the Owl." It breaks down to this:

  • Step one: draw some circles.
  • Step two: draw the rest of the f'ing owl.

The value creates a culture of doers, not sayers, where everyday an employee has to figure it out because there's no instruction book. And it's something that's engrained and discussed at Twilio. That's what we define as a value here.

Values become the building block of your culture, as our friend Moz's Rand Fishkin told us by email. Moz's values informs who they fire and who they hire, and how they go about their day-to-day business. At Moz, they have what they call TAGFEE:

  • Transparency: Moz shares what they do and learn in the open, even when it's not great news.
  • Authenticity: They stay true to who they are and don't pretend to be other people.
  • Generosity: Moz tries to give more than they receive, spreading goodwill in all their interactions.
  • Fun: Rand says work shouldn't just be work — it should be enjoyable. And if it isn't, then something's wrong.
  • Empathy: Moz's most important value. They place themselves in their customer's shoes so they can understand and solve their problems.
  • The Exception: If someone else is doing it, then Moz works to find their own path.

So how does Moz get their values to stick? Rand says:

Thankfully, at this point, they've become part of how everyone at the company communicates, though building that up was no small challenge. We want TAGFEE to infuse our decision making around everything, so it's the (often spoken, but sometimes unspoken) criteria in any meeting or discussion. Over time, we've had to prove this again and again by doing TAGFEE things when they're hardest and when sliding on them would be the easy or more profitable thing to do.

Which goes to show that values have to apply to everyone in an organization, no matter their role. No matter the type of business your company's values need to apply to the whole team. You help create accountability and people feel more connected when the company is inclusive. You don't want to create a "that doesn't apply to me" situation. Those values are there to help you be successful at your job. Or how you'll be successful at your jobs. Your company values literally could be your company's "commandments" — thou shalt be open-minded. And like the commandments, these give you a pretty good idea of how to be at your new company.

They have to be specific so they can be applied, like "Be a Coach" or "Build on Opportunity" or "Draw the Owl." They have to be specific enough to get the point across and vague enough to apply them to any situation. If not specific enough, it may be hard for someone to enact. If they lack in clarity your team won't be able to apply them you their work. They'll do it 'their way' which may or may not align with the company, and even the best intentions can have negative effects to the team.

Leaders Are Needed to Make Values Stick

leaders carry the weight

Both values and leadership are very much tied together. Values only work if there's leadership to support it and carry the weight. As Rand puts it in a previous article he wrote on this very subject:

If you're trying to figure out what a company's values really are, look at the decisions management makes when lots of money, risk, or loss of face for executives is at odds with the stated values.

In other words, Rand is saying that actions speak louder than words. That is why leadership must agree to the values then apply them daily. There has to be 100% investment by the leadership team. They have to be on the same page. But it's an ongoing dialogue. You have to have a back-and-forth on these values. Not saying that the values should be constantly changing, they shouldn't. If revisions need to be made have the conversation and everyone needs to agree.

Build Trust Through Values

Building off what Rand said about actions speaking louder than words, leaders have to build trust through practicing and living a company's values. Living the values instead of paying lip service will help build trust because you'll make a connection with the team. And leaders need to get involved with the team on a "professionally personal" level. They need to be empathic in terms of understanding how a team makes decisions. That means talking problems out, asking questions and when possible using real stories from your past that were similar and what you did to overcome those problems.

If there's no trust, you can't share values. If your leaders are unable to show their vulnerability to the team, then they won't have the team's trust. If employees are unable to connect with their leaders, it's likely they'll leave soon after.

A leader's past behaviors, along with capabilities, goes a long way to building trust. If past behavior goes against the grain of a company's values, trust won't be built. If a leader can't practice or live the values, they don't fit in the organization. Plain and simple. Eventually it will become a bad fit. You can only fake it so long with core values. And depending on your teams size the wake left from poor leadership could really negatively effect your team.

This is even more magnified when you have a culture based only on things. You can't cover up poor leadership with stuff. Bad leadership IS bad leadership, just with a pool table.

The Contrarian of Values

contrarian of values

The worst thing a company can have is a leader "contrarian of values." That poisons the well, and the team doesn't know who to follow. A contrarian works against the organization, either knowingly or unknowingly. Depending how much influence this person has in a team, the contrarian can quickly undo a team dynamic. This person is an opportunistic predator who will pray on the benign frustrations of your team. They want to feel "right" in their thinking and will want to attract people to their way of thinking.

A contrarian can create a toxic environment. It can damage your team depending on how strong your culture is and the overall long-term satisfaction of your employees. Weaker team dynamics will fall victim to these ideas. Even if the toxicity is removed, those seeds are planted. This is another reason strong culture and leadership is really vital to a healthy team.

An organization has to compensate before the negativity happens. Setting company expectations early and having leadership accountability is a great start. Ideally your team is healthy and is able to see that the contrarian is not contributing to their growth/experience and is, in fact, taking away from it.

Values You Can Build On

values you can build on

The company culture should be built from the values. They are the foundation. It would be challenging to "roll out" values like an afterthought because that's how the leadership and then the team would view them. And if they aren't working, look to your leadership. Are they "living" your company values and spreading them throughout your teams? How important is it to you? If there is a breakdown in leadership, then look to yourself too. And if the values don't work, it's either training opportunity or it isn't a good fit. You have to be prepared to handle both. In the end, your culture is what you make of it and your values are the first step in defining it.

We want to thank Rand Fishkin for his insights on this post!


Engineers Don't Build Products, They Design Them

Matt wrote this on February 11, 2015 in . It has 171 reactions

In one of our Chief Instigator's previous posts, we talked about how we can no longer think about design as being purely the domain of designers. Everyone on your team needs to design, especially your engineers. In fact, if you take a look, you'll most likely find that your engineering team is already making the majority of your interaction design decisions.

developer plans

Creating Product is Like Creating a Building

There is a fundamental misunderstanding about the role the engineers play in building products. Let's articulate this with an analogy.

Creating a product is like creating a building. You have an architect that defines what the building should look like. He imagines the building and creates a design for how the building should look and function. The architect works with a structural engineer to create a blueprint defining how the building should be built based on an understanding of the constraints. At the end of the process, a team of experts with tools come in and assemble the building based on the blueprint.

Just like in the digital product realm, you've got a product manager that works with a designer to create the technical specification, and a team of engineers that uses the specification to assemble the product. Seems like a clear analogy right? It's close, except for one critical detail.

Engineers Don't Build Products, They Design Them

When you build a web application, your product is not the code. It's the page that gets served up to a person's browser. Your engineers are not sitting in a room, waiting for a person to navigate to your site and then build them a web app — that's what the computer does.

Imagine if an architect could just use a massive 3D printer to assemble a building — that's what software engineering is. People come to your application and, based on the code defined by your engineers, a product is assembled for them while they wait a whole second or two.

blueprints

The Right Analogy

There is no one person who sits alone at a big desk and defines every last detail or interaction, it's just not how it happens, in software or architecture*. When products are done well, they're the results of a team of people working together to produce the definition — i.e. the software — that will be used to assemble the product.

Someone might play the role of the business owner dictating what the purpose of the building should be. Another may be a sociologist offering ideas of how the building can best serve that purpose. A structural engineer will make sure that the building can actually do the things the others are suggesting.

* I have no idea if this is true.

A Real Example

foundation collaboration

Back in 2011, I had the privilege of working with some great people on the first version of Foundation, our responsive web framework. We functioned as a team and my responsibility was the JavaScript. We were creating new components that were going to be used by millions of people. The interactions needed to be solid or what was the point?

How did we do it? Our designers certainly didn't create a spec. It started with some loose conversations as to what kind of components we needed to have. There were some existing plugins we had written and some new ones to be added. Once I had a loose idea in my mind of what we wanted I got to work.

The first iteration was created and one of the designers tried it out. He tried it out in a way that you can't try out with a specification or a wireframe. He clicked on it in funny ways, resized the screen, right clicked it, got it into funky states, all while I was sitting there taking notes. I went back to coding and incorporated his feedback, making tweaks or changes weighing the value of an interaction with the cost to implement it.

We repeated this numerous times, mostly just the two of us, until we got to a place where it was time to launch (if you think you'll ever get these things perfect, you're not looking hard enough).

Say Hello to Interaction Design

Interaction design is where user needs and technical feasibility overlap to create an interaction that solves a person's problem (typically at a very small level) and also, well, works. It's not just about fighting for the user, it's also about being able to ship something that actually works.

user needs and technical feasibility

In most cases, this is what your engineers are actually doing when they are building code. Sure they are solving a lot of technical problems, but with modern languages and frameworks making this easier and easier, they are probably spending a lot of time filling gaps in the definition they were given. There is still a substantial set of skills required to write code, but maybe someday soon we'll close this gap architects will be printing buildings from some sort of moon base.

3D-printed Buildings? You, Sir, Are Crazy

Less crazy than you think. Disney California Adventure has a portion of the park that is modeled after Radiator Springs from the Pixar movie cars. The red rock walls are incredibly detailed and large, presenting an execution challenge to get builders to create the walls as Disney Imagineers wanted them.

To solve this, the Imagineers (notice the engineers part of that title) designed the rock walls using software and then shipped them to a company that used computerized machinery to fabricate them directly from the designs.

Engineers Make the Best Interaction Designers

OK, let's be real for a second now. Good designers do know a lot about how products work (if they are T-shaped) and can certainly make large decisions without having to understand every last detail of the code. But what about the really detailed decisions that can add up to something big. Think Disneyland. Great product through amazing execution on all the details.

You can't define all the interactions of predictive type ahead without understanding JavaScript. How can you come up with all the states that someone can get into if you don't know how the code itself works?

Engineers are fantastic at solving these detailed problems because they can push the available functionality right to its limits and not waste time exploring things that are impossible or prohibitively expensive.

Know Your Medium

Imagine an artist creating a piece of work in some medium like copper. Now imagine the artist knows nothing about copper and is telling some guy with a blowtorch how to to put it together.

"No no, it needs to have more pop! Maybe it you get the thingy on the right really hot and then grab it with your bare hands."

The end result is going to be second-degree burns and a piece titled 'The Mediocre Result of Piss Poor Collaboration.'

So You Want Me to Teach My Designer to Code? That's So Last Year

Basic understanding, yes. Full-blown unicorn, no. There is a lot to know when it comes to engineering, and running through a couple classes on Team Treehouse does not make you a full-blown engineer. But don't sweat it, start small and keep an open mind.

Start simple with HTML/CSS. It's the medium in which web interfaces are designed, and if your designers are still delivering finished interfaces in Photoshop or Wireframes, there is a big gap in the definition you're asking your engineers to close.

The next step is JavaScript. jQuery is a great place to start, as it allows you to start defining behaviors. The more complex interactions in your product are going to be JavaScript, and it's very likely they are going to be some of the most important interactions you deliver.

Stop Wasting Your Time With Worthless Specs

shredding the specs

Let your engineers do this in the code, because that's what it is for. Get your designers working with your engineers to ask them questions about what's possible. Push them to experiment and give honest feedback on what they come up with.

We've seen (and heard) this many times. A design team spends countless hours putting together a very long, very detailed document explaining how everything should work. They zip it up and send it over to the engineering team. After an appropriate period of time has passed, a product is completed that bears little or no resemblance to the original specification.

Why does this happen? Are your engineers stupid? No, products are complex, and even the most detailed specification will have inconsistencies, gaps, and leave room for interpretation. Ever played telephone art direction? It can turn out kind of like that. Describing something is different from defining something, and the more room you have for interpretation the easier it is to describe something that is not possible.

Don't Let Engineers Design Alone

Engineers can be great interaction designers, but they also need sparring partners. Any time you leave a person to their own devices they tend to settle more easily. Working in small teams creates excitement and a sense of accountability. To avoid that accountability turning into hostility you need to ...

Develop T-shaped People

Rather than trying to get your designers up to speed on engineering, or teach your engineers everything there is to know about design, strive to create some overlap. Having some expertise in common makes it easier for teams to communicate. You are trying to avoid the 'throw it over the wall' mentality.

Specifically Though, What Are We Supposed to Do?

developers collaborate on interactions

Here at ZURB, our designers work with our engineers to define our products. We use sketching as a tool to present ideas and get feedback on what's technically feasible and how it will play with any existing functionality. Typically we work in pairs, one designer and one engineer.

Our designers create static prototypes in HTML/CSS (T-shaped!) to demonstrate the functionality and give them complete control over visuals and layout while still working within the medium (no burn wounds here).

The screens are annotated using our Notable tool to explain ideas that are not obvious from the prototype itself. This is also used to demonstrate how multiple pages come together into a flow. From Notable, the engineer can give feedback to the designs on pieces that might not work right when implemented.

The engineer hooks up the static code that defines the detailed interactions in the code itself. Interactions include actions like what gets focused when a modal opens or where is the user redirected to when they try to access the page while logged out.

Once implemented the designer can play with the functionality and make changes to the design, layout and messaging, or go back to the engineer for another pass at the detailed interactions.

This loop continues until the pair are happy with the result, and then it goes live.

Honestly, We're Not Fully There ... Yet

We want everyone at ZURB to continue to learn, year after year. There is nothing more dull than performing the same tasks day in and day out. For our engineers we want them to go even further than just learning a new programming language.

By working side by side with designers, engineers certainly pick up a lot of skills around visual and interaction design. However our vision goes even further than that. We want our engineers to be the ones pushing our designers when it comes to interaction design. Setting the bar and defining the patterns for new interactions.

Being a maker or a craftsman is more than just doing something the right way, it's about putting your mark on your product. And to do that you've gotta make some design decisions. We want our engineers to have that opportunity. We believe it's a more fulfilling career, and produces superior products.

We're certainly not all there yet, there's a lot to learn just on the engineering side alone. But we strongly believe this is the right way to go, and we're going to keep chipping away at it.


Foundation 5: Almost Here, and Sweet for Large Teams

Ghaida wrote this on November 20, 2013 in . It has 100 reactions

Foundation for Large Teams

Foundation 5 is upon us (like, tomorrow), and it is a faster, stronger, better Foundation. That's great for the millions of designers and developers using it in their workflow. More users mean more exposure to a different type of user — a type that is often overlooked by framework designers.

Larger teams have different needs from a lone designer or developer. There are a lot more variables for them to juggle: many people, each with their own goals; dealing with rigid business goals; and dealing with legacy code.

We're addressing those needs with Foundation 5 and beyond in several different ways, each focusing on a particular problem. We've kept Foundation true to its core value — to be a smarter way to code.

A Culture of Smart Coding

Create a culture of smart coding in your company. Foundation is mobile first, and coding the Foundation way will introduce your team to better coding practices resulting in leaner, meaner, code. We've seen this first-hand with larger teams and companies.

For example, we recently helped a client wireframe their entire application, some 50 unique screens, with Foundation. And that gave their development team a common starting point to build upon. The bonus: It helped them put together all the interactions and workflows within a short period of time. Which allowed them to focus on iteration and design problems rather than putting an interface together.

But it's not just our clients. We're seeing large organizations, such as the Washington Post, adopt Foundation. The Post uses Foundation to help them prototype and cut out day-to-day drudgery, such as not having to start from scratch each time they build a site. But it's also taught their front-end developers to write better code, Mobile Design Director Joey Marburger told us. Developers can work on shared code and trust that it'll work. It's allowed the paper to establish better development standards for both prototyping and building products.

How Foundation Fits Within ZURB

A framework, such as Foundation, is crucial for a company like ZURB. Why? Because it allows our business to build consistency in how we approach our development effort. Here are some ways it's helped us.

It gives us a framework to rapidly prototype our products and ensure they work across devices.


wired

Our team and volunteers using Foundation during this year's ZURBwired.

We use Foundation for our yearly 24-hour design marathon, ZURBwired. During the event, there's a cadre of volunteers that works alongside our team. Foundation becomes the common glue that allows us to quickly jump into pages and commit code. With the framework, we're able to move swiftly from sketch to prototype to production code without missing a beat.

Our consistent code base reduces our overhead so we don't have to maintain code for separate mobile and desktop sites.


We'll admit we're still moving to a mobile-first approach across our projects. While it's not always possible, the fact that Foundation plays nicely between screen sizes is huge for us. It's easy for us to switch between a mobile-first approach and designing from desktop down.

Finally, Foundation also brings standards in the way an organization QAs their products.


QA spreadsheet

Our QA spreadsheet for the Foundation 5 marketing site and docs

We battle test Foundation daily at ZURB on every client and internal project. From code to QA, we've been able to create consistency in our process. In fact, we're in the midst of that process right now as we work to get Foundation 5 out the door. When 10 people are working on QA, it makes it easier to understand the issues. For Foundation 5, we have a large spreadsheet that people can easily follow and contribute to (see above).

Those are some of the ways Foundation has helped us out. We'd love to hear how your organization is using Foundation and how it fits in your workflow. Hit us up at [email protected]. Stay tuned for the release — it's gonna be a blast!


We Feel the Need ... the Need, for Speed: What's Ahead for Foundation 5

Jonathan wrote this on November 13, 2013 in . It has 375 reactions

You've probably noticed that we're kind of big on responsive design here at ZURB — we've written about it, talked about, we wrote the first framework for it. On top of all that, we design responsively for just about all of our properties and clients. As big as we are on responsive, and as prevalent as responsive design has become recently, it's important to remember that responsive design isn't old.

Ethan Marcotte's article on Responsive Web Design for A List Apart is about three-and-a-half years old now and while that may seem like eons in Internet time, in real world terms that's not a whole lot of time. And certainly not for an entire industry to catch up. Responsive design is still catching on, and being explored while being defined to a large extent.

If you take a look at the top 20 worldwide sites according to Alexa, only one (Wordpress.com) is responsive. While some have mobile sites they direct you to, responsive, device-agnostic sites are not ubiquitous yet and that's okay. We still have some things to figure out.

Patterns, Practices and Patches.

We do have a lot more toys for responsive design than we used to. Frameworks have popped up (including our own — one of the first), pattern libraries have been created. Most of the technology has been put in place within industry specs and browsers to ensure that responsive design works well and solves real problems for developers and users.

Responsive design has even driven interaction patterns that have become common for responsive and even non-responsive sites. Things like off-canvas navigation and the now common "hamburger" icon were either developed for, or popularized by, responsive design and sites using that paradigm. So what's next? What's missing?

Speed, Baby. Speed.

Everyone likes fast stuff. Well, almost everyone. And responsive design, for all its awesome qualities, does suffer from a speed problem — and not just speed of delivery to users. Responsive design does have speed of delivery (read: optimization) issues that are starting to be solved, and we'll talk about those, but we're also talking about speed of development and speed of responsive design education.

The rate of advancement on the Web is accelerating (in stride with the pace of the Web) and in order for us to keep up we need to pick up the pace in all aspects of what we do. We need to discover new tech faster, get it built quicker, and get it to users sooner. That's part of why we built Foundation; to learn responsive design faster and to build things faster. How else were we going to hook our clients up with some sweet device-agnostic sites? Foundation was, and is, a way to standardize around a consistent, effective codebase — something we and others, given the framework's popularity, needed.

Foundation 5, the latest version of our responsive front-end framework, comes out next week — and with this release, speed was the name of the game.

The Fastest Foundation.

Foundation 5 is fast. In all the ways we've been talking about. Check it.

Faster to Learn

For 5, we've worked hard to make Foundation as fast and easy to learn as we could. Starting with the most obvious learning component of any open-source tool, we rewrote the documentation for Foundation with an all-new style and template. There's new and more detailed code examples with entirely new sections that you can browse through and just take it all in.

We also wrote a new "Getting Started" guide that'll take you from having nothing set up to having a complete Foundation environment to build or hack on. We've always had a "Getting Started" guide; but this one ought to help you really get started. Crazy right?

If you have questions about Foundation we're also finishing up a brand new Foundation Forum where you'll be able to post questions, get help, and provide help to the entire Foundation community. We'll be on there, too, answering questions and posting funny cat gifs.

Finally, if you really need to get going in a hurry, we now offer training courses on Foundation as part of our ZURB University. Foundation Basics, Advanced Foundation and Sass are all courses you can take to learn all about how to build with Foundation, right from the horses mouth (the ZURB team that built the framework, including yours truly). And it's an act we'll be taking around the world soon. It's pretty rad.

Faster to Code

While we enjoyed making Foundation faster to learn, we have to write a whole lot of Foundation code here at ZURB. That means making it faster to write was pretty near and dear to our hearts so we bet you'll like it too.

We've added new or updated components that remove some of the manual work you had to do before, including a medium grid (which won't require you to use custom breakpoints and media queries for that) and semantic breakpoints (much easier and faster to use visibility classes and mixins).

We also built all new templates for Foundation 5 so you have a speedy starting point for your projects, if you like that sort of thing. They're all mobile-first, all documented and totally easy to change.

Finally, for the nerd in all of you, we've built a new command line tool that will let you spin up Foundation projects preposterously fast, and those projects will now use Libsass, a back-end Sass compiling library that will dramatically speed up how long it takes for your SCSS changes to take effect while you work.

Faster for Users

If we're writing a lot of Foundation code (and you are too), just imagine how much that code is being delivered to users. Foundation powers hundreds of thousands of sites, and the time and bandwidth required for that in aggregate is pretty extreme. We worked diligently in this release to try and streamline the framework as much as possible, and to give you the tools to optimize your sites like you never have before.

Interchange, our responsive images plugin, has been augmented in Foundation 5 to allow for a whole new level of responsive delivery. In addition to delivering just the right image, you can now use Interchange to deliver entirely different sections of the page to different devices. Just create some different HTML partials and have Interchange swap them in for the right type of device. Want to deliver an interactive but heavy-load Google map to desktops, and a small, optimized image to everyone else? No problem with the new Interchange.

On top of that (and that's a big that) we've also added a ton of support in Foundation for hardware acceleration wherever possible. Smoother animations and transitions across the board that use less power on devices and feel dramatically faster for users. That's a win.

We even redid Foundation's visual style to be simpler, cleaner, sexier and faster to restyle — all with fewer CSS rules and effects to burden devices or the style sheet.

Must Go Faster, Must Go Faster.

There's a lot more to Foundation 5 than speedy things alone, but that was a big focus of ours. Speed is the next great opportunity for responsive design: speed of education, speed of development, and speed of delivery / use.

Many of the most popular sites in the world are not responsive, in fact many have no consideration for mobile at all. Responsive design is, in a lot of places, still ill-understood, slow to learn, cumbersome to write and challenging to test.

Beyond the challenge of just creating responsive site, consider this: the average mobile broadband speed in the US is only 2.8Mbps, compared to a little over 8Mbps on wired or fixed devices. While the US is certainly not the fastest country around for mobile or other broadband speeds, it's still in the top 10. In fact, the global average connection speed is 3.3Mbps, just a bit faster than the average mobile speed in the US.

If Foundation 5, along with other responsive frameworks, can help speed up education for this style of design, we're making serious progress. This will speed up development for small and large businesses and help users get better tailored, readily available, and better designed sites — which sounds like a win to us. Stay tuned for Foundation 5 next week, we hope you like it.


Introducing Ink: Our New Responsive Email Framework

Eric wrote this on November 07, 2013 in . It has 132 reactions

Illustration of Ink's mascot: Inky the octopus

We've been taking about the importance of responsive emails for awhile now. With over 40% of emails opened on a mobile device, we knew ensuring our emails looked good on any device was imperative. Iterating and improving our emails is something we've been working on since last year. And we've been teasing that a new solution was coming. Well, today's the day! Ink, our brand-new responsive framework, is finally here.

What We Learned Building a Responsive Email Framework

Ink's development started when we released our responsive email templates last year. We were spurred by our growing mobile readership. Originally, we didn't support Outlook in our templates, but we realized we were cutting off the second largest email client market share. Let's delve deeper into the lessons we learned whilst building Ink.

1. Flexibility is Key

Ink is a framework, not a template. Templates are the most popular approach to responsive emails, but they're not very flexible and have many limitations. We didn't want those constraints. We needed flexibility and a framework provides that. Ink uses a 12-column grid for maximum divisibility — you can divide the grid into one, two, three or four columns. Originally we planned to use a four-column grid, but found it hampered our flexibility. To give folks further flexibility, we also included UI elements — buttons and panels — that designers use frequently. But they're completely customizable to suit any design needs.

But Ink is more than a framework. It's a process that creates conventions for organizations and developers to adopt that creates consistency in the way emails are developed.

Illustration of email fish swimming towards the outlook logo. No, really.

2. Outlook Still Matters

Outlook still has significant market share, and people kept asking when we we would to support the second-most email client. Technically, Outlook is the most limiting email client — it doesn't support max-width: 100%, for instance. Focusing on the client's constraints forced us to consider the hard questions early in the design process. It had us designing Outlook First before enhancing the mobile experience by layering in media queries. And Ink allows you to reasonably support Outlook with fixed-width, as opposed to fluid, desktop layouts and media queries to target small screens. (Of course, you'd want to test it in a service like Litmus to make sure it looks swank on various clients and devices before sending it out.)

3. Media Queries are the Future

We struggled with ways to best support Gmail mobile. We ended up offering a non-media query solution, i.e. block grid, though the media query approach is still preferred. This caused a lot of headaches, so we built our own inliner to let you place CSS inline for better Gmail compatibility. As we move forward as a community, things will move toward better media query support.

Email Anywhere. On Any Device. On Any Client, Even Outlook.

Ink allows you to create emails that work across devices and email clients, even Outlook. Our responsive framework has a 12-column grid that blends flexibility and stability so you readers can view your application updates and newsletter from wherever they may be. There's five easy steps to get started with Ink:

  1. Test in Outlook — Outlook is your best, worst enemy when it comes to responsive emails. Make sure it looks great there before moving on.
  2. Add your responsive styles — Include any responsive styles you want to include.
  3. Bring your styles inline — Include everything looks great in Outlook, bring your style inline using Inky's inliner.
  4. Test your email — Don't ship just yet. Use a testing tool like Litmus to test on a number of devices.
  5. Send it out — Your email is ready. Sally forth with it into the world.

So what's in Ink? Let's delve a little deeper into it's features:

  • Ink uses a 12-column, media-query-based grid with a 580px wrapper. On mobile devices, under 580px, columns become full width and stack vertically.
  • There are UI elements like buttons and panels for rapid development.

We also provide templates to get you started, such as:

  • Basic — perfect for sending out basic but good looking emails
  • Hero — allows you to put a snazzy hero image in your email
  • Sidebar — includes a sidebar area for a list of links
  • Sidebar Hero — this combines the sidebar and hero templates
  • Newsletter — create newsletters with ease

Even though we include templates to get started, you can build your own using Ink as the framework. The best part? Ink works across all the major email clients:

Client/Browser Supported Issues
Apple Mail (Desktop)
Apple Mail (iOS)
Outlook (2000, 2002, 2003)
Outlook (2007, 2010, 2013)
Outlook (2011)
Thunderbird
Android
Gmail (Desktop)
Gmail (Mobile Web, iOS, Android) Since Gmail doesn't support media queries, users will be presented with the desktop view. If mobile Gmail is a large part of your audience, we'd suggest using a layout based on the block-grid.
AOL Mail
Hotmail
Outlook.com

Send Out Responsive Emails With Ink!

Ink is open source, and will serve as a collection of best practices as the community develops it. Our responsive email framework gives your templates a very robust base that's tested across the major platforms/clients.

Check out Ink


Responsive Email: Building a Framework in a Template World

Eric wrote this on November 06, 2013 in . It has 107 reactions

lego framework

We've written before about the importance of responsive design for email. With over 40% of emails being opened on mobile and 80% of mobile users saying they'll delete an email if it doesn't look good on opening, it's pretty evident that mobile can't be ignored, even in the table-ladden pain in the butt that is email.

There are two main methods of creating responsive emails (other than hand-coding each one individually): templates and frameworks. Both offer the advantages of making your content available to audiences on a number of different platforms and clients, but take very different approaches.

Templates: Attack of the Clones

Templates are by far the most popular approach, with many options out there to choose from. They're quick to implement, require little technical know-how to set up and can lead to decent results with minimal effort. Because templates only have to accommodate a single layout, they're not very flexible, but do their one job fairly well.

One-off templates have many limitations. Templates, by nature of their construction, don't necessarily allow for a lot of customization. As a result, their lock-in cost is fairly high (good luck trying to turn your two-column template into three), and cookie-cutter templates tend to make everybody's emails look the same. The numerous tradeoffs involved with using templates are why we chose frameworks as our current responsive method of choice.

Frameworks: A New Hope

"Framework" is a rather broad term, and one which people often used somewhat ambiguously. As we define them, frameworks are collections of reusable code and design patterns that give users a solid, tested base on which to build. Ideally, frameworks should speed up the initial coding of a design without forcing the user to use one particular layout or visual style.

In addition to laying out what a framework is, it's pretty important to establish what a framework isn't. A framework isn't "design in a box" or a quick fix. You can't just bolt one on top of an existing design and expect responsive, pretty results. Frameworks also don't have to completely depart from your current style (though they're a good way to get a fresh start). A good framework should be flexible enough that you can recreate (or come close to) an existing layout or visual style.

Why Frameworks are Right for Us

While frameworks require more up-front work than simply modifying a template, we feel strongly that they're the right approach. We've invested a lot of time and effort into what we see as a long-term play. Consistent code structure and styling will make modifying our layouts easier in the long run.

Not only does consistent code style make jumping into a framework easier, but basing it on a framework's functional principles, rather than an opinionated style guide, makes its code much more intuitive. This intuitive consistency makes it much easier to collaborate on our code, even when we bring in new team members. On top of that, when we want to experiment with new layouts, we know that we have a solid base behavior and consistent rendering on all clients, instead of having to reinvent the grid every time.

Building Our Own Framework

Ready to fully buy into the idea of building our emails on a framework, we excitedly rushed to the internet, only to find that … well … there aren't any responsive email frameworks that live up to our expectations. We wanted something that was fully responsive (obviously), easy to understand, flexible to build with and looked great on the latest, greatest retina screen iOS devices, without sacrificing support for our email subscribers who use Microsoft Outlook (or other, ahem, limited email clients).

Disappointed yet determined, we decided to build our own, and are all the happier for it. We're a group of passionate experts who live, breathe and design responsive. We have a strong track record of building and supporting great open source frameworks. Building on top of our previous success in responsive emails, we're excited to announce our brand new, super-duper responsive email framework, affectionately known as Ink, which launches soon (like soon).

Don't Just Build — Create

Ink is the first responsive email framework of its kind, and will make it easier than ever to build beautiful, functional emails that look great on any client (even Outlook). This framework is a bit more work to build a layout on top of Ink than to just drop your content into a pre-made template, but Ink offers a level of flexibility and code consistency that is unmatched by any template. Ink lets you focus on designing the best experience for your users and creating meaningful, engaging content, instead of spending all your time perfecting your low-level implementation details.

Get Ink Updates


Over 40% of Emails are Opened on a Mobile Device

Ryan wrote this on November 04, 2013 in . It has 263 reactions

A little over a year ago, we started to notice that more and more people were reading our monthly email newsletter on their mobile devices. With a growing audience of readers on-the-go, we made our email newsletters responsive. And that mobile readership has only grown since then — now nearly 50% of our readers open our emails on a smartphone or tablet.

checking email

We took what we learned and released a series of responsive email templates, but they didn't get along with Outlook. Now we're poised to release a new responsive email framework that's Outlook-ready. But why all the fuss with email newsletters that work across devices? Well, the facts are just too hard to ignore. Let's take a look at a few of them:

Marketing platform Knotice conducted a study that revealed: more than 20% of emails sent in the first six months of 2011 were opened on a mobile device. The same study also found that since the fourth quarter of last year, mobile shares of email open rates increased by 51%.

Knotice wasn't the only ones to notice (pun fully intended) the trend. Return Path, another email service, predicted that mobile would leave web and desktop email client usage in the dust by July 2012. But it happened a heckuv a lot sooner and they found that 35.6% of all Campaign Monitor emails were opened on an iOS device.

So mobile is a thing. And it ain't going away. Our audience is mobile and we need to be as well.

Mobile Triage is a Myth

It's a myth that people use their phones or tablets to triage their email. Litmus, which allows you to preview your email campaigns, found that 2 to 3% of emails are opened on two different platforms. They also found that fewer people tap through on mobile, but open rates are high — 55% compared to 43% on desktop.

But there's good news. When it comes to checking their emails, 43% of mobile email users do so four or more times a day. And a stunning 43% of all email opens occur all on mobile devices, quickly overshadowing desktop.

We Need a Framework, Not a Template

Since we launched our templates last year, we've worked hard to develop the content that goes into an email newsletter. We realize that marketers need to worry less about technical gotchas and more on the content. A responsive email framework helps with that more than a template could. Ink, which will be released soon, is a framework, not a series of templates. Think of it as Foundation for emails.

A responsive email framework is imperative. More and more of our audience is mobile, and that's only going to grow with the proliferation of devices. Consider this last thought: emails have led to more conversions than Facebook and Twitter by 7%. That's something we can't pass up. And this is how we have to think about emails now.


What Your Footer Says About Your Business

Alina wrote this on April 12, 2013 in . It has 109 reactions

You can tell a lot about the health of a business from its footer. Sounds crazy? But it isn't. Our footer has and continues to evolve along with our business.

Think about it. Your footer is the last stop on your page, where you can snare the attention of visitors before they bounce somewhere else. What goes into it says a lot about how you want to connect with your viewers, or how you want them to connect with you. And as you grow and change, so must your footer. Here's how we've changed our footer over the years to meet the needs of our evolving business.

Reflecting Changes

Our footer didn't change too much from 2008 to 2012. We were in a good place and we felt comfortable about who we were at the time. Check out our footer from 2008:

It's very basic. We emphasized our contact information: phone, email and signup for the newsletter. At the time, we were focused on perfecting our design process, and this footer was all about brining in business. But we were also poised to expand our reach.

We charted a course into product in 2009 with Notable, our first app. It was early days and we were going through the expected growing pains of launching a first product. However, our longevity helping other companies and startups put us in a good place to overcome them.

Evolution came as we launched other products, such as Solidify and Verify. We were now putting together a product suite. Our footer had to reflect that, because we weren't just trying to validate our product — we were really putting an emphasis on marketing them. Below is a footer from Notable where we first talked about a suite of apps:

Telling A Story

Footers must also match your business goals. Early 2012, we relaunched ZURB.com with a brand new look and a splashy footer. Content-wise it was mostly the same — still largely geared toward generating leads for our services — but with more emphasis on personality. After the success of proving ourselves with our own products, we wanted the world to know what it was like to work with us.

But by that time we were so much more than that. Foundation was gaining speed as were the improvements to our product suite. Our educational and training channel, Expo, was growing with new materials. We thought about our ever-growing property tally and our future. How was this all tying together? What was the story being told?

Tying It All Together

We spent many months last year figuring out who we've grown to be and how we can clearly tell the story that had emerged. Here's what we came up with:

We've pared down the top of the footer to the essentials about the properties and the most vital links. Plus a means to get help. It really covers the gamut of what users need without being too verbose, too heavy footed. The bottom is devoted to ZURB, who we are as a whole, and lets visitors into the rest of our awesomeness. And it's something you'll start seeing live on the site really soon.

With our snazzy new footer, we've developed a pattern that tells our story and works across our property spectrum. We've come a long way and we're doing big things. We were taking a stand, marking the four pillars of ZURB: Services, Foundation, Products and Expo.

Footloose and Fancy Free

A footer says a lot about your business. It says much more than the health of your company. It says who you are. And it must evolve as you do.


4 Pitfalls That Stifle Good Product Design Talent

Ryan wrote this on April 11, 2013 in . It has 54 reactions

It's been a couple of weeks since we released our Job Board out into the wild. We learned some valuable lessons on hiring product designers from it. And we continue to learn more as we go. We mentioned during our launch that we did a survey asking designers what they did not want in a job. Today, we want to share our final findings.

We've worked with many designers over the past 15 years, learning what drove them. But we dug deeper whilst putting together our Job Board. We did an initial survey on what they were exactly looking for in a job and found the following made them happy:

  1. Passionate co-workers.
  2. The type of projects they worked on.
  3. A strong company culture.
  4. A flexible work schedule.
  5. A company with vision and goals.

We followed up with another survey of 80 designers. And they gave us what turned them off in a job. Here's what we they said.

1. Designers Don't Want to Be Micromanaged

41% of designers said they don't like meddling mangers. We've found over the years that designers like some autonomy in decision making, the ability to solve problems on their own. They like to have breathing room to make mistakes, to fail fast, so they can quickly achieve wins. It gives them a sense of ownership about their work. Too much bureaucracy can kill passion for a project. But this doesn't mean that designers should be left adrift, rudderless in a sea of work.

Designers need feedback in order to become successful. What's needed isn't a tyrant telling them what they did wrong, but a coach who asks questions and challenges assumptions. A micromanager is the opposite, someone who gets their hands on everything because they don't have a clear sense of objective. A good coach can rally a designer far better than a dictator by providing clarity on expectations.

2. Designers Want to Avoid Places with Dispassionate Workers

Another 41% of designers wanted to avoid jobs where their co-workers were apathetic to their work. It probably goes without saying, but might be worth repeating, designers like to be engaged with their work and those they work with. Dispassionate co-workers can quickly poison morale, their attitude spreading like a zombie virus.

No one wants to work anywhere where there's no clear vision, no shared goal. Everyone wants something to muster behind. Without that, companies can falter and bled away any passion in their workers, much like Yahoo during Brad Garlinghouse's tenure when he wrote his Peanut Butter memo. A focused, cohesive vision can be preventative medicine for apathy.

3. Designers Don't Like Cold, Sterile Workplaces

40% of designers disliked bland, corporate environments. Collaboration and creativity can evaporate in the shackles that come with cubical dwelling. Designers, and other workers, would much prefer environments where they contribute to a community, which allows them to act naturally. And that's a boon for creativity.

Our own offices are open with large windows that allow natural light to flow through. It encourages collaboration because we aren't separated by artificial barriers. Chance conversations can lead to solutions to complicated design problems. But those can't happen in environments lacking any personality.

4. Designers Don't Care for Office Politics

39% of designers despised politicking at the office. We avoid this by having a frictionless environment with a flat-structure where everyone can contribute and aren't bound by bureaucracy or overrun by middle management. And that also boils down to ...

Having a Strong Culture

Our culture is our glue. It's what binds us and allows us to be willing to have each others backs. Each of us are T-shaped with strong core skills but able to work across the business to help solve difficult problems and achieve wins for one another. These four pitfalls can be avoided by creating and sustaining a strong culture. One that allows for autonomy, for passion to be expressed, for collaboration to happen and for everyone to work as a solid team. Create that and awesome things will emerge.


6 Ways to Recreate Your App in an Email

Kelsey wrote this on March 27, 2013 in . It has 20 reactions

We've been having a lot of conversations lately at ZURB HQ about mobile. Occasionally, our conversations come back around to Email. Sure, when it comes to the internet, we hang out in various apps and sites like Facebook or Twitter, but where is it we actually live? Email.

Which is why we realized that we have to provide a valuable email experience for people. We have to offer a pleasant interaction. At the same time, we have to be able to create an actual extension of our products. We had to ensure that email is the first service our apps are efficiently integrated with, particularly when it came to Notable.

Here at ZURB, we set out to give our customers a reason to love their email notifications from our app, Notable. So what determines an effective email experience for people using your apps and what really are the best ways to make that happen? Here's what we've learned:

1. Design Mobile First

First, you have to think about what your user is doing when they open their email. A customer could be anywhere from sitting at their desk or waiting in line at the grocery story when a notification hits. We've found that at least 30% of our customers were opening their Notable newsletters on a mobile device. Knowing this, it's crucial to design emails Mobile First. Check out how we put together our Mobile First emails for Notable:

There's one important thing we've found and try to remember. When working from a mobile device, people really just want to stay at their home base and don't want to be forced to hop around from one app to another.

2. Make the Content Count

Every single email that goes out should have one, very clear call to action but still allow for the user to decide what they want to do. This allows us to create compelling content while still allowing the user to remain on the same screen. The shot below showcases this. It shows the exact note left on Notable with the clear action of "view and reply." But now the Notable customer can determine if they need to responde to the newest comment or let it wait.

Essentially, we want to give people enough information so the decision to take any in-app action is directly placed in their own hands. Showing users as much information as possible in one place is how we achieve this. When it comes to creating an email, we wanted to:

  • Clearly show the reader what type of update they're getting
  • What item the update is referencing
  • All of the available comments and/or notes that are relavant at the time

Once the email has been read, the user has all the information they need and can decide where to go from there. Forcing a click over to the app could actually curtail engagement if someone isn't able to see what they're even looking for in the first place. Or even if they just don't have the time.

3. Write Clear Subject Lines

Another thing to keep in mind is the actual audience of your emails. A clear subject line is more likely to engage someone than an elusive one that just makes mention of your app. By doing so, you'll also allow people to create and apply organizational filters. In other words, you'll be fitting into their workflow rather than imposing upon it.

Additionally, grouping similar updates under the same subject can be a huge benefit. Many email clients will automatically group emails by subjet or by custom configuration, making it so much easier to manage multiple updates. One last thing to note, especially since there are still some email clients that remain text only, you should also include a plain text option, even if only to say "Hey, there's an update!"

4. Let Them Control the Frequency

Lastly, limit emails to one per task. This actually lets people use their emails as task items for later review. For those who don't need this feature, they should have the option to filter or even shut off these emails. Notable lets each account holder to determine the frequency of their notifications, which is great because everyone ha different preferences and means of organizing their emails.

5. Take Note of How Others Do It

There are other apps that have done a great job of integrating their emails — take a look at your notifications from Facebook and LinkedIn, for example. You get the valued information that you need regarding a specific update that occurred. However, they both still encourage a click over rather than letting you decide if you need to click over and take a look.

And if you don't have the time what's the most likely reaction? You're just going to read the email notification, delete it and then (probably) forget about it. This is exactly what we don't want to happen for our Notable users and, again, why we were so adamant on creating an unbeatable email experience for them. An experience that extends the app and keeps the entire procedure as fluid as possible.

6. Recreate the App Experience

As we said, forcing someone to click over can seem rather forceful, not necessarily creating a positive interaction. And what we've been saying throughout our tips is that you really have to replicate the same experience on email as your customer would have with the app. Recreating the app experience in an email allows you to provide valuable content and not just drop an alert in someone's inbox.

If you're able to provide all the value from an update in an email, then you should do it. Just like when we read our mail at home, we have the option to pay that bill now or come back to it later. After all, why shouldn't we have that same luxury when it comes to our email inbox regardless of where we are.



Get a job, nerd!

via Job Board from ZURB