[Sigia-l] strategy to mocking wireframes?

[Lord, Ralph]

>In most cases we use 
>wire-frames as part of the design process, that is they are used so 
>that designers, programmers and other stake-holders can contribute to 
>shaping what we are making.

We use the wireframe thingy based on use-cases in this way as well - to
facilitate communication between the client (users and stakeholders) and the
team in the early stages of figuring out just what this animal is supposed
to be and do. Why based on use-cases?  Simply because our client tends to
think in use-cases (ok, not really, who does?) - well, I mean they tend to
understand use-cases and can readily rattle off scads of "use-case like
tasks" which we then put into wireframes so they can "see" their use-cases
and react. Reactions range thru:

"OH, that's not what I meant at all"
"Hmmmmmmm"
"Does this thing work in Java?"
"Wait a minute, we need to rethink this one"
"Ooh, is this wi-fi?"
"Hey, this looks great. Are you almost done?" and so on and so forth.

Then we wireframe some-more, come back and keep turning that crank until we
get stability to start some real engineering and coding.


Ralph Lord
System Analyst
Northrop Grumman Mission Systems
Centers for Disease Control and Prevention
404.639.7382



> -----Original Message-----
> From: tom smith [mailto:tom at othermedia.com] 
> Sent: Monday, April 14, 2003 4:06 AM
> To: sigia l
> Subject: Re: [Sigia-l] strategy to mocking wireframes?
> 
> 
> 
> On Sunday, April 13, 2003, at 08:34 AM, Eric Scheid wrote:
> 
> > What's your experience with constructing wireframe mockups? 
> How do you
> > know
> > whether it should be use-case driven or info-map driven? How do you 
> > balance
> > those competing needs for the ambiguous cases? Are the two drivers, 
> > usage
> > vs. info, more often in alignment or in competition?
> 
> One "it depends" is whether what you are building is content or a 
> tools-based system.
> 
> I nearly always mockup from a use case perspective. 
> Sometimes, parts of 
> the content are wire-framed as examples, but there is 
> normally so much 
> similar content that mocking it all up would be repetitive and 
> difficult to change if we decided we'd got it wrong.
> 
> I guess there's another "it depends" hidden here. In most 
> cases we use 
> wire-frames as part of the design process, that is they are used so 
> that designers, programmers and other stake-holders can contribute to 
> shaping what we are making. We don't normally use wire-frames as an 
> exact specification for the programmers and designers to follow.
> 
> All of this depends what your team or company is like. If you have to 
> specify every last detail, then you are wasting your time doing 
> repetitive work. If wire-frames are used purely as specs then your 
> designers and programmers probably aren't contributing enough.
> 
> tom
> 
> p.s I often create documents that are a hybrid of use-cases and site 
> map, one minute they look a little like UML, the next they look like 
> design sketches, this is because at some points the layout is very 
> important and others what happens is important and to me separating 
> issues into different documents only makes the communication of ideas 
> more fragmented.
> 
> --
> tom smith
> http://dev11.otherworks.com/theotherblog/
> yahooIM: theotherblog
> aolM: theotherblog
> 0207 089 5959
> 3rd Floor, The Pavilion, Newham's Row, London SE1 3UZ
> 
> ------------
> When replying, please *trim your post* as much as possible. 
> *Plain text, please; NO Attachments
> 
> Searchable list archive:   http://www.info-arch.org/lists/sigia-l/
> ________________________________________
> Sigia-l mailing list -- post to: Sigia-l at asis.org
> Changes to subscription: http://mail.asis.org/mailman/listinfo/sigia-l
>