Uses of Wireframes (was: Contract Rates going at $150 - $250/hr ??)

6 Jul 2007 - 8:57am
7 years ago
4 replies
562 reads
Dan Saffer
2003

On Jul 6, 2007, at 6:20 AM, Phillip Hunter wrote:

> Wire frames are a tool for some interaction design, right? I
> haven't found
> them all that useful for speech interaction design nor would I
> imagine that
> device designers use them much. Same with Ajax.

I use them for devices and Ajax apps all the time. Anything with
visual controls and inputs can be wireframed.

I agree they aren't a tool for voice-input though. Annotated flow
diagrams seem to be the best option there.

Dan

Comments

6 Jul 2007 - 10:16am
.pauric
2006

One thought on annotation. In my view, device design will involve
real proper old skool hardware engineers. They like things spelled
out black and white as hardware is somewhat more costly to change
after layout. I would avoid the 'touchy feely' annotations on the
wireframe itself and opt for more of a spec. In short, avoid any
room for interpretation.
e.g. http://tinyurl.com/2bvp7u

cheers - p

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://beta.ixda.org/discuss?post=18002

6 Jul 2007 - 10:55am
.pauric
2006

I see, well with device design there is a different audience, but that
does not mean a diminished role for wireframes. While hardware
engineers need things detailed I've found they also appreciate the
end-user visualisation side of things.

In addition, and this is so critical, having a wireframe at the table
goes a -long- way to avoiding engineer led feature creep.

In a specific example I got in to a debate about displaying error
states. The engineer quite comfortably wanted to flash an LED at one
state for error A, and faster for error B. Then in the UI he wanted
to display the type of error in the mimic component. My take was, if
there's an error... there's a problem, the device will be taken
offline - plain and simple no matter what type of error it is. I was
able to juxtapose his view of the internals with what the user would
see via the wireframes and avoided making a hard call against him.

Point being, wireframes can be a new format for some engineers.
Doesnt mean you can leverage them in powerful ways. They can be used
to tell a story not readily available from a traditional tabled spec.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://beta.ixda.org/discuss?post=18002

7 Jul 2007 - 12:37pm
Dan Saffer
2003

On Jul 6, 2007, at 8:16 AM, Pauric wrote:

> I would avoid the 'touchy feely' annotations on the
> wireframe itself and opt for more of a spec. In short, avoid any
> room for interpretation.

If you are doing "touchy feely" annotations anywhere, you are doing
them wrong. :)

I wrote a piece several years ago on this:

<http://www.boxesandarrows.com/view/writing_smart_annotations>

Dan

7 Jul 2007 - 3:39pm
.pauric
2006

Sorry, again with the not articulating myself clearly.

Touchy feely: Notes on diagrams being perceived as informal design
directives by traditional hardware engineers. Those types of
engineers being more used to the formal tabular spec's that Phillip
was referring to (I assume).

Thanks for the link to your article, with the fact that its somewhat
GUI specific and this thread has focused on device interfaces I would
say the reference to 'developers' you talk about have different
needs compared with device developers (hardware engineers).

For me, the difference between the previously linked hardware
annotation: http://tinyurl.com/2bvp7u

And something I'd feel comfortable handing over to a gui developer
http://tinyurl.com/yqhvuy
I'd never do the latter for a front panel revision. Too much room
for interpretation and you'll be asked to clarify your design.

Simply, its all about understanding your audience's needs.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://beta.ixda.org/discuss?post=18002

Syndicate content Get the feed