Jon:
Welcome to episode 106 of The Digital Life. A show about our adventures in the world of design and technology. I’m your host, Jon Follett, and with me is founder, and co-host, Dirk Knemeyer.
Dirk:
Hey, Jon. Good to be here.
Jon:
I thought for our podcast today, we could chat a little bit about one of my favorite aspects of the software design process, which of course is the prototyping portion of that. I’ve noticed, nothing scientific here of course, but I’ve noticed that I’m hearing a lot more about software prototyping now. It’s almost as if it’s in vogue, in terms of being a technique that people are reasonably interested in incorporating into their user experience design process. You hear about people talking about it at conferences. There’s a million different tools it seems like to prototype now. Very different from when I started in digital design. There are now numerous ways to prototype, even if you’re not really a very skilled coder. You’ve got Axure, InVision, and iRise, and all sorts of HTML, CSS, and JavaScript frameworks. Not to mention, folks can use presentation software like Keynote or PowerPoint to do it. It really seems in the software design industry, we’ve reached some kind of general consensus that prototyping is the way to go, and we’re entering this software prototyping renaissance. At least that’s the way it looks to me.
I also remember that was not always so much the case. I wanted to talk with you about that today a little bit. Dirk, when you started down the design path, more than a decade ago, how was prototyping looked at at that point, and how has it evolved since?
Dirk:
At that point, when we started Invo in 2004, and I had been doing digital design a couple of years before that as well, but just to focus on Invo, when we started the company, design firms were not doing digital prototyping. I’m sure there’s probably a couple that I’ve never heard of, but for the most part, nobody was doing it. There still were certainly prototypes being made, but those prototypes were non-digital, whether it be things like paper prototyping, very low fidelity, or wireframes, God forbid, or screen mock-ups. Those are all prototypes as well, but the key is, they’re not digital. They’re not interactive prototypes. They might be made to be interactive in kludgy ways, but they don’t get anywhere near approximating what the real use of the software would be. One of the ways in which we really innovated at Invo, was in digital prototypes being an expected, even mandatory, part of our process. While we were explicitly a design firm, and not an engineering firm, we had a similar number of engineers on staff as designers. Now, it’s more common, but at the time was really unheard of.
That’s always been core to our process. We philosophically believe, based on a lot of years of experience, and frankly, a lot of Andre’s experience, Andre, one of the other original founders of Invo, who started the design team at Adobe and designed the Creative Suite, that to really design great software, you need to have kinetic digital prototypes that can give the designers, the product people, the engineers more robust feedback to how that software is actually going to be used, and perform. Today, that is a much more common practice. You still have design firms, and design teams without programmers, but at least for people who are claiming to design digital things, I think that’s much more the exception, than the rule, which is remarkably different from 11 years ago.
Jon:
We’ve seen that user experience has become more of a term that people recognize now. The industry has been accepted as part of the experience of putting together the right kinds of software. As the amount of software has increased, we’ve got all these mobile devices, additionally, UX has been raised up to be something more important than it was. Do you think these were contributing factors to prototyping gaining acceptance as well?
Dirk:
From my standpoint, the main reason why prototyping gained acceptance is that younger, or more progressive designers, it clicked for them, that digital prototypes are the more effective way to create things. They naturally moved into becoming programmers, or gaining engineering and programming skills themselves. As designers and creators who want to make really good stuff, it’s just obvious at a certain point, that the only way to get the most out of software, is understanding technically, what’s possible for that interface, how that interface can perform. I think, from my perspective, it was driven by the people doing the work, both the younger people, who are just making their way, and looking for the best, most effective ways, not having baked into who they are and how they see their role, which traditionally is more analogue, but then additionally, more progressive older people who, when I think about this, I always think about my buddies at Madhouse, a design studio in Toledo.
They were a traditional, very small design shop that was dealing with ad agency stuff, and as they saw their business more and more moving into first websites, and then software, they got, because they’re really exceptional creators, that the way to make those things great, required the engineering skills, and the digital skills. All of the partners of that firm, and their key employees, they all learned how to program. They just added that to their design toolbox, because as exceptional creators, they saw that it was simply correct. I think it was those sorts of individuals who were more seeking excellence, were more progressive, who perhaps had the way of thinking … Their minds, in terms of how they can learn, and what skills that they can master, maybe it was more compatible for them to add those skills. It’s not always for designers and artists. They went and did so. I think it’s that evolution of the practitioner base, driven by the practitioners themselves, that really had the big impact in shifting the whole industry.
Jon:
I think that makes sense. One of the things that I appreciate about prototyping when we do it at the studio, is all the many different reasons, the different aspects, that you can prototype for. We’ve talked a little bit about the prototype as a way of validating the design in something that’s kinetic in form, something that the user can interact with. Some of the other reasons that I’ve seen being very powerful for prototyping, especially when you’re dealing with something like interactive information visualization, is experimentation. If you have large amounts of data, and you don’t know what story that data is going to tell you, nor do you know the best way to depict that data in an information space, one very interesting way to use digital prototypes is to suck all that data in. Then, depict it in various ways on the InfoVis side, so you can go through and evaluate, which one of these experiments is working in terms of a way of discovering, which InfoVis tells the best story. I know that’s a technique that we use when we encounter large amounts of data, and really want to be able to pick the best way to depict the info’s story.
Dirk:
Mm-hmm (affirmative)
Jon:
Another really powerful reason to prototype, that I think maps well to the design validation part, is really from a risk mitigation standpoint. The further that you can validate the design, and see whether things are working or not, using real data maybe in a flat file, rather than hitting the database, what it does for both the design and engineering team is, allows us to discover if there’s functionality that is just going to be useful to the user, or if it’s going to be ultimately something that falls flat. While we’re validating the design to make sure that it’s working properly, we can also be looking to the features and functionality, and discover early on, before you get too deep into the development process, discover whether or not you have the right idea about the software in the first place. Prototyping to mitigate risk, I think, is a strong reason that is not that often talked about, but I think very important.
Dirk:
That’s a great point. A lot times clients are leary regarding the extra budget that good digital prototyping requires. Often times, when clients come to us, they’re looking for something very specific to be designed. They have a budget in mind. It’s usually lower than the design really costs in the first place, and when they see the cost to correctly do the design and prototyping, there can be a desire to try to lower that budget, and the prototyping is often the first thing that gets attacked. It’s really pennywise and tomfoolish, because most software projects fail, if you look at the totality of all the software out there that’s made. Most of them never come to fruition. They fail. There’s a lot of reasons for that, but one of them are failures in the design, and the relationship of the design to the engineering process pulling all of that together.
Investing in good prototyping, not only manifests in a better design, but it also is a risk mitigation technique to help as one way to make it more likely that your software project succeeds. It’s really money well spent. I think more and more companies are seeing that, but certainly still not all, particularly those that are less sophisticated, or less experienced around software. It’s a shame, because at the end of the day it’s about the bottom line, the overall bottom line success from the totality of that software, and prototyping is a key part in maximizing that.
Jon:
Despite the value that you can see from the validation process, or even communicating what the design should be to the engineering team as part of the results of good prototyping, there’s this desire to hold on to either that prototype or the code that forms it. I’ve seen great results from doing a variety of prototypes to properly vet the design beforehand, but if you’re leary of throwing away the prototype code, and want it to be almost a jump start into production, this is another pennywise poundfoolish moment that you can encounter in the software process where just because we’ve invested this time in the prototype to make sure things are working properly, all of a sudden, the expectation is, “Hey, it looks like software, maybe it is the beginnings of our front end.” That can have not the greatest results if the code was not really meant to do that in the first place.
Jon:
We know how prototyping has evolved over the past decade to become a more accepted practice, what do you see for the future of prototyping? I’m asking this because I think there’s some really interesting possibilities, especially for the ease of prototyping going forward. What do you see as being the next step in this evolution?
Dirk:
Prototyping is going to remain more and more important. The question is, when will artificial intelligence, when will technologies that automate engineering, displace the need for the human operator, whether it be a designer or someone who is explicitly hired as an engineer prototyper, to do that kind of work. I don’t have a good outlook for that, but I think that’s coming at some point. Jon, you said you have some ideas. I’m interested to hear those.
Jon:
Yeah. They’re much along the same lines as you mentioned. The idea that there are certain aspects of user experience design that can be, and perhaps should be, automated, and as there’s this possibility to put together pieces of the software in an automatic fashion, I think that people are going to take advantage of that. We can already see that in systems like, I believe it’s called, The Grid, which purports to allow you to create a website using artificial intelligence. This is just sort of the beginning. Obviously, a website is not going to be as complicated as creating software, but you can see around the edges that artificial intelligence is going to begin to enhance the user experience design process. Something that we definitely have to keep an eye on if you’re in this business.
Listeners, remember that while you’re listening to the show, you can follow along with the things that we’re mentioning here in real time. Just head over to thedigitalife.com, that’s just one “L” in the digital life, and go to the page for this episode. We’ve included links to pretty much everything mentioned by everybody. It’s a rich information resource to take advantage of while your listening, or afterward if you’re trying to remember something that you liked. If you want to follow us outside of the show, you can follow me on Twitter, @jonfollett, that’s j-o-n-f-o-l-l-e-t-t, and of course the whole show is brought to you by Involution Studios, which you can check out at goinvo.com. That’s g-o-i-n-v-o.com. Dirk?
Dirk:
You can follow me on Twitter @dknemeyer, that’s d-k-n-e-m-e-y-e-r. Email me at dirk@goinvo.com.
Jon:
That’s it for episode 106 of The Digital Life. For Dirk Knemeyer, I’m Jon Follett, and we’ll see you next time.
