Web design would be dramatically different if HTML had been born with some foresight for storytelling devices like maps. We certainly can’t blame web pioneers for focusing on type and images instead of maps, video, or canvas. But, because maps found their place at the table through browser plugins and third-party APIs, I find that they’re too often dismissed in the design process as elements that are just “plugged in.”
“We don’t have the budget or time for user testing,” is something I’ve heard all too often during planning and estimating meetings. Testing with real users has traditionally been an expensive and time-consuming line item in project plans—usually one of the first to be cut when budgets are tightened. It’s no mystery why: most testing methods have classically been stressful to set up, requiring a tremendous amount of scheduling, coordination, resources, and time.
Last week, Greg Storey and I attended the Senior Exit Review at Texas State University. We were both blown away by the quality of work and were incredibly jealous that these students got to learn so much about the web in college. It made me think back to when I graduated and how confused I felt about, well, everything. Looking back at what I’ve learned since then, I came up with the following list of what I wish someone had told me at the time:
Remember the childhood game of “Telephone”? One person whispers a message into the ear of their friend, and that action is repeated until everyone in attendance has heard and relayed the statement. The last person blurts out to the group what they heard, and, usually, laughter ensues.
Everyone understands why this happens. Translation and less-than-pristine reinterpretation damage the fidelity of the message. There is no copy-and-paste equivalent for verbal storytelling. A photocopy of a photocopy of a photocopy of an image will always render that image indistinguishable from the original.
The ability to update a website based on current information is often overlooked by clients and vendors alike. This may be the most missed opportunity in what we do.
Get Ready to Get Ready
When we start a redesign project, the possibilities for what the new site can be seem endless, but project work is often based on the best information available at the time. We strive to balance information requirements and business objectives with time and budget constraints. We adapt our approach as we learn more through the project. When it comes time for launching our client’s site, ultimately, both parties make sacrifices, and some requirements may not make it into the initial launch.
Web workers have a certain obsession with productivity. And it is not hard to see why. The processes and detailed knowledge required to build a website have grown leaps and bounds in terms of complexity and sophistication. With an Adaptive workflow that considers Responsive Design, multiple platforms, and countless devices with a wide range of capabilities, the job is not as simple as it once was. There are plenty of great applications and methodologies to help get organized and be productive, but these tools do not do the work for us. When it is time to get work done, we need to be working efficiently, quickly, and intelligently—and in a way that promotes good health and happiness at home and in the workplace.
At Happy Cog, we take pride in our work teaching others and sharing what we’ve learned. Whether by speaking at a conference, leading a class, or writing on this very blog, we’ve taught or shared our knowledge on best practices for web design and development, user experience design, business advice, and even the occasional informal primer on animated GIFs.
When someone at Happy Cog tells me that they’re teaching a class for Girl Develop It or a local university, or a workshop at a conference, my first response to them is one of encouragement. Then, I say: The best way to get better at what you do is to teach others how to do it, too.
I am an overwriter.
I could stop this post right here, but you wouldn’t believe me.
There is relief and guilt to overwriting—like you’ve just finished off a large bag of potato chips by yourself. You find comfort in there being no more chips to eat but also discomfort, because, well, you just ate an entire bag of chips.
Or, you’ve just written countless words to a client team explaining the intricacies of a deliverable. You exhale and cross the to-do off your list, but you secretly doubt whether the post overcomplicated the work or confused your client.
If I had a nickel for every time someone has asked me, “what is your favorite tool for responsive web design,” I would have enough nickels to buy a cup of coffee… in 1941. I’ve realized, collecting nickels is a terrible way to get rich, so I’ll give you the answer for free. My favorite tool for any design project is: pencil and paper.
You dev? If so, ever popped open a fresh PSD and thought to yourself, “Oh man, I can’t WAIT to get this party started”? I have, and I do, with each new project. As a front-end developer, that specific, exciting moment is my fresh start.
Devices come in all shapes and sizes—from iPhones, to the massive Galaxy Note, to the tall-but-skinny Nexus 7, to 10-inch iPads, and massive, 30-inch displays.
“Pick up the phone!” That is my phrase of choice when I hear about a co-workers’ failed attempts to communicate through every means except calling those they are trying to reach.