In an earlier post, I offered some thoughts on rapid prototyping. I mentioned my preference for the “high-fidelity prototype”, which leaves very little room to the imagination and provides users and stakeholders with a realistic sense of the user experience of the product.
I’ve been using a couple of different rapid prototyping tools and thought I’d offer some opinions on their limitations and what looks promising as I see it.
I’ve been using Balsamiq and Axure a fair bit. I think they’re both pretty good tools, but the problem is prototyping and design are subsets of communication and these two tools don’t seem to get that.
You don’t come up with a design in isolation, you need to validate it with users and other stakeholders. For the most part, these tools make it easy to put UIs together, but they have issues when it comes time to send out your work for feedback. The biggest problem I see with both is managing workflows in the review process.
Because they’re desktop based, you need to make all supporting files accessible to your reviewers and provide instructions to them for getting the prototype to look and act like it’s supposed to.
In reality, by the time someone gets to the review, you’ve already made changes. Every time you send out a new iteration, you need to include lots of attachments and send everything out all over again. Getting timely feedback can get so aggravating that you reach a point where you don’t want to bother doing it at all. Major pain.
I got to thinking, “There must be a better solution, even if I have to build it myself”. Then I discovered ProtoShare.
There are several things I really like and admire about ProtoShare – both the company and the tool, including:
The shortcomings I see with ProtoShare center mostly around pricing.
So I have made my feelings regarding functional specs pretty clear already. It’s clear to me, and a lot of other folks, that prototyping can be a very powerful way to capture requirements. What I have been thinking more about lately is, “What is the best way to do that?”
While there probably is no single right answer to that question, I have been learning a lot so far. Here’s where I’m at.
The design of experiences is sometimes a mystical field of work. There are so many acronyms for similar or overlapping types of work that may affect the user experience: IXD, UXD, IX, IA, IAD, UX, UXR, VD, etc.
No matter what your title happens to be, you are likely to be spending a significant part of your day thinking about how to design experiences that make sense and make people happy.
Recently, I came across a great post over at UIE that covers the difference between designing for experiences and designing for activities…