Ben Callahan – Structuring Your Workflow for Responsive Web Design
Podcast: Play in new window | Download (Duration: 30:12 — 15.7MB)
Subscribe: iTunes | Android | RSS
As responsive web design becomes more prevalent, our approach to designing for the web is changing. With former assumptions, as dismissive as they may have been, that the web was a fixed width, it was easier to have a more linear workflow. With the need for the web to reconfigure and adapt to different devices and displays, designers and developers need to adapt to changing workflows.
Ben Callahan of Sparkbox has experienced this changing landscape firsthand. He has found that even down to the core of how they price projects has changed with responsive work. The fact that their development and design process have continued to get more iterative and collaborative has had a ripple effect on all aspects of projects. This has allowed clients to become more involved in the process.
Ben says that getting the client involved from the beginning helps shape the scope and phases of the project. They try to learn as much as they can to inform what it is they’ll do next. He says that his team has really tried to embrace the idea and approach clients with “The understanding that we know less about your project today, then we will tomorrow”.
Check out Ben’s daylong workshop from the UX Immersion Mobile Conference, now in our All You Can Learn Library.
Recorded: December, 2013
[ Subscribe to our podcast via 
←This link will launch the iTunes application.]
[ Subscribe with other podcast applications.]
Full Transcript.
Jared Spool: Welcome everyone to another episode of The SpoolCast. I’m Jared Spool. We have today the great Ben Callahan of Sparkbox, who is at the UX Immersion Conference in Denver in April.
We’re going to be talking about workflow on responsive Web design projects. I’m very happy to be able to talk him about some of the things behind responsive Web workflow today. Ben, how are you?
Ben Callahan: I’m doing well, Jared, thanks.
Jared: You and I were talking before the show. You mentioned this thing that when you’re working on responsive design projects, all of a sudden at Sparkbox, you guys had to start changing your pricing.
It never occurred to me before that working on responsive stuff would actually get to the core of how we price and plan our projects. Everything changes now, doesn’t it?
Ben: Yeah, man, it’s been a really interesting journey for us because when we started, we were very linear in the way we operated. We did a lot of fixed bid work, as many folks still do. No problem with that.
What we have found is that as our development and our design processes have gotten more and more collaborative, more and more iterative, it’s had this ripple effect on all the other parts of what we do. That’s everything from the way that we manage projects, the way that we set client’s expectations, the way that we price our projects. In fact, we’ve shifted, as you were implying, we’ve shifted to working in a completely different hourly model now.
For us, it’s been mostly about really just keeping everybody, including our customer, very, very involved in the project and giving the ability to shift priority, as it’s really needed, sometimes even required by the business that they run. It’s really just about being really easy to work with, as much as it is about helping the expectation, and education, and collaboration of a project be successful.
Jared: An hourly model, that implies that you’re not as comfortable saying what the total scope is going to be at the very beginning. That implies that’s a much more iterative, organic, and evolutionary. I got that implication, right?
Ben: Yeah, absolutely and what’s funny is what we’ll do often now is, Matt Griffin wrote about this recently, but it’s something that he and I talked a lot about and what we’ve started doing quite a bit, instead of trying to gather all the requirements up front, and spend a ton of time trying to get everything just right and documenting, and then putting a price on it.
What we end up doing is we’ll get a statement of work for the customer that will be for 20, 40 hours, something like that. We’ll sit down with them for a couple days, go to their office, or whatever, meet with them, and do some Skype calls. Just try to get a feel for if we’re going to be a good fit even for the project.
We’ll spend that little bit of time together with them, giving them an opportunity to meet us, and vice-versa. Then, we’ll write up what we think is a good approach, a recommendation for how a project might be phased and scoped, but really with the understanding, and my Technical Director Rob Harr says this all the time, “The understanding that we know less about your project today, then we will tomorrow.” We want to embrace that idea, instead of pretend like it’s not true.
For us, it’s really about just whatever we can learn, we want to inform what we do next. That’s how our pricing happens. That’s how our project management happens. This is how everything now is working for us.
Jared: Is this just sort of less about responsive, and more just to the admission that this has always sort of been the way, but now that we’re talking responsive, we sort of have an excuse to be able to say to the client, “We don’t really know as much about your project as we are going to once we get into it.”?
Ben: That’s a really valid point. I feel like a lot of the stuff that, I’m I guess relearning as I do this stuff longer, I feel like it’s kind of that way. We talked about this collective hallucination that we all participated in with the idea that the web is fixed. The same thing is true with a lot of other things. Our linear processes, we kind of made it work, but in the end, there are so many holes in those ideas.
So, for us, I guess I’ve just settled on the fact that everything is up for grabs at this point. We’re willing to change it. We are constantly changing how we work. If you were to ask me again in a week, I might have a different idea for you. We are just constantly changing, and trying to find an efficiency where we can. This is one that has been hugely helpful for our customers, and for us honestly.
Jared: You’ve been successful at it.
Ben: I would absolutely say that we definitely have. When we shifted to doing more responsive work, or really it’s just about building this level of flexibility into what we do. When we started doing that more, we just found that there were so many factors involved. To try and quantify all of those, and get ahead of, and understand, and account for it, in the numbers of an estimate was just incredibly difficult. Not that you can’t do it, but it takes so much time upfront.
In the end, what we all know is that projects change. We try to keep our project duration short as well, so that we can do phases of a project. If I plan out a three month project, for me, to think that my client’s business isn’t going to change from day one until the end of that project, it’s just not true.
What we’ve talked about is trying to find a way that we can adjust our model of pricing and how we operate, so that we don’t punish our clients for their business changing, because that’s just a reality today. That’s, I guess, some of the thinking that’s pushed us in this direction.
Jared: I’m sure you must have stakeholders and clients who are really anxious about hitting a deadline, or getting things done with a certain amount of budget. How do you make sure you get to a completion point that gets them happy, without knowing offhand what the full scope of the project is going to be?
Ben: This is the question that I always get. [laughs] It’s not just from other folks in the industry, but obviously from every customer that we talk to. A lot of times, and I’ll just kind of explain here kind of how exactly this ends up playing out for us. A lot of times when we were doing fixed bid pricing, a customer was committing to us for the duration of a project.
Maybe, let’s just say, it’s a three month project, and it’s $50 grand, something like that. We’ve got some duration. We would look at that. We would say, “Let’s do three payments. We’ll do a third upfront. We’ll do a third when we’re halfway through, and we’ll do a third at the very end.” We would structure something kind of like that.
There are contracts that are signed in that scenario, that commit both parties to doing all this stuff, and making all those payments. What we found is that in order for us to request the flexibility and pricing that we want, we also have to give a little bit in terms of the flexibility for that contract.
What that means is that we don’t ask somebody to sign a long-term contract for us. In that same scenario, we would certainly put some thought behind, approximations, of what the budget should be. We may come up with a very similar number, but it’s all with the understanding that it’s an estimate. We’re doing our best guess here.
Then what happens is if we don’t do our job, if our customers aren’t happy with what we’ve delivered, they absolutely have the ability to walk away. Everything that we’ve done up to that point is theirs.
That understanding means that for us, we’re basically sharing the risk of the project with our customers. Instead of committing to some number, and seeing scope change, and dealing with all the struggles that come along with that kind of management, where there’s change request, and just constant dialogue about that. What we’ve found is if we don’t do our job, we lose it. We have to make our customers happy. We have to show that we’re delivering value for the price they’re paying.
Now, we’ll also say, for us, we adjust our hourly rate to make sure that we’re inline with what will allow us to deliver a really high quality project for a price. In the end, what happens is this becomes a very constant conversation with our customers. It opens up the conversation about money. We find ourselves literally every week talking with our customers about, “Hey, we’ve spent 60 hours so far on this. That’s about where we think we should be.”
But also, it’s possible that, “Hey, we’re a little behind honestly. What we’d like to do is get into a little bit more depth of conversation around the priorities that you have. Let’s get those literally listed, first priority to the last priority, and recognize that we may not get all the way through this list. If something is going to get cut, what should it be?”
It puts those decisions in our customer’s hands, and allows them to prioritize exactly what we work on, obviously with our recommendations for what would be a valid delivery. We get to work with them on it, I guess, is the point. That’s created much better, much stronger, longer lasting relationships with our clients.
Jared: A lot of this came about because you started doing responsive. What was it about responsive design that caused this shift in how you had to interact with the people you’re doing these projects for?
Ben: That’s a good question. I’ve spent some time thinking about that, because it’s not just pricing. Literally, this has impacted everything that we’ve done, and the entire way that we operate. We’ve changed the layout of our office to adjust for this.
For us, we were right, that responsive isn’t necessarily the reason probably. It’s really more just coming to terms with reality, but, for us, really the level of flexibility that we have to build for.
Doing a design, like just a visual UI design, is so much more complex now. Where we used to participate in that myth that there were 1,000 pixel wide browsers that were just always going to be visiting our sites, that’s just not the truth. Now, we think about the idea that a UI, a design, has to work from 200 pixels to 2,000 pixels. What’s the design deliverable in that world?
That messes with your head a little bit, when you’re used to just delivering Photoshop files, and everybody approving, and then moving on. For us, it started by impacting how we work, and then, it from there grew and spread into the idea that, “Well, maybe how we built should change, too.” That means maybe the structure of our estimates needs to change.
That means how we manage the expectations of our clients needs to change. It’s really been a rippling effect for us. The example of UI design is just one of many in the production work that we do every day.
Jared: How much of this is content? Most of the time, I’m guessing, when you’re working with your clients, they’re producing the content. You’re not producing it in house or working with some third-party content production service that they’ve hired, is that true?
Ben: For some of the projects, that’s true. We have a content strategist on our team, Emily Gray, who’s fantastic at what she does. Part of her job, actually, a lot of the same conversations we were just having around pricing and the idea that you give your customers the ability to prioritize the stuff that you work on with your expertise and recommendations, obviously.
We take that same approach with content. We believe that it’s really difficult to do effective UX, and UI, and development without an understanding of the content that we’re going to be building for. We try to do that as early in the process as we can.
It really also is about priority. Steven Hay, and a lot of his work, when he talks about workflow and responsive, he talks about this idea of designing with text. We believe in that wholeheartedly.
We start with that simplistic view of what we’re building. It’s really at that point about priority. We keep things very linear. We try to get a really good understanding of the content that’s required and the content types.
We get those things prioritized. We put them together in scenarios where they’re going to be experienced for our users. We try to make sure that we’re establishing priority effectively.
One thing we’ve seen is, as you lose screen real estate. So as you shift from an expectation, your larger screen is the default, to an expectation, like Luke Wroblewski talks about, where your small screen is your default.
As you shift down to that thinking about that smaller screen as your default experience, we’ve seen that you lose different ways to prioritize. So, the tools that a designer might use to communicate priority are reduced as the amount of viewpoint available is reduced.
That means you really do have to have a very clearly defined understanding of the priority of your content and your functionality. For us, it has to start there.
Jared: How is this designed with text changed the way you guys do your work?
Ben: Let’s see, it really comes back to the idea of priority. Designing with text for us, we talk about content priority guides and content prototypes, those things are the stuff that we’re actually been doing. We try to do as much of that in HTML as we can. Even before that, just a simple doc that shows the content types.
For us, what’s happened is, we start to think in an incredibly linear way. We might say, that we know there’s a series of pages in our system that are required for communication of a certain kind of content.
When we look at those, we did all that content together. Identified the content types, we get them onto a page, and then we can start moving things around with our customers’ feedback. Really it’s linear. Literally, you force people to pick a number on priority. We move that to the top. It’s just top to bottom importance.
Then, when we shift to that very quickly to just static HTML. Our content people write markup for us. I mean you’ve heard the conversation going around, obviously if you’re going to be a designer on the Web, you need to learn to write code.
We think that that’s true for content people, too. If you’re going to work in content, on the Web, you should learn some HTML. It’s really not that difficult. HTML, honestly, a purely semantic approach is not that complex.
There are a handful of elements. Who better to generate clean, simple, semantic markup and the person who bests understands the content. We shift to that role of writing a first round of markup to our UX and our content people.
That helps us instead of doing and writing markup in CSS and based on some Photoshop picture, we’re writing it based on an understanding of the priority. That’s really what we should do.
I’m not naive enough to think that we would just take that pristine, perfectly semantic markup, and that’s all we’ll ever do with HTML because I’ve worked on enough systems and understands that a large system requires a level of modularity to be maintainable. There are all these kinds of things that impact the markup.
I want to start with the ideal. The content and the UX people are the best ones to give us that ideal, that purely semantic HTML. Then, the rest of our team will take that work and just continue to evolve it in the medium we’re going to deliver it, in the browser.
Jared: It’s interesting to me that you’re teaching the content people to actually do markup because, in fact, when I started in publishing, you did that anyways. You bolded the things that you wanted bolded. You italicized the things you wanted italicized. That’s really just applying markup in its simplest form.
You know what you want to be a header. You know the shock that author’s have when they look at their text and the markup is wrong. They go, “Why would you do it that way? I don’t understand.” I bet that the author’s like having some control over the semantics and the markup to emphasize the right things.
Ben: Absolutely. The trick that I’ve learned is just in some previous experience teaching basic HTML to young folks who want to learn how to build for the Web, one thing that I’ve learned over time, that’s an effective tool for teaching this stuff, is to slip a little reset style sheet in, when people are writing their very first HTML page.
What that does, is strips out. I mean, HTML doesn’t have style applied at all. The browsers that we use actually have their own little styles sheets that they apply that apply default styling that’s what you and I see when you type in each one with no CSS and it looks like it’s big and bold. The browsers do that for us.
What I’ve learned is if I slip a little reset style sheet in, that just normalizes everything. Everything just looks like text, period. Whether it’s H1, a paragraph, a link, anything. Just remove all style.
If I do that, it helps people to really understand that all they’re doing is writing content, but they’re adding semantic meaning. They’re not adding design.
We may take that, the implied meaningless, added to what’s marked into the markup, itself and enhance that visually in some ways to help communicate the kinds of meaning that’s being implied. I love the idea of separating that early in the process.
It has to be done in balance with an understanding that the systems that we build have to be maintainable. We find ourselves now, we actually had Jonathan Snook come into our office. He spent a day with my front-end devs, just explaining his system for building maintainable large scale CSS.
It was a whole conversation about, “How do I pick class names?” [laughs] That was the whole day. It’s really important stuff, if you want to build something that’s maintainable.
I understand that in the end it’s almost impossible to deliver purely semantic HTML with no connection to the style. We still have to bake that in. I want to do that after I’ve taken that idealistic approach. That’s my personal opinion, at least. [laughs]
Jared: No, that makes a lot of sense. So now, the way you guys are working this stuff. How many designers do you have and how many developers do you have at Sparkbox there?
Ben: I’ll give you some numbers here. We’re a strange show though. I’ll tell you that before I say this. [laughs] I don’t know what a lot of organizations that are structured like we are, we just have tried to find something that works for us.
We have, there are 19 of us, total in the office now. We have a couple admin staff and then we have a technical director, Rob Harr. A creative director, Jeremy Lloyd. A UX director and content strategy director. Then, we have a team of basically front-end developers and back-end developers.
Most of our people are front-end and back-end devs. You’ll notice we don’t have any person who’s just the standard designer, a UI designer. Jeremy is our creative director, Jeremy Lloyd. He essentially sets the creative direction for every project that we do.
All we do, all day long, is build responsive Web stuff. [laughs] So, he’s got his hands full but what we’ve found is that by bringing in front-end developers who are actually, probably could be designers, in their own right, but their choice, their medium where they are fluent most, is in HTML and CSS.
By having those people on our team, we’re able to just do enough design that we communicate the direction and then entrust the rest of that to our front-end devs. Then, they’ll work very, very closely with Jeremy, the creative director, and we call this scenario “A design pairing situation.”
Jeremy will literally sit with them for a couple hours each week just making sure that the direction they’re carrying his vision out, is the direction he really had envisioned for the project.
Honestly, most of the time if you walk into our office, it’s half the computers have somebody sitting at them. The other half, have two people at them. [laughs]
That just tends to be how we work a lot, is there’s a lot of collaboration, whether that’s a content strategist and a back-end dev, sitting together to figure out how a content management system should be structured or whether it’s this design pairing idea, where our creative director is sitting with a front-end dev just tweaking the details that are so critical to a good project.
Jared: I like this. This is very cool. Even though, you disclaimed it at the beginning from an agency perspective, it may not be that common, but the ratio that you’re talking about is extremely common for folks who work internally to organizations. It’s not unusual to have 20 developers for every designer.
Ben: That’s a good point.
Jared: It seems to me that this idea of entrusting and pairing, is really an important one. How did you guys figuring out how to make that work?
Ben: Boy, man, [laughs] it’s really just been trial and error for us. In the end, what I’ve realized about it is, it’s less about how you do it and it’s more about who you have on your team.
We talk about this idea that the kinds of people we want at Sparkbox are people who have a level of humility that allows them to work with each other and not expect that their ideas are always going to be the best one. People who are willing to hear other people’s critique but also to offer critique in a way that it can be received.
We talk about this idea of expertise. They have to have a great amount of fluency in the tools that we expect them to use. Those two are actually, honestly, very often in opposition to each other.
Finding people who are really good at something but also very humble, [laughs] that’s a difficult find. Then, we talk about this other idea, and I know, I’m sure you have a lot of UX folks, who listen to this SpoolCast here.
We talk about this idea of empathy a lot. I’ve heard it used extensively in regards to UX and gaining empathy for our users. I absolutely believe in that.
I also love the idea that we might find a way to have empathy for our peers on our teams. That’s partly what’s required here, too. Just, in the end, we have to make decisions that are going to be for the good of the project, not for the good of ourselves, as individuals.
Sometimes, that means putting others ahead of yourself. Sometimes, that means sticking up for the thing that you really believe is the best decision for the project, but without an understanding of what the others on your team are going through, it’s really hard to the clarity that’s needed to make really good decisions for the project.
Jared: When you guys are doing this pairing thing, Jeremy’s actually sitting at the same desk, right?
Ben: One computer, two people. Again, especially for a designer, it can be really intimidating to have a bunch of people crowded around their system telling them to move pixels around and what not. [laughs]
The same is true for a front-end dev. It really does require patience with each other. What we’ve found though, and everyone on my team would agree with this, is that the work is better.
Everybody who’s in this industry wants to create fantastic, beautiful things. This helps us do that. If you read about pairing in the development world, there are tons of people who’ve written about this. It’s become a very common practice. A lot of people hesitate to do it because they think, “Well, if I’m going to have two people do one project, that means it’s going to cost me twice as much.”
What we’ve found is that our productivity is higher because people aren’t sitting by themselves, with the temptation to go check Twitter, all the time. They’re sitting with somebody. They’re not going to be constantly flipping to email or Twitter or something like that.
They’re also with somebody who’s broadening their skill set. For a front-end dev to sit and hear how our creative director Jeremy talks about typography, that’s really important for those front-end devs.
The next time that they take one of his style prototypes or something and begin to evolve it into a set of templates, they’re going to make better decisions because they’ve sat with him in the past and understood his thinking.
It’s this cross-pollination. In the end, it brings the quality of everyone, everybody’s skill set gets increased because we do it. It’s really been invaluable to us.
Jared: It sounds like there’s a lot of design literacy that’s coming out of that. A lot of what your doing here, educating the client about the scope of the project and how things are going to change and educating the content people to be able to think semantically and to put the semantic markup into the work that they do so that that’s easier to translate style.
Then working with the developers to make sure that they know more about design and understand the rationale and the thinking and the theory behind what’s happening and not just try to work off a blueprint and hope that when they have to make a decision, they’ve decided the right thing on their own.
It feels to me what you’re doing, is you’re creating a team that’s with your internal folks and your clients that are more literate about the design that they’re producing and more capable than when they are by themselves making a decision because a decision has to be made to move forward. The decision is more likely to be one that’s going to fit the mold of what you’re trying to do.
Ben: You nailed it Jared. That’s exactly what we’re looking for. We’re not the ones that came up with this idea, but I’m sure you’ve heard of the idea of T shaped person.
Someone who has great depth of expertise in a certain area and brings that to the table but they also have the top bar of a T, they have a lot of breadth of expertise, too.
A lot of folks come to an organization expecting that they need to be an expert in one thing. What we’ve found is that the way at least that we work, and a lot of shops are starting to shifting towards on the Web, is the level of flexibility that we have to build for, means that everybody on the team has to have some understanding of all the disciplines.
That helps with the empathy that I talked about. It helps with the humility. In general, it just makes the team better.
In fact, one other little insight, we love this idea of learning that you were talking about. We do the workshops. We travel around. We do workshops. We speak a lot. We require all of our people to write.
Most people, when they start, don’t feel like they have a lot to offer, but what we tried to communicate is that, you just write about what you’re learning. There are so many people who are just a little step behind you and there are a lot of people who are a couple steps before you.
Just find your place in that scale and work to try to communicate what you’re learning, that’s all we need to do. We want that documented. We want to help, if we can, in the industry in that way.
We also, we bring in really young folks in as apprentices. We do that for a six month apprenticeship that’s a paid apprenticeship. It’s great that we get to do that. We work with these young folks to teach them how to do the stuff that we do.
In the end, for me, what’s the most valuable part about that apprenticeship is that I give my team an opportunity to teach, as well. Sit with these young students, who are asking these fantastic questions and challenging my team on why they chose to do something a certain way, really with a level of innocence that’s just really humbling, sometimes.
When those questions come, the next time that person has to do work with an apprentice, they realize, “I’ve got to know my crap.” [laughs] “I’ve got to put my stuff together in a way that I can actually defend what I’m doing and why I’m doing it.”
It’s often happens is that a young person will ask a question that pokes a hole in something that we’re doing. They’re looking at it with a different perspective. That’s an opportunity for us to improve efficiency, to improve our workflow, to find a better way.
I love that stuff. That stuff is inspiring to me. In the end, it just helps everybody.
Jared: You don’t really learn something, truly learn it, until you teach it to someone else.
Ben: Absolutely true.
Jared: Well, Ben this has been absolutely fascinating. I cannot wait to get to your workshop. For those of you who are thinking about this, this is going to be at the UX Immersion Conference.
It’s a full conference that’s going to be talking about all things mobile. There’s a lot of discussion about responsive design. Ben is going to do a full day workshop on workflow about responsive design Web projects.
It’s going to be a lot of fun. I’m really excited about it. It’s going to be April 7th, in Denver. It’s all day. It’s part of a three day conference that goes from the seventh to the ninth.
You can find more information about it UXIM.co, that’s where we talk about the conference. It’s going to be fun. Ben, it’s going to be great to see you in Denver.
Ben: I’m so excited, man. I really am. It’s going to be a blast.
Jared: Cool. So thank you again for coming and making us so much smarter today. I really appreciate it.
Ben: Absolutely, my pleasure, Jared.
Jared: I want to thank our audience. If you listen to this on the iTunes, could you do me a favor? Could you go and take a moment and put in a little review for us? Tell us what you think. That’s how we keep track of it. Look at those things. Other people look at them. That’s really helpful. Just take a second to do that. That would be awesome.
Once you’ve done that again, I want to thank you for spending the time and as always, thank you for encouraging our behavior. We’ll talk to you next time. Take care.