Responsive Web Design A Myth about Process

[00:00:00]
>> [MUSIC]

[00:00:05]
>> Ben Callahan: Okay, let's jump back in. Any questions as we jump into process a little bit here before we get into this? Okay, I want to quickly get an idea of sort of what you guys actually do on a day-to-day basis. So how many project managers do we have, one?

[00:00:24] Okay, how many content strategy or copywriters, people who are in charge of getting the content together? No content people? Okay, how many front end developers, you write HTML, CSS, JavaScript? Okay, designers, UI kind of designers? One designer, are you kidding me? Wow, two designers. Okay, how about user experience kind of stuff like wire framing, architecture, a couple of those?

[00:00:58] Okay, a handful of those. What about back end of, your in the on the server, database, that kind of stuff? Okay, project manager and back end dev?
>> Speaker 2: I do everything.
>> Ben Callahan: You do it all. You should be up here, man. Awesome. Okay, what did I forget? That's it.

[00:01:18] Okay, all right, so mostly front end devs. It's funny, I think one of the reasons I think that responsive web design has become so popular so quickly is because we put so much power in the hands of a single role in our process. You know, the front end developer could make a decision, whoever is writing the CSS, could make a decision at any point in the time in the process that they just wanted to make the site responsive.

[00:01:47] And what I think that's resulted in is a bunch of web sites that are definitely responsive, but that are actually not very usable. And so what I think we need to do is start to invite some other people into the conversation. I mean, we have completely changed the way we build sites in the past two years because we've just found that taking these techniques that happened, primarily in CSS, and just kind of cramming them into our existing process doesn't really result in good stuff.

[00:02:19] [LAUGH] So let's talk a little bit about process, and I don't want to spend a lot of time on this, but I think it's really important for us to hear. So let's start off with a myth about process. A lot of people out there I think believe this.

[00:02:34] Each client deliverable needs to look more like a final beautiful end product than the previous one, right? It's like you're on a journey. You're taking a step with your clients. They expect that each step that you take should look more like that web site that they gonna get at the end of the day.

[00:02:51] And when I say clients here, I don't necessarily mean that you're necessarily always in a service organization, you may be internal at a company working on a product. You still have clients, you still have somebody who's got to approve the stuff that you're building. So what does this result in?

[00:03:08] Pushing towards nearly designed wire frames quickly and completely designed comps soon after, okay? And I think that this kind of gets us in trouble. We've been actually creating throwaway deliverables for a long time. We've been making pictures of websites. [LAUGH] And we should be making websites, right? I think we do those things to try and convince our clients that they hired the right guy or that we're, you know, good in our position.

[00:03:38] So a better mindset that we might start to consider. Deliverables that best serve the organization and prioritization of content in function across multiple resolutions. If we can get this stuff down, then we're gonna have a much better chance of creating a usable experience at any resolution.
>> Ben Callahan: So the first Venn diagram of the day.

[00:04:03] I'm sure that I've missed some skill sets in these sort of outer circles, but the point here is this. We think a lot of times when people talk to you about their process, they say well, we start with a research, and we do planning, and we do design, and then we do development.

[00:04:20] And the problem with that is they've taken planning, and they've kinda just put it up here at the beginning. And then you're making all kinds of decisions, the rest of the whole process. Months of decisions are being made based on this one little planning session that you had.

[00:04:34] You know, or maybe a couple days worth of planning. I think that's a bad idea, especially in a case where we're building lots of different, essentially lots of different designs from the same document. So what we try to do is we try to think about our process in terms of deliverables.

[00:04:49] And we try to make sure that planning is included in all of them, okay? And planning is something that should be happening at every stage that you're, that you're, that you're progressing through. It should cover all disciplines. I'm sure that I've missed a few disciplines here, but you get the idea.

[00:05:07] So here is a rundown of the kinds of deliverables that we at Sparkbox, that we actually have in our process. We do research deliverables, okay? We're talking about brand analysis, competitive analysis, requirements gathering, stakeholder interviews, all these kinds of things. We do that stuff. We do a good investigation of their current site.

[00:05:27] You know, what's working, what's not working. We do content, we have content deliverables. We talk about content inventory, gap analysis, we do writing, those kinds of things. We do priority deliverables. So, we have things like information architectures, wire frames, experience design, experience mapping, those kinds of things. We have, and when I talk about priority here, I'm not talking about just priority of content, also priority of function.

[00:05:56] We have style deliverables obviously, we do layout, topography, color, texture, all those kinds of things. And then functional deliverables, templates, content manager system, database integration, customizations to those things, okay? And today I wanna focus on two of these, priority deliverables and style deliverables. Cuz I think that we've kind of been handling all of this up to this point in the functional deliverable section.

[00:06:22] So I wanna start to move some of the thinking a little bit further back in our process. Okay, I'm gonna assume that you guys are doing some sort of research, some sort of contents work, okay? In fact, we spend probably a significant portion of our time on those first two things.

[00:06:41] Cuz we just really think that it's gonna create a better product in the end. So please don't hear me as saying that we don't really those things aren't important. I just wanted to cover a couple specifics today, and save some time for some more technical stuff a little later on.