Full Transcript

Adam Churchill: Hey, everyone. Welcome to the SpoolCast. A little while ago, Ben Callahan presented a great virtual seminar for us on responsive workflows. Now, there's over 175 UX seminars like Ben's that are part of UIE's All You Can Learn, if you want to get a hold of this presentation. In today's podcast, Ben is coming back, and he's joining us to discuss some of the great questions that were asked by our audience in that virtual seminar. In the seminar, Ben shares tips and techniques from giving and receiving design critiques to pitching ideas before they're fully baked to establish a responsive workflow that's focused on the end product. He shows how to bridge communication gaps, and establish clear design goals and build trust between management and project teams. Hey, Ben, thanks for the spending a bit more time with us.

Ben Callahan: My pleasure, Adam. Thanks.

Adam: For those that weren't with us for your presentation, can you give us a bit of an overview on what you presented that day?

Ben: Of course, I got a chance to talk with your listeners about this idea of a more fluid process. Ironically, I started the day off with a statement that I generally hate presentations on process. I wanted to start with that, because I've seen a lot of them. A lot of people talk about this stuff. A lot of times, we draw a lot of pretty pictures, and beautiful diagrams that illustrate it. But one thing that I've found is that we don't get into the details of what that actually looks like day-to-day. Not only that, for those producing the work, but for those of us who have to manage a team, one of the things we need to think about in terms of creating an environment where a more fluid process can exist. That's what I started, and tried to quickly make the point that there is no one way. There is no perfect process. That's a myth. I don't know why exactly that's such a strong belief. But everybody, they're looking for that one true way of how to do this work, especially, when you add the complexity of cross-device consistency and building stuff that works at any resolution on any device. When you add that level of complexity in, there are so many factors that make it pointless to the idea that there is no perfect way to do it. With those foundational ideas, I tried to guide us through a handful of the things that we do. We've stopped focusing so much on deliverables, and we've started thinking about this idea that we need to collaborate and iterate to the one deliverable that we do have in this whole deal which is the thing that we're building. In the case of maybe a university, the deliverable for them might be a website, a new public facing site. In the case of some other position, maybe it's a web application behind authentication. Whatever it is, that is our deliverable. We need to keep that in mind. All that does is that keeps us focused on waiting to do our refinement until we've got something in the medium. I covered things like style comparisons and style prototypes and a little bit about element collages, and some of these ideas that are tools that we use early on in the process to try, and get an understanding of how one of our client's brands might translate to the web. As opposed to spending a week in Photoshop copying an idea, we can spend a few hours getting a direction established. The same thing is true as it relates to content. In parallel with that thinking about style, we may be doing the same thinking around content, prioritization of content functionality on an individual page, but also in the system, and also across all the different viewport widths that we have to support. From there, I got into this idea, where another thing we've seen really benefit our projects is giving our clients visibility into the dirty underbelly of how things actually work. From the very beginning, we invite them into help us with our estimates. We do collaborative estimation, and we're trying to get a first step in the process taken in a real collaborative way. Then, all the way through, we give them full access to everything that we're doing throughout. They may very well pull up a part of the project in a middle of the week somewhere, where things are broken, and that's OK. They're going to see that brokenness, and they may ask a few questions, but that's part of the process, too. We want them to see that. We give them full visibility in. Then, I shared a little bit about, what I'm really passionate about in terms of process, which is how we develop teams, and how we develop individuals that are able to take all these different varying factors in, and come up with a good approach. My idea here is that we can't come up with a perfect process. Instead, what we need is a bunch of tools that we can use. When the problem presents itself, we know which tools to use. But then, a shifting of our focus on to people instead of the process so that we can focus on developing the people who are solving problems everyday. If we focus there, then, we can embrace this idea that maybe our team can improvise a little bit. When they find themselves in a situation where they haven't solved these problems, which honestly, happen on almost every project we're on these days, when they find themselves in that situation, they are smart enough to go and figure it out. That's the direction of the virtual seminar that I shared with you and your listeners.

Adam: Very cool, you've evolved this process over years of working with lots of organizations. What's happening when you present this to them? What are the concerns that they offer up or maybe the challenges that they poke back at you with?

Ben: That's good. Most commonly, I would say, I find that these ideas are significantly difficult for an organization that is structured in a way that it's in opposition to the process itself. What I'm trying to say, that's a really complicated way of saying, that I think we've structured our teams in organizations around an old way of thinking, a very linear way of thinking. I go into customers, meet with their teams often. Many times, I'm sitting in a conference room, maybe on site with a client, where I've got two or three people from IT who are responsible for hosting the site and making sure that it's fast. I've got somebody from a marketing group or a PR side of the organization that's focused more on the content. I've got somebody from a user experience group that cares about the design and the usability of the thing that we're building. We have these silos of individuals spread out across all different locations, and sometimes, not even in the same buildings, not even in the same countries occasionally. This process that I described is much more collaborative. It requires all of those people to work together. We're a smart industry made up of really smart individuals. We can solve technical problems, but the stuff that's the most difficult, and, for me, some of the most interesting, is figuring out how to get people to work together on this. That's why I wanted to share a little bit about how people learn, and how it's a painful process to stay current. A lot of those things are really relevant as it relates to organizational change, as well.

Adam: Ben, one of the things our audience is always after is the tools and resources that somebody like yourself and your entire team at Sparkbox uses. Talk to me about the tools that you're using to accomplish this. One of the specific questions was about coding, but certainly, I know a lot of what you have to offer is more of how you're communicating internally.

Ben: Sure, to address the coding question, we've got a room full of folks who are very good at writing code. We have a lot of front-end developers and a lot of back-end devs. Everybody sits in the same space. In fact, our front-end developers probably could mostly be designers in another organization. They're very, very good at design. They happen to choose to use HTML and CSS and JavaScript as their tool for design. In terms of coding for that group, we've got people who use Coda which is an editor. We've got people who use Sublime Text. We've got people who use VEM, and we use a lot of GitHub resources. We're big fans of their whole software of GIT in general, but of GitHub's implementation. We do a lot in there. We track issues in there. We invite our clients in to that issue tracking world with us. In terms of communication, internally, we use SLAP, which is a slightly newer real-time communication tool. The nice thing that we like about it is, well, there are a couple of things. First of all, it's fully searchable. Again, a full archive of the information exchange with our clients and internally here, we invite our clients into that tool with us. It's easily searchable and archivable. All that stuff stays with you for the duration of your project, and even beyond, if you so choose. The other thing that I really like about that tool is I don't know that this is super intentional on their part, but the way that it's structured. Any individual on my team who has full access to our organization there -- that's pretty much all of my team -- they can see all of the channels that are available. It's not like other real-time communication tools where you have to be invited to participate in a conversation. In this situation, you get to choose what conversations you take part in. What's interesting about that is that we have a lot of individuals who are interested in other things that are happening on other projects, they'll be in those channels and SLAP, as well. They can contribute because they have experience from other projects that's relevant, even though, they're aren't maybe necessarily specifically assigned to that job. I love that cross-pollination that that facilitates. It's really been interesting to see how that's impacted our projects. We also use more standard tools like Basecamp for project management, depending on if that's a need, that level of PM work is a need. We also are huge fans of Google's document stuff, their spreadsheets, and their documents. I guess, a really good example of that -- I hinted at this earlier -- but we do this thing we call collaborative estimation. If somebody reaches out to work with us, the first thing I do is get a rough understanding of their scope and put together a Google spreadsheet that I literally just share with them. We call collaborative estimation, because I'm putting numbers in there, they get to see it, and we get to work on that estimate together. We do the exact same thing with all of our other project updates as we go, we have a content priority guide that's done in a Google Doc. We do it that way so that our clients can get right in there, and make changes and suggestions and comments. That real time collaboration that those tools from Google provide is just amazing, and it's incredibly helpful. I know there's something I'm forgetting, but those are the big ones, I suppose.

Adam: Just to follow up on that, what in particular do you use for making sure that the entire team is looking at a timeline, a deadline? Are you using that BaseCamp functionality with to-dos and things like that, or does that exist elsewhere?

Ben: Yeah, we definitely sometimes use that. We sometimes use BaseCamp. We also have weekly, we encourage a very, very regular cadence of conversation. We do at least a weekly meeting with our clients, and every week we are talking with them about the scope, and the timeline. That's a conversation that we have, every week. And we also talk every week about budget. Most of the time, it's just enough to say "Hey, we're on track", but what that means is that every week it's just an item we need to make sure we've covered. If we find ourselves just a little behind, we can say early in the process "Hey, we're a little behind." We need to start prioritizing things, and that puts the decision for what gets done and what doesn't get done in the hands of our client, as opposed to us pretending we're on track until the very end, and then, struggling to say we are not going to quite get anything done. We want to invite them in to help us make good decisions for their projects, that's where we talk about that stuff. We also have used Google calendar for tracking that sort of thing, but Base Camp is good for that.

Adam: In the presentation, one of the things that you talked about. I know it's just a piece of the puzzle, but it got a lot of traction in terms of the questions that were asked. You spoke of the content priority guide. Can you define that again, and say a bit more about it?

Ben: Sure. Yeah, one thing that we noticed is, as an organization, we're focused on, we're really specialized on building stuff on the web. What's interesting is most of our team, we have a career director, a content strategist, a director of UX, a technology director, but everybody else just writes code and works on stuff that we're building all day long. What's interesting is we have just a little bit of a touch into all these other aspects like UX and content, where we realize that they're hugely important for the success of the kinds of work that we want to do. And so, when we have an opportunity to work with a client who may be, from a budget perspective can't afford to bring in a content strategy specialist, another organization that just does that. We have enough people on our team that understand that that we can work with them at an introductory level. And one of the things that we've been doing there, it really comes back to trying desperately to understand what the actual priority of everything that exists in their system is, and we call this a content priority guide. It's part information architecture, part simple content modeling, and may be a little bit of an audit of some kind. We do this in a Google Doc. I think Emily Gray, our content strategist, has written about this on our blog, called The Founders. I can maybe, somehow share a link with you on that. But it's a good tool for very, very quickly getting a sense of the unique types of pages that exist in a system, and the types of content that exist on those pages. And because it's linear, it forces the conversation of priority. And so, this linear approach means that we're really forcing our client to say this is the most important thing on a given page, or in the system. And they're again, in the Google Doc, they can comment or they can move things around. They can ask questions, and we can work on that together. That's the goal there.

Adam: What are some of the other ways that your team gets their head around, or understands the priorities of the content?

Ben: We use these content priority guides early in the process, but they don't include real content. They include, that's what I meant by hinting at content modeling. It's more about the kinds of content that exist. We also do something called content prototype, which is in HTML. We ask our content strategists or UX folks to write that markup. One of the things that I've been thinking, you've heard the conversation for a while about, if you're going to be a web designer, you need to learn to write some code, some CSS. I believe if you're going to be someone who works in content on the web, you need to learn to write some HTML. And who better to make semantic decisions about the markup of the content than someone who fully understands that content? We ask our UX and content strategy people to write those content prototypes, and then, includes real content. Obviously, we wouldn't do this for every page in a system. There may be thousands of blog posts in this scenario. We pick one of those, and demonstrate. But the idea is that we start with that purist model of semantic HTML with almost no style applied at all. And that means that we're focused on the content, we're focused on the priority. It's very linear because it's not laid out in any way. That's one way. Another way would be, this is a little bit cheesy, but we actually do our wire framing at a really narrow width. This hearkens back to Luke Wroblewski's writings about mobile first, but this idea that we should be using small screens as an opportunity to filter out a lot of the crap that we try to put on our websites. If you're limited in real estate, the view port width and the height are small, if you're limited in the amount of space you have to present something, then you're really forced to prioritize. And I think that taking that approach from the very beginning, when we started thinking about something that's more functional, where we may use a wireframe, we want to do that small. We want to do it narrow so that we're really understanding the most difficult implementation case, the absolute smallest screen that we're going to build for. And then, we find that it's much easier to take an approach where that can grow and expand up into something that's much larger for a wider viewport width.

Adam: Very good. There were some questions, obviously people were thinking about business strategy and how this process that you are teaching them to use, how they work that in. How does an organization's business strategy, or the structure of it, tie in or maybe even conflict with this process for responsive workflow?

Ben: That's good. Man, I think in my mind it's about looking for any efficiencies we can find in the way that we work. If you talk to any business owner, they're going to be on board with that. If you can get the work done a little quicker, if you can avoid spending a bunch of time traveling down a road that's just not the right path for their project, then they will be on board for that. That's why we look for very regular conversations with them. That's why we invite them in to help us make decisions along the way. I really believe that a lot of people in our industry get so frustrated with clients, they feel like clients are idiots and they see these broad posts, entire Tumblrs dedicated to ranting on clients. What's amazing to me about this is that every project I've ever been a part of, the client has been the key to my success. They hold the knowledge that I need in order to be successful on this thing. They know the most, of anybody, about their business. And so, we take the opposite approach, it's more about trying to understand what it is that they actually need and working with them to provide our expertise. It's how to build the stuff on the web, and how to make it accessible and how to adhere to the standards that are needed, how to build something that can work at any resolution. The client realizes they need some of those things. That's why they've brought you in. You can't do it on your own. I definitely think it's one of the best industries to work in web design, development, usability, because we get to learn so much about so many different businesses. For me, it's about really trying to understand what they actually need, playing that level, that translation layer where you hear what they say, but understand what they actually mean. It's a skill that will always be valuable for us. The way that we try to do that is taking small steps in varying directions to make sure that our client's on board, and turning the ship a little bit at a time as opposed to going far down the wrong path.

Adam: With that in mind, there was a question that came in through Twitter during the virtual seminar, and it asks, "How do you deal with those clients that go way overboard with iterations, and actually in some cases, when they have access to almost real time development?" Can you say a bit about that?

Ben: Yeah, this is good because this is actually one of the largest criticisms of this approach. Inviting your client in means they get to see your dirty laundry, and they may have a lot of ideas about the progress of the work that you've done when you haven't even really thought about the stuff that they're talking about yet. This is good, but the idea that a client may actually, I guess, I think you said, "Go overboard with iterations," that's a real possibility. But, honestly, this approach actually saves you more from that. Think about these two alternatives. One alternative is I do what I've described. I do a little bit, maybe I do a style comparison, which is super simple, six, eight questions. We show somebody other websites that are maybe dark and light, and we say, "Which one's right for you, illustrated versus photographic? Which one's right for you?" We start to gather really quick initial feedback from them. I could do that, and then I could put together maybe a style tile of some kind, a static image. It's a handful of design elements that we think are appropriate for them based on the feedback we got, put that together. Now, all told, I've probably only spent maybe a full day's worth of time, maybe eight hours, say. The alternative to that is what we've done traditionally which is from a UI standpoint. My designer disappears for a week. I come back with 30 to 40 hours build later, and I've got a Home page and a Content page. I present those to my client. Now, the alternative, these two alternatives, if this is a client that has a lot of feedback and wants to have a say, they're going to be very involved in the small, little decisions that you made, the style comparison, and the style...they may not like the style tile, but you've only spent eight hours. If you get 30 or 40 hours in, and then they now get an opportunity to give you feedback, you've wasted three times the amount of effort, maybe four times, maybe more. You've got to go back to ground zero again. I feel like this actually helps. A lot of times, those clients, they want a voice, and they react like this occasionally, where you feel like maybe they're giving you too much feedback, but they're reacting to the fact that you're not giving them enough. Sometimes, what we see is when we invite them in, and let them have a say, then they back off. They feel like they're part of the conversation. They're being heard. This, honestly, has never happened to us like this guy or gal is asking. The idea that a client because they're seeing every little iteration, they're going to go overboard asking for lots and lots more. Instead, it quiets them, and they get to see the progress. They feel like they're being heard. I feel like it's an actually good anecdote to this challenge.

Adam: Cool. Ben, this was great. Thanks for spending a bit more time with us.

Ben: Of course, my pleasure.

Adam: To our audience, thanks for listening in, and for your support of the Virtual Seminar program and UIE's All You Can Learn. Goodbye for now.