Turn Signals
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.
Process
How to succeed (and sometimes fail).
We’ve written 95 blog posts about Process. View all topics »
-
-
Rethinking Our Prototypical Process
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.
-
Plan for the Unplanned
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.
-
Presenting Design with Confidence
When it comes to conducting a well-orchestrated design presentation, having prior presentation experience is a false measuring stick for success. Preparedness, not experience, actually breeds the confidence needed.
“Are you ready?” Klaus asked finally.
“No,” Sunny answered.
“Me neither,” Violet said, “but if we wait until we’re ready we’ll be waiting for the rest of our lives, Let’s go.”
– Lemony Snicket, The Ersatz ElevatorLike Violet states, you can’t wait for the perfect moment or the deserving job title to feel comfortable presenting work to clients. To help nudge you out of the nest, I’ve culled these personal tips for anyone who has to stand up in front of an audience and talk about design fluently and with confidence.
-
Cognition Roundtable
On this edition of Cognition Roundtable, we ask: “Does every site need to be responsive?” This question has been an undercurrent topic for conversation in the web industry ever since RWD was introduced, but our own work as well as others’ continue to spark it again and again. Design Director Michael Johnson leads a discussion on the differences between adaptive, responsive, and dedicated sites with Senior Designer Yesenia Perez-Cruz and Developers Anthony Colangelo and Sam Hernandez. Tune in for this half-hour discussion that also covers:
-
Designing with a (Performance) Budget
Lately, the web industry has been focusing on ways to improve performance—specifically, by applying the idea of a “performance budget.” A performance budget involves establishing a target page weight (usually in kilobytes), and then making sure no single page exceeds that value. While sticking to this number may seem like a developer’s burden to bear, as Mark Perkins puts it, “performance is everyone’s problem.” As a designer, it’s important to keep your budget in mind throughout your entire process—all the way from discovery through implementation. When both designers and developers work closely to set and stick to a budget, a sweet spot will emerge where neither performance or design will be compromised.
-
Hover-crafting
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.
-
’Tis but thy name that is my (fr)enemy
“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.
-
Why Developers Need to Learn Design
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.
-
Avoiding #RWD Limbo
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.
