Responsive Web Design, Part 1 (2015)

Responsive Process

BY BEN CALLAHAN

Let’s Start At The Beginning

“The successful respondent to this RFP will provide three static design options for our team to evaluate.”

I’ve never been a huge fan of taking a multi-option design approach, but I get it — sometimes a client needs this.

“Each of these options will provide design for three unique layouts: home page, listing page, detail page.”

All right. Now, we’re up to nine static design files. This is getting a bit out of hand.

“Each of these unique page designs should take mobile, tablet, and desktop sizes into account.”

I was never great at math, but I can do this calculation. Twenty-seven static design files!? Not gonna happen.

This is a real-life RFP I received not too long ago. Turns out, the client was very amenable to a more efficient approach. But this experience really got me thinking… The hardest thing about doing this stuff isn’t actually doing this stuff. It’s working with people while you do this stuff.

You see, almost every potential client out there already has a website. For us, that means most clients are coming to this with a set of expectations, along with their own baggage from past web projects. That baggage can have a drastic impact on how your client approaches the project — and you. To help diminish the negative effects of these expectations, I’ve found the best way to manage them is to be the one who sets them.

It’s my aim in this chapter to help you be more successful with your web projects by starting at the beginning; by working from day one to help set your client’s expectations about what’s going to happen, and by working throughout a project’s life cycle to do the same.

KEY DIFFERENCES IN PROCESS FOR RWD

Before you open your favorite text editor, before you open Macaw¹, before you get your sketch pad out or start sculpting with text², you need to help your customer understand the process. There are many ways to do this, and my least favorite is to just try to sell them on a new process. In my experience, demonstrating value in your way of thinking early — even before a contract is signed — is the best approach. This gives your client the confidence that you know what you’re talking about, but it also means you need to earn their trust to try a new way.

To encourage this, there are four ideals my team and I try to keep in mind as we interact with each other: collaborate, iterate, adapt, and prioritize. Let me briefly explain why these specific ideas will keep you on the straight and narrow.

COLLABORATE

I know, I know. Everyone everywhere is talking about collaboration and how it’s needed to do great work. Well, you know what? It’s true. Of course, you need to collaborate within your team, but there’s another kind of collaboration that’s needed these days — collaborating with your client. I have an important reminder for you: clients are people, too. They may not have your expertise when it comes to web design and development, but they know a lot more about their business than you ever will.

Again, it starts at the beginning. At Sparkbox, I’ve been looking for a way to be more collaborative in bringing new clients on board. As part of this, we’ve been taking a new approach to writing estimates. Instead of a customer coming to us and explaining their project so that we can disappear for a week and come back with The Perfect Solution™, we’ve been inviting them to help us with the estimate. It’s super easy — we call it collaborative estimation and clients love it.

We start with a basic Google Spreadsheet³ that has a few adjustable fields and calculates what we think it will cost to do the work. We begin with wide ranges because we do this very early in the process — typically after just a 30-minute phone call. Then we share it with the client, and we work on it together.

An example of a collaborative estimate, created in Google Drive and shared with a potential customer.

Here’s why this is important: we collaborate on the very first thing we do with our clients. We want them to know that we add more value when we work with them rather than for them. This is just one way we put our money where our mouth is.

We also invite our clients into our team communication channels with us. We’re big fans of Slack⁴ and Basecamp⁵. These tools provide a great mix of formal documentation and informal conversation, both of which are needed to facilitate quality collaboration.

In Daniel Mall’s open redesign of the Reading Is Fundamental website⁶, we all got a glimpse of how Dan brings his customers into the project with him. Brad Frost took it a step further with a GitHub project called “Project Hub”⁷which is a tool for keeping track of the progress of your project.

SuperFriendly’s “Reading Is Fundamental” and Brad Frost’s “Greater Pittsburgh Community Food Bank” project hubs.

Remember, these are all just tools. Tools can help, but what’s really needed is a change in how we think. My friend Kevin Sharon⁸ said something very poignant to me once. He said, “If you can’t say ‘No,’ it’s not collaboration.” I don’t know about you, but I’ve had many relationships with clients in which I didn’t have the authority to push back — even if I knew from experience what they were asking for would not work. These clients come to you with solutions rather than problems that need to be solved.

I’m ashamed to admit it, but I have also had client relationships where the opposite was true. Sometimes my frustration gets the better of me, and I forget that I need my client to be a part of the project. When we hear an idea from our customers and immediately disagree, we’re just as guilty as they at denying a collaborative process. Many web studios are not willing to allow this kind of collaboration in their process, often because they don’t believe their clients are creative or technical enough to contribute in a meaningful way.

Collaboration is a two-way street. Shifting your view of your customers toward them becoming true contributors in your work will result in all kinds of new ways to include them and help you create a better product.

ITERATE

We regularly look for opportunities to deliver a small, high-quality subset of functionality at tremendous speed. Taking an approach like this demonstrates progress early and provides real opportunities to let what you’ve learned create momentum to carry you through a project.

If you sense that there might be political challenges in shifting how your client works, here’s a pro tip (and I sense this in every project we do): working iteratively can help turn skeptics into advocates. Most folks are much more likely to let you try a new way of working on a small phase than on an entire project. Again, the major point here is to demonstrate your value early to earn the trust of your customer.

One way iteration manifests itself is in prototyping. We are constantly looking for opportunities to identify a significant challenge, suggest a possible solution, prove or disprove its validity through prototyping, revise and repeat.

Often we look for the chance to start with a paid discovery⁹ phase before beginning a large project; think of it as dating before you get married. This gives you an opportunity to learn much more about the project and what it’s like to work with this client. Both parties are able to determine if the working relationship is a good fit.

Initial engagements can take many forms, but the primary objectives are to:

•Better understand the scope of the project

•Identify and prove possible solutions to the biggest challenges

•Figure out if the client/vendor fit is right

•Prove you are capable

•Get paid for the above

Your clients will appreciate this approach and you’ll be building a great foundation for future work. And if you learn something that dramatically changes your understanding of the project, you’ll only be committed to a small phase. This learning will greatly inform the next step in the process and push you toward a better solution.

We have a customer we’ve worked with for many years; in fact, we recently started our thirtieth project with them. To me, this is a sign that we’ve found a mutually beneficial way to work together — they see the value in what we offer, and we are creatively and technically satisfied in our work with them. In trying to pinpoint what has made this relationship successful, I keep coming back to our iterative approach. There have been many times when they’ve come to us with a problem and an idea for how to solve it. Instead of just biting off what may be a 12-week project, we’ve regularly suggested smaller, iterative phases that test out possible solutions and have a much lower initial investment. Taking this approach has allowed us to earn their trust. That trust is indispensable in creating a sustainable relationship, and iteration is at the core of it all.

ADAPT

When responsive web design hit the scene, I can remember being struck by the idea that the flexibility inherent in the product we were building was working its way into our process. Samantha Warren¹⁰ said it best: “Your process should be as responsive as the products you are designing.¹¹”

The truth is, there is no perfect process for this kind of work. You and I need to embrace the constraints we’re presented with. Every project, client, scope, timeline, budget, team, tech stack, support matrix is different. The organizations that are successful in this business are the ones that can work within the constraints of a project and still do timeless work.

My views on process are decidedly difficult to explain to a customer. Given the opportunity, I’d probably lock a few key people (client included) involved with the project in a room for a few weeks and give them the mandate to figure it out. Take it from me, clients don’t like to be locked in a room for weeks at a time.

Instead, we have to find a balance between a very rigid process (where each step is laid out and documented) and an improvisational one (where we trust the team to find the best approach as they go). There are many factors to consider in finding this balance. Here are three to start with: the size of the team; the experience of the team; and the criticality of the project.

The Size of the Team

It’s much easier to allow for great flexibility in process when you have a very small team. Two or three people sitting in the same room will be able to keep track of what’s happening without a lot of structure. Take the team size up to six or seven and it starts to get difficult to make sense of the impact of each player on the progress of the whole project. Increase your team to ten, fifteen, or more and it gets almost impossible.

This is very personal for me. When I first started Sparkbox with my partners, there were only four of us. We each had a fairly well-defined role, and we were able to operate fairly effectively without much process. Because we all sat in one big room together, there was constant communication about all aspects of our business.

Now, we have 23 full-time people, plus three apprentices. We certainly haven’t grown as fast as some places — we are very deliberate with our growth — but the phrase “growing pains” still rings true. We’ve had to experiment constantly with when, what and how to communicate. It’s only through this experimentation that we can find a balance that’s right for us.

The lesson here is that the size of your team affects the kind of process you can employ for a given project. Generally, the more people you have on a project, the more rigidity you’ll need. As your team size goes down, you can get away with a less formal process. It’s the responsibility of your project manager to monitor the pulse of the team and adjust the process to keep things moving smoothly.

The Experience of the Team

When you are working with an inexperienced team, a more rigorous process will help keep everyone on the same page. In fact, I believe an inexperienced team needs a concrete process as context for gaining experience. Only after demonstrating success in a more rigid environment can you start to peel back the layers of process allowing a team more freedom in how it works.

This, again, is a fairly personal concept for me, mostly because of how we organize teams for a project. We put together a unique team for each project we take; even during the course of a project, it’s possible we’ll rotate people in and out of the team. This can create challenges, especially if the experience of those individuals is vastly different. Mostly, it’s meant that we need to be conscious of the fact that different people need differing levels of process to be successful. Our project managers monitor this closely and adjust as needed.

We have a lot of experienced designers and developers, so this balance is mostly about spreading out the less experienced folks. Adding one or two newer developers to a highly skilled team will raise the bar for everyone. The new devs will learn from the more experienced, and the more experienced will learn by teaching the new devs. This makes for a win–win!

The Criticality of the Project

The idea of how critical the project is comes from a gentleman named Alistair Cockburn, one of the original signatories of the Agile Manifesto¹². In his writings on “Crystal Methods,”¹³ Cockburn describes the range of criticality by completing this statement.

Defects cause a loss of:

•Comfort (not critical)

•Discretionary money (somewhat critical)

•Essential money (critical)

•Life (very critical)

Alistair Cockburn’s Crystal Light Methods Chart

The more critical our product is, the more rigid our process should be. You might have experienced this if you’ve worked for both small and large businesses. Small, local companies tend to allow you more freedom in how you work because they have less at stake (lower criticality); large companies have much more to lose (higher criticality) if your process doesn’t produce good results.

When I was just getting started in this industry, I worked almost exclusively with small, local businesses. I managed projects with sticky notes, email and a phone call every other week. Now, I’m involved with much larger organizations. Managing these projects requires us to participate in daily stand-ups, retrospectives, and sprint planning meetings. We find ourselves building burn-ups, working in JIRA (issue tracking software), and calculating our velocity more than I care to admit. All of this is because of the criticality of the work — a small percentage of a big enough number is still a huge number. These larger companies understand this, and they have process in place to protect them from those formidable losses.

PRIORITIZE

As the size of the screens we design for decreases, so do our options for communicating priority. Think about it: we typically use things like size, position, order and contrast to help users understand where they should focus. On a small screen, there’s only so much you can do with the size of an object or the position of a headline. We simply don’t have the same liberties as we have when our focus is on larger-screen experiences.

For this reason, it’s critical to understand the priority of content and functionality throughout a system. Luke Wroblewski¹⁴ brilliantly encouraged us to think about mobile devices first¹⁵ to help our clients home in on what is truly important. The truth is, without a solid understanding of priority, responsive web design is just guesswork.

We’ve encouraged this in our customers by making them think linearly very early in the process. (In the “Getting It Done” section below, I’ll share the kinds of tools we use to do this.) Thinking linearly has the benefit of requiring people to pick what’s most important, and it’s this priority that you need agreement on. Establishing this straightaway in your project will lay an accepted foundation to build on, and provide answers to many questions you’ll find yourself asking later in the project.

We recently had a project where our client came to us with widescreen wireframes already put together. They had done this in an effort to save some money, and we were happy to try to work with them in this way. When we started design, the client wasn’t happy with our work. It wasn’t until halfway through the project that we realized the widescreen wireframes didn’t adequately identify the priority of the content and functionality. This was the crux of the issues we were having. We ended up going back to perform some content analysis and prioritization to regain momentum on the project. Had we done that earlier, we could have worked more efficiently throughout the project. Unfortunately, in an effort to help them save money, we had to perform some rework which could have been avoided if we’d just laid the proper foundation first! Lesson learned — establish the priority early.

FOUR IDEALS

As you jump into your next project, keep in mind that you need to include your client in the project. Look for opportunities to collaborate with them instead of just working for them. Remember that the more you demonstrate value early, the more trust you’ll earn. Iteration helps you do this — don’t be afraid to start small! Also, remember that you will most certainly have to adapt your way of working to better suit what a specific project or client may need. Finally, push hard to establish a priority of content and functionality early in the project. This will pay dividends later in the project when questions arise about the importance of certain kinds of content.

Beyond these four ideals, I’d like to provide a bit of a framework for you as you consider what kind of process will work in your day-to-day.