When I conducted my first usability test, I felt extremely tense. I was given a sliver of hours to painstakingly figure out how to turn a dense wireframe document into a testable, interactive system. Recruiting seemed to take forever, and some recruits inevitably flaked out. Running the tests required cold calling a large number of recruits, many of whom were non-technical and very impatient with the computers and software used to run the tests. At the time, I didn’t think being a designer would ever mean having to face these sort of obstacles. The thing that haunted me the most, though, was the possibility that the designs that my team and I worked so hard on would fail.

Why Designers Should Run the Tests

My early struggles taught me a valuable lesson: engaging with users in realtime while they interact with a system is very different from reading a report about it after the fact. The more testing experience I got, the more personal accounts I gained—which continue to shape how I approach design problems to this day. Testing not only helped me make better design decisions on a particular project, but it also trained me to make even better design decisions well after a project had ended, or as Mr. Hoekman Jr. put it:

“Usability testing informs the designer and the design.”
– Robert Hoekman Jr., “The Myth of Usability Testing”

Adding value is within your budget.

At a fraction of the cost of traditional lab testing, remote and informal testing methods are steadily becoming popular options to reduce costs while still getting real designs in front of real users. These tools can be strategically used throughout the definition (discovery), design, and development of a project to gain the most insight, even with limited time and on a small budget.

During Requirements Gathering

Talking to users about what features and functionality resonate most can help inform decisions on how to prioritize requirements. The most obvious method is simply picking up the phone or conducting user interviews users face-to-face. Recruitment of these users can take many forms—sometimes clients will even have a list of engaged users for you to work with. If you aren’t so lucky, Ethnio is a good product for recruiting users via a web-based intercept on a live site. Ethnio enables you to set up a screener, collect contact information, and provide incentives to potential recruits. Having a real conversation with the participants is ideal, but an online survey tool like Survey Monkey is a quick and cost-effective alternative to gather quantitative data across large sample sizes.

During Content Development

Card sorting and tree testing exercises help to evolve content categories and develop a site’s information architecture. If your project budget doesn’t allow you to recruit users and run these activities in person, you can still find users to participate on the web using tools like Optimal Sort and Tree Jack.

During Design

The evolution of the design process at Happy Cog has given rise to the creation of HTML wireframes to more efficiently document interaction design, content strategy, and information architecture across a range of screen sizes. These interactive wireframes not only serve as a design tool, but also are instantly-testable artifacts that require a minimal amount of setup before they are ready to be put in front of real users. Depending on the project, there are a few main ways you could gather data:

1. In-person Testing

Testing in person gives moderators the ability to physically observe participants’ reactions. A lot of information can be gathered from physical reactions, especially on mobile or touch devices where those reactions would be lost with remote testing. Recently, at Happy Cog, we went to a restaurant and informally tested a client’s site on the iPhone. We captured these sessions using the the UX Recorder app which captures gestures, audio, and front-facing video. It took all of three hours to complete, we gave each participant a voucher for free guacamole, and we learned a few simple things we could do to improve the responsive nature of the site.

If you’re conducting an in-person test on a laptop, it’s easy to record these sessions for later reference using a tool like Clearleft’s Silverback. It captures screen interactions, webcam video, and audio of a test session. Pro tip: setting up the test machine with screensharing software like Join.me allows other stakeholders to remotely observe the live test sessions in real time.

2. Remote Testing

Remote testing removes the barrier of having to be in the same geographic region as the participants. A tool like Ethnio can work well for recruiting for this type of test because it allows for recruitment across a large geographic area. To remove as many technical barriers as possible, we’ve preferred calling participants on the phone, hosting a web-based, screen-sharing session like Join.me, and giving users mouse and keyboard control.

3. Testing Concepts or Mockups

Occasionally, there may be a need to get design mockups or concepts in front of an external audience. Using similar remote and in-person methods as described above combined with a tool like InVision, designers can easily add in-browser interactivity to static design comps and put them in front of users.

Be Prepared

Not all tools or testing methodologies are right for every project. I am constantly adapting my testing toolkit as new tools become available and our design process evolves. Regardless of which type of test you conduct, it is important to set expectations with stakeholders.

A good test plan answers:

• Why are you conducting the test?
• What you are measuring?
• Who is participating, and what are their incentives?
• What methodology is being employed?
• What devices are being tested?
• What tasks are being tested?
• What happens after the test is over?

Similarly, how you engage with test participants during the sessions can greatly affect the outcome of your test. Having a script that dictates how to describe specific tasks to participants can help create uniformity across testing sessions. Permitting yourself room to deviate from the script when participants behave unexpectedly can help surface the reasons behind potentially-overlooked usability errors.

Time has taught me the real value of user testing and has changed my perception of what is possible with a few hours and a small budget. Maybe one of these methods will help your team incorporate testing into your next project, even if you didn’t anticipate having the resources to do so. Are there any other tools you use for user testing? Let us know in the comments.

1. It’s tough for everyone.

By the time I graduated from film school, I realized that working in the film industry for the rest of my life wasn’t for me. Four years and all that debt for nothing. Sorry, Mom and Dad! After throwing my education out the window, I got a job as a nanny. I enjoyed the day-to-day of hanging out with six-year-olds (ask me anything about Sponge Bob), but I felt like a failure. It seemed like all my friends and classmates had jobs with salaries and health insurance, while I was playing Mary Poppins.

Recently, I talked with some friends about the year of purgatory after college. It turns out everyone felt lost during this time, even those with “real” jobs (they all hated them and quit). Now that I have the benefit of 20/20 hindsight, I can tell you that it’s okay to feel lost. Travel. Take a fun job like nannying or giving museum tours or fixing bikes, because when you’re 40, you probably won’t want to. Even if it feels like you’re not learning anything or advancing your career, you are. You will be better at whatever you end up doing because of this time.

2. Ask for help.

During this period, I got a crazy idea: maybe I could make websites. But, I hadn’t majored in it and didn’t have any friends doing it, so I didn’t know where to start. At the time, I read Jason Santa Maria’s blog and emailed him to ask if we could get coffee so I could barrage him with questions. He graciously agreed and spent an hour giving me advice about how to become a web designer. One of the first things he told me to do was to read Designing With Web Standards. I did, and the rest is history.

We’re lucky to work in an industry full of incredibly nice people who like to teach and help each other. Don’t feel embarrassed or ashamed to ask for things. Here’s a little secret: people really like helping. You’re not bothering them by getting in touch—you’re giving them the opportunity to pay it forward. (And when they respond, don’t forget to be nice, patient, and appreciative.)

3. It’s okay to quit.

Shortly after meeting with Jason, I took a job as an assistant at a publishing company in New York. They treated me well, I liked my boss, and I got along with everyone I worked with, but my heart wasn’t in it. After a few months, I started to understand the “9-to-5 blues” that I had heard adults complain about. I spent about a year debating whether or not to stick it out, and eventually decided to quit. This decision forced me to take on some freelance design work, which I ended up loving.

I often think back to this great podcast about the upside of quitting. The sooner you stop doing something you don’t love, the sooner you can be moving towards something you do. Life is too short to do something you’re not passionate about.

4. You’re in the right place, at the right time.

If you’re reading this, you’re probably interested in doing internet-y things. This industry moves fast. The great part about this is that everyone—no matter how long they’ve been at it—is constantly learning as they go. There is a kind of “Wild West” attitude with everything we do. We’re all venturing and discovering new things together, and it’s really fun.

This constant state of flux also means that there are no true experts. You are just as likely to write an amazing plugin as a web veteran who has been working for 25 years. You can meet really smart people on Twitter. You could start a blog and publish your thoughts for anyone to read. No matter where you live, you can join the community and the conversations. At no other time in history has this been possible—take advantage of it!

5. You’ll be fine.

Yesterday, after the wonderful Artifact Conference, I asked around about what other advice people would offer to someone graduating college. The resounding answer was along the lines of “be nice and work hard.” I couldn’t agree more. Whether you end up working in the web industry or doing something completely different, if you do those two things, you’ll be well on your way.

You’re in the lucky position of having time on your side, with your whole career ahead of you. Don’t worry if you don’t know what you want to do right now. You’ll figure it out in time. Take it easy and relax—you just graduated, and you deserve it.

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.

Unfortunately, the waterfall web design process and “Telephone” are similar, and too much valuable, primary research (in this case stakeholder interviews) ends up being reinterpreted to the point that the original sentiment and answers are lost. The process of conducting and then documenting stakeholder interviews can keep a team at an arm’s length from a project. Instead, place designers and developers closer to the project discovery and research phase. Maintaining the fidelity of the research helps our team craft the best user experience possible. While not everyone has a background in research, anyone can conduct a stakeholder interview.

The barrier to entry might be lower than you think. In the last 12 months, I’ve had to go from interviewer novice to Charlie Rose as the Happy Cog research process was revamped. Being thrown into the deep end of the pool has forced me to recognize quickly some of the more important aspects that make an interview successful. The following tips guide how I plan for and conduct any stakeholder interviews.

(Note: At Happy Cog, we work with our clients to determine what defines a “stakeholder” of the project. Stakeholders may just include the core members of a client team or can extend to content owners, key opinion leaders, potential audience types, users, etc. These interviews tend to take 30 to 60 minutes and are typically conducted by phone. To ensure our interviewee can focus on conducting the interview, a project manager captures notes from the call, and from time to time, we also record interviews.)

The script matters.

“Do you know how to have a conversation? Then you can conduct an interview.”
— Michael Johnson, Design Director at Happy Cog

Having the “gift of gab” doesn’t mean you can skimp on drafting a well-structured script for the interview. A strong interview script works from the general (big-picture project goals) to the specific (role-based concerns regarding features and functionality.) Start with the basics to get the interviewee comfortable. Ask about their role on the project and how they see themselves providing value. Allow interviewees to talk about themselves in their own words. Build confidence in the interviewee that their vision matters, because it does.

Once you outline the easy questions, work backwards. Consider the goals of the project and the goals set forth by the client. What questions will help you learn more about how this interviewee can help articulate the path to success? Always consider the uniqueness of the interviewee’s position and role on the project when deciding appropriate questions.

But, sometimes the script doesn’t matter.

Yes, the script is important, but it shouldn’t be carved out of stone. Just because questions are in a specific order shouldn’t dictate how the interview is conducted. Let the natural flow of the conversation govern the order in which you ask questions. Be cognizant of the topical threads in the answers the interviewee provides; look for the right moments to shift to a question in the script that might keep that narrative thread intact. Mentally check off the questions as you go, ensuring you still cover everything the session demands.

Prepare appropriately. Know who you are interviewing.

Knowing the right way to version the script means the interviewer must do some homework. Set yourself up for success by spending a brief amount of time familiarizing yourself with who you are interviewing and their role. This shouldn’t be a research project unto itself; a quick Google search should suffice. Don’t make the mistake of asking a question that exposes a lack of preparation. The same questions won’t apply to the Dean of the College and a prospective student. Respect the time that the interviewee is providing by making sure you aren’t asking questions that aren’t relevant.

Consider the difference between these two questions:

“What are the most important types of information on yourwebsite.com?”

Versus:

“As the VP of Marketing, how do you use yourwebsite.com to accomplish your team’s goals?”

While the purpose is the same, the second question is much more personable for our fictional VP of Marketing to highlight what types of content are valuable specifically to her and her team. Awkward bulleted-list responses can halt momentum in a productive interview. Avoid the inevitable “umms” found in responses from question #1, and, instead, focus on prompts that will promote free-flowing feedback. Let the interviewee be the storyteller.

Don’t be a robot.

Interviews should be a conversation, not an interrogation. Levity is not a bad thing. The conveyed expression in the interviewer’s voice, the manner in how questions are delivered, how introductions occur and the ice is broken—these all create an “air” enveloping the interview situation. Address this head-on. It starts with the tone in your voice. Keep it happy, upbeat, and generally interested. Let the interviewee know you are a blank slate, ready to learn. Not only does this help establish a more relaxing environment, but it also empowers the interviewee, letting them feel that their input is valuable and that their answers aren’t just checking off a compulsory check box in the project process.

Actually listen.

The best interviews often go completely off-script. Why does this happen? A topic or comment by the interviewee often leads to follow-up questions that can never be predicted. That can only happen if the interviewer is actually listening to the answers and not mentally multitasking. Listen for cues for follow-up questions. Never be afraid to ask “why?” Get comfortable asking for the interviewee to clarify an answer. You should be trying to get the best answers, not just the answers you expect.

Don’t have the last word.

End the interview with some humility. An hour-long conversation can never capture everything that the interviewee can contribute or exhaust their thoughts regarding a project. Quite often, they have more to say. To open a window for this last bit of insight, let the final question be phrased like this:

“What haven’t we asked you today that you think would be valuable for us to know?”

This allows them to shift the conversation to anything they find valuable that hasn’t been addressed yet.

Opt in to being better informed.

“Being able to tailor questions to different stakeholders based on their unique roles and goals gave me firsthand insights that I couldn’t (and didn’t) get from just reading requirements documents.”
–Yesenia Perez-Cruz, Designer at Happy Cog

Being closer to a project’s research phase can be beneficial to the design process. Working in a small(er) agency, UX often falls on the shoulders of more than one person or team. Use this as an advantage. I’ve never heard a designer or developer state “I want to know less about this project.”

Having firsthand exposure to what stakeholders are saying creates less chances for those findings to be watered down. Put an end to whisper-down-the-lane requirements and tactics. Keep what is learned in the interview intact by removing extraneous voices and filters from the process. Consequently, designers and developers can have more of a say in the overall project strategy and design process. Intimacy in the research phase instills project ownership. Ownership is an investment that will manifest itself in the project quality.

Everyone wins.

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.

As you plan for the first update to your redesigned website, you will be tempted to start with the list of requirements that didn’t make the first cut. This makes a lot of sense—until you remember that the information that led to defining those requirements was based on your old site. You’ve got a new site now, and with it comes an opportunity (and responsibility) to re-prioritize these requirements thanks to your new site’s analytics.

Is that critical call-to-action driving users to make a donation? Are users completing that business-critical form or are abandon rates still too high? Being able to isolate answers to these questions and re-address missed opportunities is the beauty of working in a dynamic medium like the web; this ability relieves the pressure of having to include everything under the sun in your initial site launch.

Make Data-based Decisions

Data gets better with time, so what your data tells you will become clearer with each passing day. Let your business goals be your guide. If you’re tracking sales, you’ll want to observe how the changes made in the new site correlate to conversions. If you are trying to drive ad revenue, take a look at your page views in relation to duration of visit. Perhaps adjusting ad placement on frequently-visited pages with the longest average visit is all that is needed.

Focusing on these indicators will guide you to make decisions that can, and will, inform your next set of site changes. These changes may spur requirements that didn’t make the initial launch, and they may not. The key here is to use the most relevant and timely data to drive your next important business decisions and allow your site to work for you.

How are you using data to improve your site’s experience with each update?

You Don’t Have the (Will)Power.

When we try to power through work, we end up in a worse place than we began. The concept of “ego-depletion” that willpower is an exhaustable resource we can simple run out of, helps illuminate why this is the case. Rather than thinking of willpower as a trait we either do or do not have, think of it as a muscle that can become fatigued and needs to be rested to be restored (and even re-energized). Maintaining our energy and willpower in an intelligent way will allow us to keep our focus and remain productive, ultimately helping us get more work done in less time than if we attempted to power through.

Also, since our reserves of willpower are not compartmentalized, if we fatigue our willpower muscles at work, we will not be able to call upon them in the other parts of our lives. Keeping up with that diet, resisting the urge to spend compulsively, or even just dealing with those annoying quirks our loved ones have all require us to use some of our willpower reserves.

Like distance runners, we want to be able to conserve our energy and willpower reserves for when we need them most. There are a variety of things that can be done to help achieve this goal, but I am going to suggest starting with just one of them that you can use today with almost no effort: taking a break.

Breaks Are More Important Than You Think

There is immense pressure in our work environments to keep up working throughout the day. Try as we might to keep focused on tasks in front of us, inevitably, the distractions of Twitter, Facebook, and YouTube start to creep in. Instead of working deliberately on a task, we find ourselves jumping back and forth between procrastinating on social media and working on what we know we really should be doing.

To avoid this, it is better to practice a more deliberate schedule in our work days. As Gregory Ciotti points out, when the most elite violinists practice, they do not do so in isolation for hours on end. Their sessions are broken up into periods of deliberate, one might say intense, practice followed by breaks of 15-20 minutes. This allows them to maintain their energy throughout the day and get the most out of the time they do spend working on their craft.

The 90-minute Strategy

So, here is my suggestion: break your day up into sessions like those elite violinists. Focus on work deliberately for 90 minutes. Quit your twitter client and block out disruptions as much as possible. Knowing there is a break coming up allows us to zero in and focus intensely on the problems we are trying to solve. You will not be missing too much on Twitter, I promise.

On your breaks, ideally of 15 minutes, step away from work entirely. Take a short walk outside in the fresh air and replenish your energy reserves. You will return to your desk ready to refocus on your work. And I mean really focus. Many times, when I find myself stuck on a particular problem, breaks like this are often followed by the solution. It’s a strategy that designers and writers have long employed to get past a creative block. The benefit of including regimented breaks in your routine is these solutions come much more quickly and regularly.

Recognizing our limitations and working within them in this way will provide a boost to the quality of our work. The benefits we realize from managing our energy reserves in this fashion can be extended to our home life or extracurricular activities. If you do end up trying this strategy, I would be very interested in hearing how it works out for you. Good luck, and do good work.

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.

If you want to test your own prejudices and assumptions about the tools and techniques you use, then volunteer to teach a group of local designers or developers or do a short, instructional talk at your local Meetup group. Do you want an even easier way to get started teaching? Write a blog post or article sharing a development or design technique. Regardless of where or how you teach, the experience of preparing the material and then sharing it will make you better at what you do. Ready to get started?

Five Things I’ve Learned About Teaching

Know Your Stuff

For starters, make sure you know the information you’re teaching. If there are aspects with which you aren’t as knowledgeable, do the proper research and become informed. The biggest mistake you can make is to try to teach something you don’t thoroughly understand.

Make the Sale

Teaching requires you to share and transfer your knowledge to your students. But, that knowledge is transferred with a good sell. A good sell? So, teaching is a sales pitch for the material your students are learning? Precisely.

Think about the worst teachers you’ve ever had. Mine was my high school algebra teacher. She was smart and knew all of the material, but her delivery was dry and uninspired. She sat behind the overhead projector and slapped one transparency after another onto the glass. My takeaway from that was that she didn’t care about the material she was teaching, so why should I have?

Show your passion for the topics that matter to you. Remember back to the first time you learned the technique or technology you’re teaching and how excited you were about it. Channel that excitement, and relive that moment for your students.

Teach with Context

Every lesson should have context. Embed the topic you’re teaching in real-world examples. If you’re teaching responsive web design, then the material should walk through how to code a sample project. Give your students the opportunity to immediately apply and try what they’re learning. Give them scenarios that will fit how they’ll use the new technique after the class is over.

Improve and Iterate

Here’s a big secret on teaching: your curriculum is never done. You will always change and improve your lesson and approach based on classroom experiences (e.g. your students are confused by how you’re explaining a topic) or changes in the topic you’re covering.

While you’re teaching, make notes of where your curriculum isn’t working. After the class, go back and adjust it. Improve and iterate on your material after every class.

Be a Student

Take other classes, and be the student. As a student, you get to learn a lot about how others teach: the order of the material they cover, the examples they use, and how they explain difficult concepts. Good teachers always watch others teach.

Alas, these tips are only useful if you actually apply them. So, go find your first opportunity to teach someone something new, and improve your own knowledge!

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.

I haven’t always written exhaustively. Remember the good ol’ days of the five-paragraph essay? I got so used to writing five-paragraph essays that when I entered the dawn of mandatory word counts, I tried every trick to make my writing appear longer: double-spacing paragraphs, increasing the font size to 12.5 points, widening the margins, and even exercising my early design eye to choose a font with wider or larger letterforms.

Eventually, I was able to expand my arguments to work up to higher word and page counts. Writing became about thoroughness—creating a bulletproof presentation of points built step by step for the reader.

The thing is, I haven’t been able to turn off the faucet since.

My Basecamp Reality Check

In the world of Basecamp, I often need to describe in writing design mock-ups, UI components, and/or the logic supporting a system. Our written correspondence with clients can be simple and straightforward: We uploaded the work here. We addressed your feedback X, Y, Z. This is our agenda for the kickoff meeting. Other times, what I’m trying to communicate may warrant more explanation, e.g. We recommend delivering static wireframes instead of HTML wireframes for the following reasons, etc.

Drafting Basecamp messages involves achieving the right balance between writing enough to explain the necessary points but not so much that the reader can’t possibly absorb all the details (or doesn’t even try to). To help achieve this balance, I’ve come up with three self-directives to cure my overwriting habits, and for you to do the same:

1. Write how you speak.
   When you write like you’re talking straight to the reader, you’ll write more honestly and in a tone that your audience will understand. Embrace conjunctions, and leave awkward transitional phrases behind.
2. Embed hierarchy.
   Breaking up your writing into multiple paragraphs and using more headings will make your message easier to scan and digest.
3. Edit down to the essence.
   Empathize with your audience by being selective with your points and getting straight to them. Less can be more if you include just the right amount of detail.

Start a Conversation

In admitting I overwrite, I have finally acknowledged that: A) Not everyone who is willing to read what I write is willing to read everything I have to say, and B) Overwriting doesn’t necessarily eliminate the possibility of there being follow-up questions.

I’m realizing that, unlike the five-paragraph essay, my Basecamp posts should not always be delivered wrapped up tightly with a bow or sealed in clamshell packaging. They should not over-explain, and they should not be a one-sided presentation. It’s better for me—and better for my readers—if I write less and anticipate having a conversation. “Brevity is the soul of wit,” Shakespeare wrote.

We may not be able to increase the terribly-small type size of bullet points in Basecamp, but we can surely make our points easier to read. Overwriters or not, we can more readily anticipate, prompt, and embrace conversation. What are some of the ways that help you do so?

Now, you might be saying to yourself, “that’s idiotic,” or “who is this person,” or “why am I in a bathtub of ice cubes?” By the way, if you’re in a bathtub of ice cubes, I recommend calling 9-1-1. It’s possible a crazed medical student has removed your kidneys. See if there’s a note.

Leave a Mark

I use pencils, pens, and markers as the core of my design process. My best work is probably all in a sketchbook or recently erased from a whiteboard. Any work I do in pencil helps define the ideas that solve design problems. And I’ll be the first to testify: I cannot draw. Let me clarify. I cannot draw well. I can draw adequately. And drawing adequately is better than not drawing at all.

Drawing first is important, because it’s easy for me to sketch to show how an idea could be executed. Drawing lends itself to any sized canvas, even small “viewports.” Hashtag R-W-D, you guys. My drawings might be scrawls and scribbles, but they are ideas that translate easily to page designs. In short, sketches are cheap, quick, and easy. More so than wrestling to yank ideas from my head onto a blank Photoshop canvas.

If the first step in your design process is to open Photoshop, you’re not defining your ideas before you start executing solutions. Simply put, pencil and paper is the planning stage of design. Photoshop is the execution of your plan. If you’re jumping right into Photoshop, you’re probably just messing around hoping for genius to strike you like a lightning bolt from the sky.

Assuming you’ve got a minimal level of skill, sitting in front of Photoshop is going to give you adequate results. If you’re really good at Photoshop, maybe you’ll achieve better than adequate results. Whoah, adequate plus!

By skipping sketching, you won’t see the smart thinking that precedes a solution. The best you can hope for is a repeated loop of trial and error until you finally find a happy accident. You may work on tight deadlines, and fussing with shapes and pixels in Photoshop is a surefire way to waste valuable time. I’ve found, you really need to sketch first before you get on the computer.

Stay Sharp

We work on teams in both Austin and Philadelphia. The one tool we always fall back on is sketching. Sketching might mean working in a group around some big Post-it notes or sharing a whiteboard over Skype video. Sketching is quick, easy, and flexible. You can put something down on paper and discuss if it works. If it doesn’t, you can open the printer drawer, grab a new sheet of paper, and start again. Because of this casual and informal approach to iteration and discussion, sketching becomes a really powerful and flexible tool that supports collaboration.

For our approach to projects, where everyone on the team from designers to developers is working together at the same time, communication is crucial to keep everyone moving in the same direction. When it comes to communicating ideas about design, sketching is critical for us.

When you need a tool that is flexible enough to communicate ideas from wireframes to graphic design, instead of looking for a silver-bullet application to solve your problems, try picking up a pencil and sketching first. Put your ideas down on paper. Have you used sketching in your design process? Share your process, and send us a photo!

It’s not just that I love what I do—solving problems and working with a fantastic team that creates beautiful, purposeful things. It’s because I make a conscious effort to seize the opportunity inherent in this fresh start that I look forward to it every time.

The very beginning, the first time you dive head-first into a project—that’s special. That fresh start represents the potential to be better (whatever “being better” means to you). Every new project could be the “the best project ever ever ever!!”

Try something new.

Our best practices and medium are ever-evolving—the W3C spec changes so often it might as well be written in pencil. We’re lucky in that regard. We’re all perpetual students, and each project is an opportunity to learn something new.

Most recently, I had the opportunity to work “mobile first.” From a dev perspective, for me, that means I start with mockups of the mobile design. I first define things like typography and color, leaving the grid and layout for a later phase and working up to desktop styles. I’ve always worked “desktop down” in the past, so I found it to be a really interesting exercise with takeaways for my future projects. Getting comfortable fleshing out a full typographic system from the ground up without the context of layout left for cleaner baseline styles. I also found I had to fight the cascade far less, as I was conditionally weaving layout over top of my existing CSS. Most importantly, coding “mobile first” added an extra layer of intrigue that helped keep me focused.

Refine your personal process.

In order to look forward, you must first look back. Before my mobile-first fresh start, I reflected on aspects of my previous projects that were challenging and/or left room for improvement so I could take the opportunity to address them.

In a previous project, I became frustrated by the volume of selectors I rewrote, because I repeated and grouped styles by media query. So, for this mobile-first project, I sprinkled inline media queries throughout my stylesheets. I didn’t have to worry about specificity issues, and my styles felt far more organized.

I also paid close attention to how often I overrode properties in my mixins and extends, trying to keep them as small and as succinct as possible. (Non-devs: mixins and extends are chunks of CSS organized and available in shorthand form.) As I’m finishing up this mobile-first project, I know this is an aspect I need to continue to refine.

One of the things I love most about our industry is how rapidly it evolves. There are exciting things released daily, and fresh starts provide opportunities to both try these new things and hone existing methodologies—without the interference of any past mistakes. Be sure to recognize and harness the joy that the very beginning of a project can bring to your personal process. Be sure to recognize the beauty of the blank slate.

Not only are there countless physical screen sizes, but each handheld device can be held in portrait or landscape orientation—and browsers on a desktop or laptop can be contorted into all sorts of shapes.

So, why has responsive design focused almost exclusively on viewport width? Just like we had to stop ignoring skinny viewports, we need to stop ignoring short (and tall!) ones.

When Things Get Weird

Long and skinny viewports, like an iPhone in portrait orientation, are a natural fit for websites. Their width is perfect for single-column layouts, and their height works well for seeing a whole block of content at once. Turn that sideways, and things get a little weird.

Images often don’t fit in the viewport. Scrolling, awkward zooming, and 11-finger gestures are required to see the whole picture. Large headings and generous line-height can severely limit the amount of text visible on screen at a time, making reading a chore.

Scrolling past a 400-pixel-high Google Map on a 320-pixel-high touch screen is like playing Operation (without the horribly traumatizing buzzer).

In all of these cases, a simple vertical media query would make a world of difference.

In The Wild

The most widely known (whether noticed or not) example of vertical media queries comes from a company I wouldn’t have expected to come up in a conversation about responsive design: Apple. With the company’s device line-up, it’s surprising that Apple really hasn’t even acknowledged responsive design. Yet, Apple is one of few using vertical media queries in a meaningful way.

On the iPhone’s landing page, Apple uses vertical media queries to increase the size of the hero image as the viewport’s height grows. Start your browser at approximately 650 pixels high, and look at the hero image.

In typical Apple style, it’s front-and-center—essentially the only thing on the page. Begin making your viewport a bit taller, and you’ll notice that at 721 pixels, the image size bumps up to regain that center stage focus. Same thing happens again at 1,001 pixels.

When space is available, why not feature the product more prominently? Apple uses vertical media queries to optimize its iPhone hero image for tall viewports but could easily extend that same thinking to small viewports, as well.

Using Vertical Media Queries

To be honest, I have yet to use a vertical media query all by itself. Not to say I never will, but I haven’t run into a use case for that yet. I typically use vertical media queries combined with their horizontal siblings to make minor adjustments and optimizations to an existing layout.

In vanilla CSS, that looks like this:

@media (min-width: 32em) {
    h2 {
        font-size: 2em;
        line-height: 1.5;
    }
}   
@media (min-width: 32em) and (max-height: 20em) {
    h2 { line-height: 1; }
}

I’ll normally have a base style in my main layout query (the min-width declaration above) and will combine that with a vertical query to make adjustments for a particular size.

For my fellow Sass users out there, the above code would look like this:

h2 {
  @media (min-width: 32em) {
    font-size: 2em;
    line-height: 1.5;
    @media (max-height: 20em) { line-height: 1; }
  }
}

Like any approach to our work, you’ll have to experiment with vertical media queries to figure out how (or if) you like using them. I’m sure there are some amazing (and far more complex) examples of vertical media queries out there. For all I know, someone has created a vertically-responsive site that turns into a side-scrolling platformer game (like Super Mario Bros.) at heights less than 100 pixels.

Have you used vertical media queries in your projects? Please share! We need more examples of how to better serve viewports of all heights.