People who sketch well are intimidating. I’m talking about those who confidently visualize an idea with speed and style. Some are just born with this talent—others have to develop it. I fall into the latter category.
Like many designers, I showed enough drawing ability to have put me on this career path but not enough to be an illustrator. That gap in drawing talent manifested itself as a lack of confidence with sketching, as well. I tend to see the vision as the pencil hits the paper—not before. As a result, throughout much of my career, I’ve kept my sketches to myself in volumes of Moleskins. I’ve rarely shared those doodles with coworkers and never with clients. The thumbnail-sized brainstorming and visual problem-solving made sense to me, but I had no confidence it could communicate clearly to others.
We lost another job to spec work.
Originally I came here, to this previously blank page, horrifyingly white (both myself and the screen—it’s been a busy summer) and blinded by rage, to rail against designer injustices (the ones made for designers and by designers) and gnash my teeth and furiously hammer out another scathing anti-spec article (that no one needs), when I remembered a conversation.
Over the course of hundreds of projects, project managers develop a very real sense while trying to build a perfect project plan that we are architects pulling from a tried-and-true collection of building blocks. But, (and this is a big but—I cannot lie) tried-and-true can be blinding. Though some client teams and projects seem to closely resemble past experiences, every client is unique, and there are countless combinations of project requirements and team personalities.
Sure, do it for money. But just as importantly, do it for fun.
We’re currently working on a digital redesign for Lagunitas Brewing Company. It’s our first foray into the craft beer world and a bucket-list item for me personally, having long been a fan of Lagunitas. Many of their beers are complete style mashups (they are not staples at the Great American Beer Festival in part because their beer doesn’t fit neatly into judging categories). Their brand is decidedly lo-fi, but filled with personality. If you haven’t read a story on one of their beer bottles or some of the prose on a case, just have a gander.
It’s no secret designers love typefaces. Web design is 95% typography, and it’s hailed as the most important aspect of a design. So, it’s imperative to find typefaces that accurately convey the voice of our words. Designers may not be always thinking about it, but how a site performs can be as important as choosing the right typeface. The weight of a font kit is arguably more important to a site’s performance versus other heavy hitters (like images), because fonts are loaded on every single page. And, after all, if a site loads too slowly, users won’t view the typography as you’ve intended!
We’re bringing you this special edition of Cognition Roundtable, where Assistant PM Mica McPheeters speaks with our VP of Design Chris Cashdollar about the client’s role in design projects. Spend the next half hour with Chris, as he pulls inspiration from his upcoming presentation at HOW Interactive Design Conference in Washington, DC—“Reevaluating the Role of Your Client in the Design Process.” Specifically, he’ll cover:
I should have an office pony. Something straight out of Thelwell, with a bushy mane as wide as its body, sparkly-painted hooves, and short enough to use as a portable laptop stand. I’m convinced that this should (and will) happen one day. Just ask my coworkers how often “little horses” come up in conversations with me.
I have a long list of “shoulds.” Most are pony-delightful, but not all of them; some like to sneak in and push my limits—the devious suckers. Those shoulds are the kind that adore instilling doubt, delaying decisions, and convincing us we need to incessantly reach and achieve and exhaust. It takes guts to tackle that kind of should. They play the long game, and they always seem to crop up during tests of our fortitude. They love to mess with our heads.
Leading up to the design phase of a project, we devote a lot of thinking to setting the project’s core goals and requirements, as well as establishing a basic plan for how the project will flow. During this time, on my team, we ask as many questions as possible and learn as much as we can before we present a strategy to the client. In the end, everyone agrees on what the goals are, but how those goals will be realized is yet to be determined.
The ability to communicate well with non-technical people is what separates star developers from the rest. Star developers understand that other team members don’t need to know about implementation details. They’ve developed an understanding of the non-technical aspects of project work—things like requirements, risk, scope, client concerns, project timelines. They handle more than just the technical parts of a project with ease.
It’s no secret that most developers have room to grow in the communication department. Even within the development world, back-end developers and front-end developers’ communication skills can range. We have a hard enough time communicating with each other about things like CMS implementation, template integration, CSS best practices… and we speak each other’s lingo! Forget about trying to explain things to non-technical folks. (By the way, you may know Happy Cog only for exceptional designers and front-end devs, but it’s worth mentioning we have a brilliant back-end development team too.)
One day a phone call came in from a large, amazing hospitality brand. They were preparing for their annual shareholder meeting and needed some environmental and wayfinding work done in a hurry. It was 2004 and I was a designer at a studio in Southern California. The studio was small, and the team was small, but we had a big passion for great work and cool brands. There wasn’t much that we couldn’t handle.
Our passion for this particular project was pretty intense. We were collectively excited; not only by the type of work, but for the brand as well. Nights and weekends be damned, this project was going to kick ass. And it did — but not without its bumps in the road and small anxiety attacks. Communication started to breakdown and frustration started to take over. The client’s trust in our ability to see the project through started to evaporate.
The movement towards designing with performance budgets in mind has inspired more fist pumps and vuvuzela bleating in this developer than the recent World Cup. Thinking through the ramifications of design choices for site performance makes it easier for me to build a fast website when development begins.
But when it comes to testing against budgets, we’ve been measuring page weight and rendering times manually, using tools like WebPageTest.org and Yahoo’s YSlow. Relying on humans to run tests has meant we don’t always measure our performance consistently, therefore missing page weight hogs like the occasional stray Blingee. There has to be a better way, right? A curious client got us wondering how we could automate our performance testing.
If you’re in the web industry and reading this article, you’re probably thinking, “Over halfway through 2014 and she’s writing about the fold on the web! I thought we settled this!” But, the existence of the fold is still something that gets debated on many of our projects.
Below is an imagined conversation between myself and a Defender of The Fold, in which I successfully explain why we shouldn’t worry about the fold on the web.