Rapid prototyping process brings technology to life

Chris Harrison, a computer scientist and the director of the Future Interfaces Group at Carnegie Mellon University, is working at the cutting edge of UI. Innovative projects that he and his team have developed include OmniTouch and Skinput, which can turn a random table and even human skin into input surfaces.

For Harrison, a rapid prototyping process of building cheap mock-ups of the technology that users can play with and give feedback on is a critical technique in his research. In a recent interview with SearchCIO, Harrison described why he and his team rely on rapid prototyping to innovate and iterate quickly, and he explained why he sees the technique not as a set of skills, but as a work ethos.

Editor's note: This Q&A has been edited for clarity.

You gave a presentation a few years ago, and you said that a rapid prototyping process is key to your research. Is that still true today?

Chris Harrison: Yes. I think rapid prototyping and research are almost the same term, at least in my field. … Because, in our field where humans have to touch and interact and experience the technology, the feel of a device, the feel of an experience is so important.

Chris Harrison

It would be like going to people back in 2006 and showing them an iPhone-like interface, but on a laptop. That wasn't what made something like the iPhone a really special device. Sometimes you just have to go out and build it -- build that futuristic mobile device, build that car dashboard of the future and get people to sit in it. And that's very expensive to do if you do that from scratch every single time. So, that gives you the idea that you have to prototype if you really want to deeply understand how a technology comes into play and how people use it.

But, of course, we can't build an iPhone-like device every year. That was a multiyear research project with probably hundreds of people involved. And so, really, the notion of rapid prototyping is, let's create the crudest possible experience that encapsulates the vision, put that in front of people to get their feedback and then iterate again.

So, it's a constant iteration cycle and as we do these rapid prototyping cycles, it slowly condenses to the point where you have something that is actually pretty high fidelity. But it may be that of the 10 ideas we try, when you put nine of them into people's hands, they go, 'Eh, this isn't really exciting or it's really goofy or there's nothing that really illustrates what utility this technology might have,' and we drop it. So, we just have to keep moving quickly because it's an open landscape of possibilities.

Sometimes you just have to go out and build it -- build that futuristic mobile device, build that car dashboard of the future and get people to sit in it.

How rapid is rapid?

Harrison: There are no hard-and-fast rules on this because it depends on the size of the project. Sometimes it takes a year to build something, but sometimes it only takes a week. We've actually gone from the beginning of an idea to complete execution -- so, running a user study, which we do for pretty much all of our research, to actually submitting a publication that is peer-reviewed -- probably the shortest that ever happened is about two weeks from conception of technology to actually being able to ship a product with a demo video and everything. So, that's about as rapid as it gets.

I would say, typically, we pick projects that are on the order of about a semester -- so, about three months is a typical iteration cycle. And at the end of those three months, we pause and say, 'Are we going to double down and do another cycle or are we going to step back and let the idea go?'

Besides a rapid prototyping process, are there other techniques that are critical to your work?

Harrison: Certainly to my colleagues -- they leverage a wide variety of possibilities. Some people would argue why even rapid prototype at all? You should be able to get a pretty good feeling if an idea is good or not by doing things like paper prototyping, where you might have an iPhone-like experience but you don't build anything at all other than, you know, sketching it on paper and then working through a kind of qualitative exercise where you understand how that fits into a person's life or into a technology landscape.

We tend to do that less because, as technologists, we want to get technology into people's hands and make sure that it's viable. The question is not only is the technology useful, but is it even possible? Saying we want to project interfaces onto people's bodies, well that sounds pretty cool, but how are you possibly going to do that? So, there's a big technical challenge in addition to the utility challenge.

Rapid prototyping is core to what we do and that encompasses a wide range of different skills. We're building our own electronics and hardware; we're doing industrial design on how these things look. We're doing a lot of software and firmware development. We're applying machine learning and AI and computer vision and so on to do the high-level algorithms that are going to empower those systems. And then, ultimately, we're building demo and applications that run on top of the full stack that show and demonstrate if the idea is interesting enough.

So, there's a huge variety of skills that are encapsulated under that ethos. It's not really a skill of rapid prototyping; it's an ethos of rapid prototyping where you want to explore and sort of fan your fingers out into the open research area and see what hits a chord with people.