Current Methodologies vs. Technology (Was: Sketching vs. Prototyping: Bill Buxton)

26 Jan 2007 - 4:53pm
7 years ago
7 replies
997 reads
Josh
2006

> Jared said:
> In his world, a sketch should communicate how "done" the thinking is.
> Rough sketches communicate early thoughts. (referring to Bill Buxton)
>

I definitely understand that, but what if you can actually build multiple
working prototypes in the same amount of time it takes to make the sketches?

Time for a rant:

There seems to be an underlying sense that everyone's goal is to build 1
perfect solution, but with the Web we can build multiple solutions and run
them all at the same time. Consider leveraging the strategies already used
by online ad campaigns (rotating and automatically optimized content,
different creative based on demographics, etc.) in actual Web applications.
I don't know of any current methodologies factor in this technical
capability.

It amazes me how many companies, ad agencies, and consulting firms believe
that they can build an online solution and walk away from it expecting
long-term success. They preach and use UCD principles while concepting, but
aren't around to see how real people use production applications once
they've gotten their money. Oh yeah, and they don't teach their clients how
to do it either.

Also consider that with the Web, a properly built and managed site is NEVER
"done". As soon as you stop making changes, you're dead in the water.

Concepts and feature lists are never hard to make up. The hard part is the
execution.

- Josh Viney

Comments

26 Jan 2007 - 5:57pm
Brett Williams
2006

I completely agree with your rant Josh . . . well written.

Web Applications are never done, especially if they were designed
with UCD principles in mind . . . the market is always changing . . .
the users are always changing . . . and your application should
always adapt and change accordingly.

bw

On Jan 26, 2007, at 4:53 PM, Josh Viney wrote:

>> Jared said:
>> In his world, a sketch should communicate how "done" the thinking is.
>> Rough sketches communicate early thoughts. (referring to Bill Buxton)
>>
>
>
> I definitely understand that, but what if you can actually build
> multiple
> working prototypes in the same amount of time it takes to make the
> sketches?
>
> Time for a rant:
>
> There seems to be an underlying sense that everyone's goal is to
> build 1
> perfect solution, but with the Web we can build multiple solutions
> and run
> them all at the same time. Consider leveraging the strategies
> already used
> by online ad campaigns (rotating and automatically optimized content,
> different creative based on demographics, etc.) in actual Web
> applications.
> I don't know of any current methodologies factor in this technical
> capability.
>
> It amazes me how many companies, ad agencies, and consulting firms
> believe
> that they can build an online solution and walk away from it expecting
> long-term success. They preach and use UCD principles while
> concepting, but
> aren't around to see how real people use production applications once
> they've gotten their money. Oh yeah, and they don't teach their
> clients how
> to do it either.
>
> Also consider that with the Web, a properly built and managed site
> is NEVER
> "done". As soon as you stop making changes, you're dead in the water.
>
> Concepts and feature lists are never hard to make up. The hard part
> is the
> execution.
>
> - Josh Viney
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> List Guidelines ............ http://listguide.ixda.org/
> List Help .................. http://listhelp.ixda.org/
> (Un)Subscription Options ... http://subscription-options.ixda.org/
> Announcements List ......... http://subscribe-announce.ixda.org/
> Questions .................. lists at ixda.org
> Home ....................... http://ixda.org/
> Resource Library ........... http://resources.ixda.org

29 Jan 2007 - 10:06am
Josh Seiden
2003

>what if you can actually build multiple working
>prototypes in the same amount of time it takes
>to make the sketches?

But you can't. That's why paper and pencil is so cool.

But let's say you could--then you'd be sketching in software, which
would be pretty cool too.

JS

29 Jan 2007 - 11:38am
Josh
2006

Josh,

I guess what I'm trying to say is that it might not be necessary to
segregate the "concepting" phase from the actual development phase. With the
Web we can concept while building, so that when a decision is made the
assets have already been built. Working as many phases concurrently as
possible can save a ton of time.

- Josh Viney

On 1/29/07, Josh Seiden <joshseiden at gmail.com> wrote:
>
> >what if you can actually build multiple working
> >prototypes in the same amount of time it takes
> >to make the sketches?
>
> But you can't. That's why paper and pencil is so cool.
>
> But let's say you could--then you'd be sketching in software, which
> would be pretty cool too.
>
> JS
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> List Guidelines ............ http://listguide.ixda.org/
> List Help .................. http://listhelp.ixda.org/
> (Un)Subscription Options ... http://subscription-options.ixda.org/
> Announcements List ......... http://subscribe-announce.ixda.org/
> Questions .................. lists at ixda.org
> Home ....................... http://ixda.org/
> Resource Library ........... http://resources.ixda.org
>

29 Jan 2007 - 12:09pm
Jared M. Spool
2003

On Jan 29, 2007, at 11:38 AM, Josh Viney wrote:

> I guess what I'm trying to say is that it might not be necessary to
> segregate the "concepting" phase from the actual development phase.
> With the
> Web we can concept while building, so that when a decision is made the
> assets have already been built. Working as many phases concurrently as
> possible can save a ton of time.

But the phases have very different goals. In the concept phase (or
"ideation"), you're exploring many different alternatives, try to see
where each alternative can take you.

In the development phase, you're trying to refine a single idea, not
letting alternatives distract you.

Building out assets while in ideation could waste time, as only one
of many ideas will come to fruition, and you can't tell which one.
That implies all the assets for the non-followed paths will be wasted
effort.

As I learned years ago as a software developer: "Never spend time
optimizing non-working code."

Jared

Jared M. Spool
User Interface Engineering
510 Turnpike St., Suite 102, North Andover, MA 01845
e: jspool at uie.com p: +1 978 327 5561
http://uie.com Blog: http://uie.com/brainsparks

29 Jan 2007 - 12:38pm
Josh
2006

Jared,

Premature optimization is definitely not something I'm interested in.

Like I mentioned in an earlier response, there is an underlying assumption
floating around that development is necessarily more expensive than
designing. From my experience, this is becoming less and less the case,
especially with the new generation of web frameworks like Rails. As the
tools get better we should be changing our methodologies to reflect them.
It's the only way we'll see the increased efficiencies that technology can
give us. The alternative is using machine gun technology with Revolutionary
War tactics.

In another thread they're discussing which tools we should be using to
document/describe interactions. My initial gut instinct was to say, "just
build the application". If teams are talking about using tools like Flash to
concept, how much different is it to build it using the actual final
technology?

We're not building bridges or hospitals; real estate isn't scarce. We can
write lots of code and do it quickly. It's not just the designers that need
to sketch concepts, the developers have to do the same thing. Why not work
together early in the process and use the same tools?

I'm not suggesting that we employ entire teams to build these early versions
of applications. Start with small teams, maybe only 2 or 3 people then ramp
up the resources as the product gets finalized.

- Josh Viney

29 Jan 2007 - 1:05pm
Josh Seiden
2003

My point is not about expense. My point is that these are two different
types of mental activity. Changing the tools you use or the schedules in
which you deploy the activities them doesn't change the fact they are
different from one another. Whether they take place in alternating bursts of
activity that last 5 minutes each, or in highly formal phases lasting
months, concept creation and construction require different mental
strategies.

So, while it it possible to blend the strategies in clever ways, I think it
diminishes the quality of our work when we don't credit the different
imperatives of each activity. You get neither the best creative thinking nor
the best constrcution thinking when you force them to happen at the same
instant.

JS

On 1/29/07, Josh Viney <jviney at gmail.com> wrote:
>
> Jared,
>
> Premature optimization is definitely not something I'm interested in.
>
> Like I mentioned in an earlier response, there is an underlying assumption
> floating around that development is necessarily more expensive than
> designing. From my experience, this is becoming less and less the case,
> especially with the new generation of web frameworks like Rails. As the
> tools get better we should be changing our methodologies to reflect them.
> It's the only way we'll see the increased efficiencies that technology can
> give us. The alternative is using machine gun technology with
> Revolutionary
> War tactics.
>
>

29 Jan 2007 - 2:43pm
Jared M. Spool
2003

On Jan 29, 2007, at 12:38 PM, Josh Viney wrote:

> Like I mentioned in an earlier response, there is an underlying
> assumption
> floating around that development is necessarily more expensive than
> designing. From my experience, this is becoming less and less the
> case,
> especially with the new generation of web frameworks like Rails. As
> the
> tools get better we should be changing our methodologies to reflect
> them.
> It's the only way we'll see the increased efficiencies that
> technology can
> give us. The alternative is using machine gun technology with
> Revolutionary
> War tactics.

You're talking tools. I'm talking mindsets.

The other "JS" addressed this really well. I stand by what he said.

>
> We're not building bridges or hospitals; real estate isn't scarce.
> We can
> write lots of code and do it quickly. It's not just the designers
> that need
> to sketch concepts, the developers have to do the same thing. Why
> not work
> together early in the process and use the same tools?

If you play with tools that encourage/force you to think about
details beyond where you should, you waste time and focus on the
wrong things. Making edges line up, specifying fonts, choosing
colors, creating validation code, and other activities are a waste
and distraction at the ideation stage. It makes sense to use tools
that don't put these restrictions/distractions in the way of the
creator at that stage. This is where the notion of "rough" comes from.

At the later design/development stage, these activities are necessary
for communicating the fine level detail -- rough won't cut it here.
Now you want tools that force thinking at this level of refinement.

Watch an episode of Project Runway (Best. Reality. Show. Ever.) and
you'll see how sketching is very different from the later stages of
designing the outfit. It's the same with interaction design, in my
belief.

Jared

p.s. Can't wait for Season 4.
p.p.s. Next time you see me, ask me to do my Tim Gunn imitation.

Syndicate content Get the feed