Dreamweaver Wireframing Extension

Hi David

It's very interesting to hear about your 2 work stream approach - you might be onto something there.

Logic and experience dictate that the most sensible way to do things (involving all members of the project team at each stage) would be roughly as follows:

1. Business strategy
2. Site proposition (based on various things - the business strategy, brand and, most importantly, customer needs)
3. Define the information architecture + high level thoughts on content and functionality - this should involve testing with real users (e.g. card sorting usability techniques to understand where users would expect to find particular content)
4. Define the content and functionality in more detail - what will be on the site to support the customer needs? How will it work?
5. Start to create the actual content (because it always takes longer than people think)
6. Using the storyboard / wireframing techniques mentioned in this thread develop paper prototypes that can again be tested with users to thrash out any issues

And then, only then, should graphical design begin - the optimal graphical rendering of the content and functional components within an information architecture and interface design that best serves the brand, the business objectives and the customer.

And yet the reality is that people love pictures. Too much emphasis is placed on the "look and feel" too early in the project. Although this is important it is actually an awful lot easier than the steps that go before it, especially if those steps have been done properly. Pitches are too often won or lost based on the wrong kind of 'creative'. Projects are often jeopardised by resources being diverted too early into delivering 'designed' pages.

People feel understandably more comfortable once they start seeing designs. I have found that the site map is the initial big point of client interest ("There is my site!") and the page designs the next big point of interest ("There it is on the page, it must be almost done!"). A designed page shows more apparent progress than an information architecture or content specification. But you are heading down a very dangerous path if you design a page for the 'razzmatazz' and the client gets excited about it and it is passed on internally - before you know it that is "the design" when you might know full well it is unimplementable.

I think a parallel work stream to address this need for design look and feels is a good idea. But expectations would have to be very carefully managed. It should be seen more as a series of experiments, "mood boards" or to show the creative mental journeys that are possible - flexing the creative muscles to generate ideas that can then be tested with users and discussed in the project team. At some point, however, the work streams must come together and that integration process must be very carefully managed.

As David points out, we are pulling out some vintage jargon in this thread:

- 'timeboxing'
- 'iteration'
- 'wireframing'
- 'HCI' etc...

I'd love to take a clipboard out onto the streets and conduct a random polling of passers-by to see what they understand by these various terms!

On a more practical note, Ashley's point about effectively 'overlaying' graphical design onto the core information architecture and interface design is bang on in my view. That's not to denigrate the value of the graphic designer in the whole process: his/her role is just as crucial as any other member of the team.

One could use the analogy of a body to demonstrate the point. The core elements are the skeleton and flesh that sits upon it. That body can then be 'clothed' in any number of ways - each of which gives out a different impression. So the graphical design is the site's 'clothing', placed on top of the skeleton/flesh that is the info architecture, interface design and content.

Which brings us to the following question: would we rather have a Claudia Schiffer dressed in M&S or a Nora Batty dressed in Armani? Point made.

Sam

On 18:18:12 1 May 2001 dcjarvis wrote:
>Ashley,
>
>I think you and I are on a similar wavelength - perhaps
>bearing the scars of previous engagements!
>
>The issue, as you rightly say is to do with *when* and
>*how* you integrate. So this isn't a usability problem at
>all. It relates to project/account management or
>development process. The only way to do it is to iterate
>the design over a number of progressively more detailed or
>more polished prototypes. Then, if you are running the
>creative side in parrallel, you can "overlay"
>the signed off creative design/branding onto a functional
>prototype of some kind. With this done, you can do
>usability testing and iterate away until happy.
>
>The key point is that "an iteration" need only
>take a few days, 5 at the most - so clients need not be
>worried it will take forever to come up with the solution.
>(This is called "timeboxing" - for those who are
>into jargon!)
>
>I am sure you are already aware of this, but for the
>benefit of others in the forum I'd recommend checking out
>some software engineering methodologies and processes that
>are becoming increasingly common amongst interactive
>agencies:
>
>Dynamic Systems Development
>http://www.dsdm.com
>
>Rapid Application Development
>http://csweb.cs.bgsu.edu/maner/domains/RAD.htm
>
>These focus more of the technical side, but for a more
>user-centred perspective:
>http://www.usability.serco.com/trump/index.htm
>[this is essentially the same as the above, but includes
>more details on usability processes]
>
>Cheers, d