Topic: Prototyping

Digging a Hole and Covering it with Leaves — The Software Development Version

Whenever I hear the plan uttered (and in my Wall Street consulting days, I heard this a lot), that we should build an HTML (or Flash) prototype, impress the client and then fill in the back end, an unwanted image comes to mind. We're digging a hole (the missing 80% of the back end) and covering it with leaves (the HTML prototype) in the hopes that the client will fall in (impressing the client).

No, this isn't a rant about HTML, Flash or paper prototypes. Those have their place, to be sure. We use them every day in our own software development practice, but they have a short lifespan -- usually less than an iteration on the way to delivering the actual feature that it is prototyping. But when the prototype takes on a life of it's own and becomes a long-term deliverable, that's when you run into problems. What are these problems? They aren't as numerous as fall leaves, but there are plenty.

Continue reading »

What is UxD?

A couple of weeks ago a sales presentation was being prepared in our New York office; it was primarily focussed on the problem at hand, but the presenter wanted to include a single slide as a cue to talk about  User Experience Design [UxD]. He emailed me and a couple of the principles asking for a description in a single frame.

I wrote something, designed two slides because I could not shoehorn it into one, various documents were thrown into the air, then we were all consumed by other work as the train moved on.

Now I am rethinking it. UxD is a fairly complex set of activities to describe, and there is no shortage of areas claimed by related disciplines. All of them are occurring in an area of rapid market development that happens to be highly valued by the societies we are in. Which is a recipe to attract passionate debate driven by financial rewards.

So is there a good way to describe it, or state it's value to a potential client in a single powerpoint slide? Assuming that no fly-ins, starbursts or windowshade rolls may be used in place of meaning, we will start with those old standbys - words:
________________________________________

Concise version:
User Experience Designers create structures for understanding and manipulating information, designing consistent contexts which encourage cumulative learning. In doing so they raise the bar from "being able to do something" to "being able to do something easily".

Their solutions go beyond code to model the most efficient and pleasing conceptual space that can be created within the constraints of time, budget & resources.
________________________________________

Verbose version:
User Experience Designers are typically employed on applications or sites with large amounts of features, complexity or information.

They create structures for understanding and manipulating information or parameters, designing consistent contexts which encourage cumulative learning.

They raise the bar from "being able to do something" to "being able to do something easily". As a starting point they conduct research to find:
_Who are the users?
_What are their goals?
_In what context will they use the product?

Then they use any modeling technique available to propose solutions that go beyond code to model the most most efficient and pleasing conceptual space that can be created within the constraints of time, budget & resources.
________________________________________

And this is just a starting point for discussion, and the slide itself is TBD. The concise version is hardly meant to be all encompassing, but it focuses on Pathfinders particular business goals. These are concentrated in application work, either in or out of a browser, and our communications tend to be directed toward fairly tech savvy folks. Interested in your comments.

Charles

When your best is too much

Opinions can be strong and diverse in the Information Architecture arena--for example, just try and find consensus on the ideal wireframing tool. Granted, this is an easy target because everything currently available is decidedly non-ideal in all situations. Other issues seem to attract less debate and may, in time, provide one or more proven strategies we formalize as “best practices.”

I've recently run across several articles on prototyping that convey a notably consistent viewpoint. The authors’ common thread—that we are too-often prone to invest time, effort and budget producing an over sophisticated prototype—is certainly self-evident, but this impulse nevertheless presents a real temptation for designers. We want to dazzle clients with our artifacts or simply exercise our creativity by “filling in” design elements to enable us to visualize the finished product before all the design work has been thought out.

Kathy Sierra, in her blog, Creating Passionate Users, advises Don’t make the demo look done, noting that the level of fidelity of a work-in-progress sets expectations that can ultimately backfire on the designer. Her bottom line: How “done” something looks should match how “done” something is.

Sierra’s second point goes beyond perceptions and addresses the actual point of demo-ing a prototype to team members and stakeholders: The more “done” something appears, the more narrow and incremental the feedback. A concept executed to a level of fidelity that makes it look almost completely done will elicit detailed tweaks to specific features, while a rough sketch (even if produced with an application) allows reviewers to question higher-level features and consider bigger changes. She argues that even more revolutionary, big-picture changes are enabled by eschewing screen representations entirely and instead presenting storyboards or use cases. Her advice? “If you want big picture, make it fuzzy!

Henrik Olsen has two worthwhile articles on prototyping available on his website. The first, Balancing fidelity in prototyping, acknowledges the hesitancy of designers to show clients something that appears unfinished, but immediately notes that the “fact is that prototypes by definition are unfinished.” Excess visual detail in prototypes subverts the effectiveness of the iterative design process and usurps the role of the graphic designer.

Olsen’s most interesting concept regards the potential breadth and depth of the prototype. He defines breadth as “the scope of features covered by the prototype,” while depth is “how deep the prototype goes into each feature.” He advises that a successful prototype will not compromise on breadth, but should limit the amount of depth.

In Olsen’s more recent article, intriguingly titled The dark side of prototyping: How to steer clear of the pitfalls in prototyping, the author is quick to reassure readers that there aren’t really any downsides to prototyping, but there are some banana skins to steer clear of. He identifies these perils as (1) Not aligning the design with project constraints; (2) Going high-fidelity early in the design process and (3) Not involving colleagues.

Topics:

Great Article on Prototyping Complex Interactions

If you haven't already read it, you really should. Andres Zapata has published an excellent article over at boxesandarrows entitled The Guided Wireframe Narrative for Rich Internet Applications. A brief taste:

The key to using a low-context medium (wireframes) to illustrate
high-context information (rich internet applications) is to narrate the
information in layers or in dimensions. In short, because we couldn’t
build a prototype (due to time and budget constraints), we built a
story. But because it wasn’t a linear application, multiple stories
needed to be constructed. We call these stories the Guided Wireframe Narrative.

Our story or narrative focused on four main dimensions:

  • Hierarchy
  • Screen real estate
  • Design conventions
  • Interaction patterns

We call these multiple stories microflows.  Lots of food for thought here. Go and read it now.

 

Rapid PowerPoint Prototypes for Ajax and Rich Interactions

As applications take the web from static pages to dynamic screens, how can the designer effectively mock up and vet early-stage dynamic screen designs? PowerPoint provides one possible vehicle.

We have found PowerPoint to be effective because it has very easy to use animation, screen transition and click-through capabilities. While the prototypes we produced were not highly polished, they were highly effective in vetting the ideas for a new website IA with three key groups: stakeholders, developers and graphic designers.

One specific effect that was used was the screen transition called “Wipe”. The Wipe effect (available in up, down, left and right versions) enables easy simulation of things like sliding drawers. You simply make a slide with the closed state of the drawer followed by a slide with the open state of the drawer and apply the Wipe transition.

Though the technique is simple, it is quite effective at communicating the screen ideas to users and developers.

Visualizing Rich Interactions in Paper Prototypes

Wireframes and paper prototypes work well in documenting the standard page metaphor of the Web, as the functionality of each screen can be captured in a single wireframe. Rich interactions, though, pose the challenge of expressing a series of states that may occur on a single screen.

As technologies like AJAX gain greater popularity, designers face the challenge of exploring and developing new and innovative visual vocabularies and flexible tools for capturing the microflows of rich interactivity.

At Pathfinder, we are drawing inspiration from the discipline of storyboarding, which is, of course, closely related to wireframing. Storyboards express ideas in a sequence of "key frames," showing only the minimum number of frames to convey the idea. The richness of storyboards comes not from just the individual pictures, but from the change from picture to picture. It's possible, then, to embed a miniature storyboard into a wireframe, thus illustrating the quality of the rich interaction.

A second technique is to create a visual taskflow representation to the system. In this format, all screens are miniaturized to capture both the linear and non-linear flows within individual screens and from screen to screen.

Our fellow practitioners are tackling this challenge as well. Bill Scott considers several strategies for creating interactive wireframes, including the PowerPoint clickthroughs, the development of quick and easy RIA toolkits, and standardized notations to indicate interaction effects in traditional, static wireframes. His personal technique involves the creation of storyboards in Visio, which he then animates. The strategy is detailed in his blog entry, "Interactive Wireframes: Documenting RIAs."

Launch: Pathfinder Newsletter

    Get a monthly update on best practices for delivering successful software.

    Subscribe via email


    Subscribe via RSS      RSS icon

Topics

Search

WordPress

Comments about this site: info@pathf.com