layout comps or sketches. Can you talk a bit more about that?
Jason: The main reason is that, when you prototype in the browser, you can see what
it really looks like. It doesn’t matter what tricks you have in Photoshop, it’s never going to translate exactly into how a web page will behave. So, over the years, I’ve started to see that, if you have a good base theme, or a handle on writing HTML, you get to a place much faster where you can actually explore behavior—especially when you’re putting it right into a content management system. So you can explore more of the real life of a website quickly, rather than trying to mock up every different state of an interaction.
Dani: How do you ideate something like that—do you go straight to code, or do you start with sketches, and then move to code later?
Jason: In terms of the actual design process, there’s always work that goes on in Pho-
toshop or Illustrator. But oftentimes, that comes after a prototype’s been built. We tend to have this “sandbox” version of a website, that’s been built out with all of the main pages, and some of the default users there already. It’s really quick to play with things, and think about “How am I going to search?” and “How am I going to play with these things?” Once it’s time to go into the look and feel, you have all the real stuff there to play with. Even as you’re opening Photoshop or Illustrator, you know the real things that you have to be concerned with—the buttons, navigation elements, and the real content on a page, etc.
But even with that, there’s pages and pages of sketches, notes and things like that from early on in the process, especially for something complicated.
† For more information on the Lean Startup movement, check out http://theleanstartup.com/. 90 | Chapter 11: Prototyping in the Browser
Dani: The flow that I’ve been moving towards lately is sketch, maybe wireframe a couple of pages, but then start prototyping in Drupal quickly so I can see how things are falling, and how something’s going to be implemented. The question I always ask myself is: how much of that workflow is based on the fact that I’m a team of 1–3, as opposed to being one piece of a larger team? I notice with larger teams, they do often have more clearly defined roles, so there’s not as much concern about whether you specifically can implement something, but more about whether it can be implemented by the team. Have you had experience with that?
Jason: I’ve worked on teams of varying sizes, from just me to managing a group of 3–
5 people to being a creative director at a company in Boston with 30 developers and a team of 6 designers. I’ve never been a big fan of having a person for every possible task and isolating the work that they’re doing. It’s never seemed to work well.
Especially with a platform like Drupal at your disposal—even doing the site for CVS/ CareMark, which is a pretty significant project, it was still a team of 5–6 core people. There was a designer, there was a researcher and information architect, there was me and a couple of developers who were helping me. That was pretty much it.
Dani: That’s one of the benefits of Drupal. There’s so much that’s built for you that it’s easier to make big websites with fewer people. I don’t think it makes it any less complicated, but I do think it allows you to focus on more important parts of the experience than what the code is going to look like.
Jason: Exactly, and that’s one of my favorite things about it. It lets you be a team that
is iterative and reactive far more easily than when you have each person in their own separate role. I keep thinking of these companies that push development offshore, or to a partner company, where you have this enforced wall between design and archi- tecture. Maybe there’s some prototyping, but the real development happens some- where else. In those cases, there’s no way to just sit down with someone and discuss something, and then react to it right away.
Dani: While you’re prototyping in the browser, do you find that there are any moments where you find yourself leaning on Drupal’s defaults a bit too heavily?
Jason: That’s an easy trap to fall into. Because you know something works, so you put
your attention to something else, and it’s not necessarily that it works in the best way. I think that’s a constant challenge, and not one that’s so difficult to overcome if you work smartly. One of the things that I have enjoyed about the process of working on the platform we’ve built for SchoolYard is that there’s a common base point we’re starting with. Every project, we get to smooth off more of those rough corners. I think that when you build up this set of defaults—this set of modules that you always use, this point from which you always start the process—it lets you build up these layers of sophistication. You can start building all these little things that add up to a much more refined experience. That’s where taking the time to get to know the platform and just look for stuff and see what’s out there—every time you do another project, it just gets better and better.
Dani: How do you document that?
Jason: In part, it’s frozen in this starter kit website that I start from every time I start a
new project. Periodically I’ll go in there and update the modules, and every time I see something interesting I make sure I throw it in there.
That, and blog posts. I do a lot of that. If I figure out some weird challenge, I take notes in Evernote as I figure it out, I make sure I copy down all the steps, and I add in all the things that I have found, and I stick it up on my blog.