We’re bringing you this special edition of Cognition Roundtable, where Assistant PM Mica McPheeters speaks with our VP of Design Chris Cashdollar about the client’s role in design projects. Spend the next half hour with Chris, as he pulls inspiration from his upcoming presentation at HOW Interactive Design Conference in Washington, DC—“Reevaluating the Role of Your Client in the Design Process.” Specifically, he’ll cover:
- Recent changes in traditional agency/client roles—and how RWD has impacted expectations and responsibilities
- Common communication pitfalls to avoid when working on RWD projects
- Why and how we’ve expanded our tool belt beyond Photoshop
- Tips for helping communicate design intent—and how doing so can help you craft a strategic process for your clients
If you’re interested in learning how to better collaborate with clients, there’s still time to grab a ticket to HOW Interactive Design Conference next week. If you’ll be in attendance, make sure to say howdy to Chris or leave questions or comments below.
Cognition Roundtable 004 — Full Transcript:
Mica McPheeters (MM): Hey everybody, and welcome to another Cognition Roundtable. Today we’re going to be talking with Chris Cashdollar, the VP of design at Happy Cog. And my name is Mica McPheeters, and I’m an assistant project manager here.
So Chris, I hear that we’re going to be talking about reevaluating the role of the client in the design process.
Chris Cashdollar (C$): For the past few years, as responsive design has kind of become more the norm than the exception in the work we do, it’s created a lot of new headaches, and kind of hurdles for us in the design process to ensure that we are putting forth the right type of design artifacts for our clients, keeping the project moving ahead swiftly, purposefully; not wasting time, too.
And from that, I’ve had to work with our design team here to really look at the process and say okay, do we have the right tool sets, and are we using them at the right time Ultimately, this is important because when you’re considering the fact that we are creating really complex, interactive solutions for our clients big and small, there’s really a lot of opportunity for error, if you aren’t really taking a look at your process, and saying are we putting forth the right thing at the right time, evaluating it, testing it, and ensuring we aren’t wasting our clients’ dollars and budget time.
MM: It seems like you’re taking a really proactive approach to this. How has the traditional agency/client role changed recently?
C$: It’s really changed a lot of our tools in our tool set, essentially. When we consider what we have in our design process, but it’s also mad us reevaluate when and why we use these tools. For instance, four or five years ago, to articulate design intent you would probably 99% of the time create a whole bunch of paper wireframes, and essentially recreate the content needs, functional needs, hierarchy needs of a website, in paper, and get that in front of your clients, and then review it. It might be 12 pages long. It might be 60 pages long. But it was essentially a dead artifact. And they’d have to kind of evaluate your thinking in this kind of very non-digital form, and tell you yes, this captured everything, or we would revise it as needed.
Unfortunately, that’s a layer removed from what you actually are creating. It shows design intent, but if you consider what responsive design creates, the new set of problems, thinking about things in a fluid manner, paper isn’t going to be fluid for you. So you can’t really evaluate whether or not your proposed design solution on a small screen and a big screen is correct, or going the right direction, unless you’re making now multiple layouts per page. And now you’re basically multiplying that effort two-, three-fold, depending on how may kind of core break points you want to maybe work into your design.
So instead, we’ve taken a lot at other things. We’ve looked at HTML prototyping as a way to kind of evolve paper wireframes. So instead of creating page after page of the layout, we’ve taken a lot of that effort and put it into a framework. We’ve been using ZURB Foundation as a way to get quickly into a framework that allow us to articulate content needs, functional needs, hierarchy of that content in something that is responsive and allows us to work in a manner that’s a bit more fluid, that’s a bit more realistic. We can start to see and play with the content and functionality and breakpoints in order to determine how well the design solutions coming together with this type of artifact.
We’ve also found that sometimes you can’t go all-in on that. Some solutions need to be looked at a bit more singularly. For instance, we’re working on a large project now for a consumer-product website, where the core transaction is e-commerce, essentially, and it includes a lot of things like very robust account management, menus, checkout carts, things of that nature.
When you’re tackling an entire project of this scale, you have to start looking at some of these individual patterns, some of these individual interactions and say okay, we probably should really just think about this navigational structure. We should probably look at what happens here at the different states of the account set up, and how the consumer manages this, and look at that pattern outside of the whole of everything.
Yes, we know what’s going to be on the page, but we really need to get this menu system right. We need to get this account system right so that if this page translates to small screens, we need to look at, and evaluate that everything’s there that needs to be there. It’s working on all the small screens, and we’re not kind of hiding something that the consumer actually needs.
It’s being aware of employing the right type of focus on the right type of thing and finding the right artifact to pair with that effort. It’s a bit more of a challenge, of course. It forces our teams to be a bit more self-conscious of what tasks they need to be focusing on. Of course, it allows our project managers to have to manage a lot more touch points with our clients as well, but ultimately what we get out of it is the collective understanding that we’re moving in the right direction.
As opposed to throwing a lot of very complex problems into a single deliverable, and expecting our clients and our users to say yes, this is correct, right away, and not really evaluate each of these decisions independently, which is ultimately what it demands.
MM: On that topic, when you have a client who might be used to the traditional “I want to redesign my website,” but they haven’t been exposed to responsive web design before, that’s a pretty exciting thing. How do you go about introducing that to them?
C$: What we look at when we put together a design process for our clients is we consider the role of education in this equation. I don’t think any more that you can just assume that client services is just going away and creating. I think because we have our clients very heavily involved in our process, we have to expect that there’s going to be things they don’t understand, and it’s our job to ensure that they understand the purpose and reason why we’re prescribing or recommending certain tactics, techniques, artifacts.
There’s a sense of patience that has to emanate from everybody on our team because we want to make sure that our clients understand why we’re doing something. So that means there has to be an aspect of our role that is very much about education. It’s about informing those who need to know something at the right time, with the right type of tone, and demeanor so that there isn’t a misunderstanding. Misunderstandings often lead to pauses and hiccups in the process which of course, if you’re in a deadline-driven business like we are, those things add up over time, and they can eat away at the overall metrics of success for a project.
MM: You mentioned design intent earlier. What does that mean when it comes to crafting a strategic design process for your clients?
C$:Design intent is something I’ve kind of felt really strongly about recently. I read an article a few years ago about design is the rendering of intent, I think was the quote. It’s from Jared Spool. And our design intent is manifested in everything we do in the design process. We don’t like to make dead artifacts. I mentioned that earlier. We don’t like to make things that are created for the sake of their creation. We want to make sure everything we’re doing is driving the purpose forward; it’s educational, and it also demonstrates some aspect of our recommendations of our design intent.
Now, you could say that the end result, the site itself, the code that goes live, that is the manifestation of all of our design intent, all of our working towards. And so everything that we create along the way, our kind of yellow-brick road of design deliverables, these are things that have to carry some sort of understanding or some sort of communicative power of our recommendations. So you could say that HTML wireframes are a very strong artifact in rendering design intent for some small-screen patterns, and how patterns change, based on view-port size.
You could say that Photoshop documents and comps are a great artifact to drive brand and identity intent in the aesthetic purpose for getting that checkbox marked off. We’ll create really robust design—pattern libraries, and once again demonstrate a lot of our design intent for key interactions and the atomic-level components of the design system. Ensuring that our client can maintain and govern their site long after we’re involved.
So every one of these pieces has a role and a goal in the overall process. Each one kind of carries their own flag of design intent along the way. When you step back and look at everything all together, that essentially is the entire demonstration of the strategy. It’s the demonstration of everything working together, hand-in-hand, in order to carry the strategy through, to ensure that what ends up in that end goal is the proper gestalt of all of this, and is actually demonstrating what we intended to occur.
MM: When you’re thinking of different ways to present the information to your clients, do you do a lot of research online? Is there a sub industry that’s coming up with innovative ways to present?
C$: I wish there was. I wish there was some sort of magical realm we could peak into that knows, and does this, and knows all the answers. The answer is no. What we do is we have to keep our ear to the ground, and we also have to be good listeners. We have to understand the problems we’re trying solve, and really look at everything together. Step back and say we’re not just going to blindly go into an artifact we know has worked before. We’re going to evaluate the problem and then prescribe a solution for the right kind of piece of the phase that we’re tackling.
There’s a lot of people out there doing great things like this. One person I admire very much, Dan Mall, he and I have talked about this a lot. He’s somebody that I take inspiration from too. He understands that you look back at the problem and you don’t try to just Photoshop it to death. You don’t try to just build it to death. There’s very key, distinct things you get to get buy-in from your clients, at key points in time, that can help you just keep moving on, keeping the momentum positively moving forward, without having to dedicate 120 hours to just Photoshop work before you can get approval, per se.
As a whole, the industry’s moving this way, slowly. It’s a big change. Historically designers were more comfortable with putting their nose into a computer, into Photoshop, and just designing as much as they can — designing the solution all the time.
For us, we have to step back and say design isn’t Photoshop. Design is the aggregate of all these different things we can do to make sure that our intentions are communicated, so that then they find their appropriate spot downstream, in the final execution of the site itself.
MM: What kind of indicators come up in a project that tell you okay, we had planned to view Photoshop comps at this point, but I think we need to do some HTML now?
C$: Good question. Time and budget will always have some sort of bearing on what we should be using. But sometimes certain things crop up that can be key indicators of hitting pause, an evaluating again. For instance, last year, we did a design for a Spanish-language newspaper. And initially, the project scope called for HTML wireframes, which before we started working on the project made sense, because we’re dealing with a lot of content types, a lot of module types, a lot of navigation.
It made a lot of sense to say let’s dive into HTML wireframes right away, as kind of the first core artifact. But we found out, after diving into some of our discovery work, and user research, and stakeholder interviews, was that actually there’s kind of two core problems that had to be solved early on in this process.
There was the editorial process, which is essentially the experience that most of us use newspapers for, which is the content itself. And there’s also the advertising component, which is basically funding the newspaper itself, which is all the ad buys that are around the content that you are often aware of.
These were two strategies that had to align and we had to figure them out at the same time, but working with different teams. That means we couldn’t just kind of dive head first into very time-consuming HTML wireframes without better understanding that advertising strategy first, and how that was going to impact the wireframes themselves.
We had to hit pause. We had to say okay, it actually makes sense here. Let’s go back to paper wireframes, and sure enough, we spent a little bit more time creating something a bit lower fidelity but we could get earlier buy-in on this. That ensured we didn’t waste a lot of time by just kind of creating HTML wireframes, that could ultimately have been misaligned to the overall advertising strategy. It would’ve been a big miss by us and a waste of time, effort, and budget, and might potentially put the project deadline at risk.
We have to be aware of those scenario. We have to be aware also of the brand itself. I think brand and how we articulate brand in a digital experience is something we have to be confident we’re going to do right. Often, we’ll take a bit of extra time at the beginning of a project to ensure we really understand our clients’ goals for where the site needs to go, aesthetically speaking.
We have a lot of techniques and tactics we’ll employ, exercises in our kick-off workshops, or even kind of competitive analysis exercises that we’ll conduct with our clients to uncover potential biases that might exist on their team about where the aesthetic needs to go, or might even exist between our two teams about where the aesthetic might go.
For example, if I say the word — I don’t like the word, but if I say “clean design” to you, you might have something in your mind when you hear that, and I might have something in my mind as well. But we need to understand if we have the same understanding of that word. If a client comes to us and says we think the site should be X aesthetic, we need to make sure there’s no ambiguity between our two collective brains and what that term means.
MM: How has this forced your designers to adapt and expand their skill set?
C$: Tough one, good one. I respect our designers a lot. And I know that this has put them into situations where they’ve had to expand their skill sets a bit more in the last couple years. I think it’s made them stronger designers. I think it’s helped them better understand the solutions they’re recommending. And I think it’s helped them communicate not only with our clients better, but with our development team better, as well.
What happens is our designers need to be a bit more adept at helping to create essentially what could be any one of these different pieces, or artifacts that prescribe design intent. That might mean that they have a hand in conducting stakeholder interviews, or user research. It might mean they have a hand in crafting the actual communication strategy the new site needs to achieve.
That definitely means they’re probably going to have their hand in creating some sort of wireframe. It could be an HTML wireframe, it could be paper wireframe. It could be something like a keynote, which we’ve been messing with a bit in order to articulate interaction. Anything that they can potentially do to illustrate and educate our clients about our preferred interaction, aesthetic, articulation of whatever, I encourage them to do so. That’s getting out of Photoshop and finding the best way to communicate something.
Video is great for that. Motion is great for that. Interactive tapes are great for that. They don’t need to make these things real. They can be faux, emulations of interactions but the point is to decide specifically what they want to communicate, and then make sure that whatever they’re using to communicate it is clear and as purposeful as possible.
MM: Have you seen that this fosters an enhanced sense of exploration while they’re working on a project?
C$: Definitely. It forces our teams to work more cross-discipline. It also creates more of a shared understanding of the goals of a project. No longer do we have pass-the-baton type of responsibilities. Our developers, our designers, our project managers all have a shared understanding of what we’re trying to create together, very early on in the process. And you can’t really check out.
I encourage everyone to work together to find the best path forward. Hear at Happy Cog we say we don’t have UX designers. We have a shared responsibility across everyone for user experience. That means our designers and developers are all equally responsible for creating a solution that’s powerful and purposeful and meets the business goals and goals of a project.
(MM): What are a few of the common client communication pitfalls that you’ve found you need to avoid?
C$: I think in the past it was easy to use email as a crutch for getting on the phone. When I say education, what I really mean is demonstration. Demonstration with clear instruction, so when possible, make time to talk to your clients. When possible, make time to get in front of your clients.
Important deliverables should never be done over email. Of course, this isn’t always realistic. It’s important to maybe in a case where budget is tight or time line is tight, identify just the key points in the process, where you know you need to kind of heighten your interaction with your clients.
Look for those problem areas where you know there are stakeholders that need to be involved that have some sort of level of input that could definitely affect the future of the project as well. Make sure there’s opportunity to kind of get in front of them and help them understand where the project’s going.
That said, every time I present something, and I also encourage the teams to present something, you give a bit of history. You give a bit of understanding to the attendees, of whatever you’re presenting, or describing how you got there, what the intentions of the meeting are that you’re in, and ultimately how you would like them to frame and shape their thoughts moving forward.
It’s kind of basis meeting 101 stuff. You want somebody to understand why they’re sitting there with you, and what the purpose of the meeting is. But when you reference the history, you reference the goal, and you essentially put a bit of boundaries around what you want them to focus on. It helps align everyone in the meeting. You reduce that opportunity for somebody to go rogue and wanting to revisit something that maybe is already approved or already agreed upon maybe a couple meetings ago.
You look for opportunities to once again shape the conversation. I equate this to teachers. Teachers craft lesson plans. They craft syllabi. They put their students in a situation where they can be successful. I like to think of every time we present work or we present design thinking, we do the same thing.
MM: What’s next for you now?
C$: One is I think Mica we need to continue to explore in the design process better ways to communicate our design intent. As I said earlier, we’re starting to experiment with more animation techniques that once again demonstrate interaction. We’re looking at new tools that can help us reduce that boundary between what we want something to be, and the method in which we communicate to our clients.
I’m excited to speak at HOW Interactive Design Conference in DC and share these ideas with a lot of interactive designers coming in from around the country. Hoping also to potentially start talking to more colleagues and industry peers out there about this topic. And see what else we can learn and roll into, collectively, client services that once again help us better communicate with our clients, and also keep the quality high in what we’re actually creating.
MM: Thanks, Chris.
C$: This was great. Thanks, Mica.