This month’s newsletter is all about website prototyping from a designer’s angle. In anticipation of that, I sat down last week for a few minutes with Newfangled’s founder, Eric Holter, to chat about how he discovered the value of the kind of prototyping we do today and how that led him to write his book, Client vs. Developer Wars.
Here’s the full 15-minute audio recording of our conversation that I captured using my iPhone (i.e. not amazing quality but good enough):
But also, here’s a transcript of the first half or so of our conversation (listen to the audio to get the entire thing):
Chris: Why (and when) did you write Client vs. Developer Wars?
Eric: It was early 2001. The year 2000 was a big shift for us. We had two big projects that we built our technology around—Highland Capital Partners and Providence Business News.
Chris: Wow, so one of those (HCP) is still a client. That’s impressive!
Eric: One of them is still a client. I know, it’s pretty amazing. Those were both projects where they needed a CMS. Mike Boulet [Ed: a former employee] suggested, “why don’t we build one system for both projects and then we’ll have something we can keep on using.” So he prevailed upon me to do that. As we were getting started on those projects, it was also the same time that Nick DeLuca [Ed: another former employee] had shown me how much time we actually spent on projects and it was, like, three times more than we budgeted on average! So, I was just looking ahead on these new projects and realizing that if we did things like we normally did, we would be dead. These were three or four times bigger than any other projects we had done, so the possibility of us losing our shirts on these was significant. I just wasn’t really willing to continue on that same process and I was trying to think of what we could do different.
I thought, what would happen if I had one of our developers take the printed wireframes, which we were doing like everyone else at the time, and convert them into HTML? The same exact information, just with HTML. So Bob Clinton [Ed: a former employee] actually did that. He used Dreamweaver, and in a couple of days reproduced the wireframe in the browser. These were approved wireframes. In other words, we could have started programming, and that was the intention. We sent the HTML back to the client and they came back with all sorts of questions and changes, and we also found things, too, as we did it, that we realized weren’t going to work the way we had spec’ed them. That was when it happened—it was 2000. We finished those projects in November, and the fact that they went live, and the clients were happy, with minor changes at the end, was just epic!
Chris: When you showed HCP the prototype as it was at the time, were their questions more indicative of confusion, like, “what exactly am I looking at? Is this the website, is it not the website?” or did they get right away what the prototype was?
Eric: They did because we’d already gone through the wireframes with them so they were in that mode. We were able to say, “This is the exact same thing you just reviewed, we’re just showing it to you in a browser. Humor us. Do what you did with the wireframes.” There was a connection there. For those two particular clients there was not confusion because we weren’t leading with prototyping. It was sort of an extra, experimental thing.
Chris: So then, after you saw what insight that brought to the process and efficiencies gained and all those things, the next time around when you ordinarily would have taken a wireframe approach, did you literally just discard that and start with a prototype? And if so, were people resistant to that?
Eric: Not quite yet. At this point it was just an add-on to our process and our intent was that we’d only do this in cases where there was a high technology demand. After we finished those projects, we had a few more that weren’t as complex but we thought, “It only took an extra day. Why not just do this for this simple project as well?” And so we did, and…same thing! They wouldn’t have been quite as painful to have missed details, but it was great to catch those things before the project went live.
So, in early 2001, we began doing this as part of all of our sites and we began seeing the consistency, every single time. We were still doing both—they would approve the wireframe and then the greyscreen would reveal all sorts of things that just weren’t captured in the paper version. That’s where I began realizing, we need to lead with this. Forget the paper all together. Let’s just start, day one, in greyscreen mode. So we began doing that in early 2001.
The other thing that was happening at the same time, which was important, was we were doing this huge intranet for an architectural firm in Boston. The complication there was that there were so many parties involved that had different needs and points of view on what the site should be that to build anything and have it be coded successfully would have been extremely difficult. So we actually had a huge consulting project preceding the development, where we went up there and had sessions with all the different departments and got all the information and then went back and turned it into a prototype. That showed that the prototype was effective for not just communicating the content but also drawing multiple people together around the same thing and getting multiple points of view represented. It reinforced the value and we got to see how it contributed to the full process and complex situations, both technically and with groups. All that went in to informing the process—yes, this is valuable, yes it’s helpful, better than paper, etc.
But where prototyping really got refined was after 9/11. We went from being very busy and doing very well to having nothing to do. Absolutely bare bones. So the change for us—business-wise at that point—was if we had any projects, they were very low budget—about a third of what we were normally charging prior to that. If we didn’t milk every dollar out of those projects for efficiency and profitability, we would have been sunk. Prototyping, at that point, became essential. Circumstantially, it forced us to look at our process at every single area and say, “what can we do in this prototyping that will make us efficient all the way through?” It just pushed it to another level.
I think this is also where we built our own tool for prototyping. We had the time to do that kind of work. That took it to another level, too. It took three days to prototype before, but now you could do it in a few hours. That was huge! So I think that was the point, in late 2001, that I started writing the book. I’d seen over the last year how radically it changed our business. I guess it was probably 2002 that it was actually published originally…