Over the past few months, I set out to write regularly. I also had a few potential talk topics bouncing around my head, and I had been waiting to find the right place to share them. This past April, I spoke at two events: Jersey Shore Tech on design patterns in JavaScript and Peers Conf about how we built the system at the heart of the O Music Awards.
As a designer, my involvement in projects’ front-end development varies. Sometimes, I spend most of my time in code; other times, I work solely in Photoshop. But, there is one part of every front-end engagement that I always love to jump into the browser for: to create hover animations.
Hover animations are a site design element just like typography and color, so it’s important that designers take ownership of this step. Not only do hovers add to the look and feel of a site, but they also add an extra layer of usability for users with a mouse. A finished site may “work” without them, but these nuanced touches add polish and really reinforce a site’s personality. I like to think of their addition as “bonus design”—it’s an opportunity to better what’s being built.
“What’s in a name? that which we call a rose / By any other name would smell as sweet; / So Romeo would, were he not Romeo call’d” (Shakespeare, Romeo & Juliet, 2.2).
In the world of project management, naming conventions are often the source of miscommunication. You have to call your work something, but if you assume everyone interprets a name the way you intended, you’re likely to stub your toe during the course of the project. As managers, minimizing risk and setting expectations is an everyday task, yet something as simple as a name or label can fly under our radar. We live and breathe our work, and we are passionate about it. It’s a good practice to never assume labels are understood out of the gate. Here’s a few tactics to help you make naming conventions work for you.
A couple of years ago at Happy Cog, I transitioned from my position as a designer to a developer full-time. Up to that point, I had been a hybrid designer and developer, splitting my time between the two responsibilities. The truth is that it was a long-overdue transition. My passion lies in the development side of the spectrum, so I am glad to be in a role where I get to express that passion full-time.
I no longer design all day every day, but my experience as a designer taught me that developers should learn and practice design. The trope is often that designers need to learn to write code, but in working as a developer on the web, I’ve learned that the value of a design education pays dividends beyond being able to mock up a page in Photoshop.
The article’s title is borrowed from Malvina Reynolds’ song, “Little Boxes.” No doubt, many of you have heard the lyrics, though sung by a different artist than the original songwriter. Malvina wrote the song to protest the mass conformity of home development taking place in a suburb of San Francisco in the early 1960s. If you have ever driven through the area, you can still see all the ticky-tacky, little boxes dotting the hillsides and throughout the area. Though Daly City provided the inspiration for the song, Suburbs of Sameness are prevalent throughout the country.
When I graduated college with an English and Fine Arts Degree, my school’s career services office didn’t know what to do with me. They handed me a giant book of jobs for English majors. Nothing interested me, but I wasn’t going to let some lady in a university office dash my dreams. I went to Monster.com and found what seemed to be my dream gig at a startup. I applied, selling myself as a creative type eager to learn anything and everything.
I got that job over 15 years ago, and I’m happy to report that that description of me still hasn’t changed. I’ve always wanted to learn on the job, and I still do. Somehow, I’ve made a career in an industry perfect for learning while working.
Almost four years ago, I wrote a Cognition post about my Rule of Threes. In it, I explained that pushing a design effort far enough often resulted in stronger, better-conceived, and more thoroughly vetted solutions. If you didn’t read the article, let me give you a quick recap:
At the conclusion of the information architecture phase, multiple designers worked in unison to evolve three unique design concepts. Each effort was aimed at different, but agreed upon goals. By varying art direction, user-interface interpretation, and content prioritization, the Rule stressed designing a “range” of static mock-up solutions to present to a client. Whichever concept garnered the most attention became the “base model” that was iterated on and drove the overall look and feel moving forward.
It’s easy to get caught up in the daily grind of researching and strategizing wonderfully thought out websites. Sometimes, it’s nice to cut loose and create things just for fun, away from the computer screen. Thus, our monthly Happy Cog Handcrafted Challenge (HCHC) was born.
February was its inaugural month, and I led the effort. I wanted to take things back to elementary school and do an anonymous valentine exchange (though, I used the term “valentine” loosely—really just any card stuffed in an envelope would do).
Off the top of my head, I can tell you that I’m afraid of flying, public speaking, and savory foods that contain hidden fruit. I’m also afraid of starting a new project. But, I dive into new projects just like I risk biting into mango every time I go for the summer roll, because I know that fear of the unknown isn’t a bad thing.
Fear is a natural reaction to the unknown, but as a society, we don’t really like to talk about it. Not many people will openly admit they’re afraid, because, well, it’s uncomfortable. Admitting your fears makes you vulnerable. It also makes you human. When it comes to the world of digital projects, admitting fear is sometimes likened to admitting defeat. It’s not. It’s a normal reaction to the various unknowns that exist at the start of a project.
We’re back with another Cognition Roundtable—a casual conversation about process and the web industry recorded by Happy Cog folks. This time, CMO Greg Storey leads a discussion with designer Sophie Shepherd, developer Brandon Rosage, and VP of Technology Ryan Irelan about how and why we’ve started experimenting with a more development-focused project process. In under a half hour, they cover topics like:
Do you ever overcompensate? Maybe you’ve gone on an “unplugged vacation” to combat device addiction or embarked on a juice cleanse after an indulgent weekend. I’ve been there often.
I’ll spare you the details of my “10-Day Sugar Detox,” but I can share a little about how I’ve overcompensated in my design work. You see, my early designs were chock-full of inconsistencies—every style I created had a unique embellishment. One day, I became fearful that I had become one of “those clueless designers” that frustrated developers write scathing articles about.
The web has been all about style guides lately. Everyone from the BBC to Code for America to Yelp released their guides to the public, and style-guide-automating tools like KSS and Hologram are becoming increasingly popular. At Happy Cog, we’ve been making our clients’ style guides more interactive. Our newer style guides go beyond documenting the design systems we’ve established; they take advantage of their living in the browser to dynamically show how a system’s pieces are built, how it responds at different viewport sizes, and how users can interact with those pieces.
For the recently launched Ben & Jerry’s website redesign, we created one of these “interactive style guides.” It covers everything related to building out and maintaining the new website: design components, page layouts, and even content creation. I chatted with a few of the Cogs responsible for the Ben & Jerry’s style guide about how it came together.
insights