A few months ago I was asked to assist leading some moderated qualitative usability testing sessions. I’ll be honest: I had little-to-no experience speaking with users, so at the start of the project I didn’t feel like I was fully equipped for the task. The idea of being in a room with someone I didn’t know for an hour and guiding them through a handful of scenarios to validate our design didn’t sound as good as one of my typical design days. However, I knew it would be a good learning experience and said I’d help out.
On almost all projects at Happy Cog, there is usually one design lead who oversees the work from the initial concept to the QA’d, browser-tested, final product. Other designers may step in to help with production or provide guidance, but for the most part, one designer owns it.
For my first driving lesson my father took me to the empty elementary school parking lot across the street from my house on a Saturday afternoon. He drove over, parked the car, switched seats with me, then instructed me to drive.
We’ve been on a big manners kick in my house lately. We’re talking about chewing with your mouth closed, not interrupting others when they are speaking, not hitting or pushing (duh?), and the importance of the age old “magic words.”
We’ve been on the Sass bandwagon here at Happy Cog for quite some time. It’s become an essential integration into our workflow. Sass’ power manifests in many ways. It makes it easier to maintain our code, it enables a modular architecture, and it helps us scale our CSS. There is a problem, though. I’m sure you all have been there.
I recently came off a huge project in which I was responsible for front-end code that had me knee-deep in a singular codebase for seven, count ’em, seven months. ’Twas fun—no complaints. In fact, I really enjoyed the work, but when I found out the next project in the pipeline was a one-page marketing microsite with a quick turnaround time, I got super excited for the learning/implementing opportunity a project of this scale provided.
No matter the client, FAQs are often a topic of conversation during many site redesigns. Maybe they are legacy content and deemed a new requirement for the get-go. Maybe stakeholders raise them as a potential solution during the course of the engagement. Sometimes, they even creep up on us (unplanned) after launch.
When I started working at Happy Cog three years ago, deliverables fell neatly into two categories: design or code. In the design category, there was another clear division: UX design (wireframes) or graphic design (page comps). But then RWD came in and threw a spoke in the wheel. Since JPEGs only show a fraction of a responsive website, we needed to figure out new ways to communicate the design to move the project forward. We introduced HTML prototyping to replace traditional wireframes, and the lines between UX, graphic design, and front-end development blurred.
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.