This question seems to come up a lot lately.
A related issue often comes up a lot as well—how do we know if a simulation is “simple” or requires more functionality at the outset of a given project? My initial answer is that we don’t. I can think of many examples where we think a given visualization project is going to be simple, and it ends up requiring multiple datasheets, tons of conditional logic on what appears on the screen, and the combination of high graphical fidelity and high functionality. Conversely, I’ve worked on projects where I think it’s going to be some really involved simulation with Web 2.0 multiple Web 2.0-type elements, and it turns out to be pretty straightforward wireframes with links.
This?
Or this?
At id8, we’ve had lots of conversations about different prototyping tools for different types of projects, and which tools have capabilities for different types of simulation. It seems all very well and good to say, well use an easier tool if it’s simple, and a more robust tool if it’s complex. But what happens when it suddenly turns more complicated because the client realizes the power of rapid prototyping and wants to use the prototype for early usability testing, or training? Do we then spend the time to migrate to a new tool and try to explain to a client that now they need to buy a different tool, with additional licensing costs, and that we have to rebuild now in this other tool (and cost the project unforeseen expense)?
At first I thought my answer was simple—use the tool that has the greatest capacity in terms of functionality, and that way you’re covered. But then I realized that that was too pat an answer. I think that just maybe I spent too much time thinking about which software tool was most important, when really I think the answer lies in our ability to facilitate that answer.
Too often, I come in on a project and am asked to simulate this or that wireframe. Visualization is brought in as a step in the process. And at that point, it’s difficult to know what the simulation is going to be, or how complex it needs to be. Flat wireframes, even when seemingly rich and complete, tend to leave out more than they know. So one spends much time trying to figure out what the gaps are, because we aren’t involved from the beginning.
And overly simple as it sounds, I’m coming to believe that’s the answer—always make your visualization team a part of the process from the beginning. At id8, we’re not “prototypers,” we’re application definition specialists. And as I reflect back, our most successful projects are those where were just that—involved in defining the application as early as possible—when we’re all sitting together saying “We need an application that has the ability to. . . .” We need to work with our clients to understand throughout the project what’s too much or too little in terms of prototyping—and work with their experience and knowledge in order to visualize just the right amount. If we know more from the beginning, we can make much more educated decisions about which software tool to use most effectively.
So I guess the most important tool is Us.
