Do tools matter in Big D design from an execution perspective? Formerly Expression Blend a "review"

13 Apr 2007 - 12:40pm
7 years ago
5 replies
739 reads
Chris Bernard
2007

Michael, this is great feedback and the 'do your tools matter' is important. But are we confusing having tools 'matter' with being 'important' for a given task? Eclipse and Ant aren't very important for folks that work in the world of .NET but they surely do matter and in fact probably influence how the tools in .NET work and vice versa. I suspect that regardless of if folks work in the world of .NET, or Adobe or the myriad of open source variants or jump among all three that the tools, processes and frameworks in all of these worlds influence the others (and this is a good thing).

And perhaps I'm being overly vague here too in my question as I certainly concur that tools do matter when it's time to 'carve the wood'. Do tools like Eclipse, Visual Studio or Photoshop or Flash matter than much in the early phases of the design process (around research, analysis, synthesis and conceptualization?) or what I'm calling the Big D part of design?

I think we could make a strong argument that tools like Photoshop and Flash do for many folks but is even that wise if you're using them to flesh out an app that will be built in <insert technology here>?

Perhaps the conundrum I see here is that I suspect many people (present company excluded) use prototypes the wrong way, or make them too real too soon without understanding the implications of execution (This is a somewhat lesser known contributor to the Vista development debacle BTW). This is even further compounded by the fact the some of the interactions and patterns we design for simply have to be built for people to 'get' them. It's pretty hard to show the utility and interactivity of a one page shopping cart (let alone measure or test it) without a pretty good representation of the final artifact. It gets even more dicey when were using one technology platform as a proxy for another in this process as we can get in the weeds pretty quickly or design interaction scenarios that can't be supported by the application logic of a platform or the backend (often legacy) that you're plugging into.

I'm also curious how we reconcile this with many of the current trends in Web development. For example. Let's look at an application like Basecamp from 37signals.com. What's the best way to bring that application to life? What's the best way to prototype it. In Photoshop? In Flash? Or just build it?

Chris Bernard
Microsoft
User Experience Evangelist
chris.bernard at microsoft.com<mailto:chris.bernard at microsoft.com>
312.925.4095

[cid:image001.jpg at 01C77DB9.15A1B750]<http://visitmix.com/>

Blog: www.designthinkingdigest.com<http://www.designthinkingdigest.com/>
Design: www.microsoft.com/design<http://www.microsoft.com/design>
Tools: www.microsoft.com/expression<http://www.microsoft.com/expression>

From: Michael Micheletti [mailto:michael.micheletti at gmail.com]
Sent: Friday, April 13, 2007 10:07 AM
To: Chris Bernard
Cc: Christian Sosa-Lanz; IxDA Discuss
Subject: Re: [IxDA Discuss] Expression Blend a "review"

Chris,

Designers sail past different shores of a large sea. Some skirt close to the land of the developers and sometimes walk onto the beach to trade fish and curiosities for handmade trinkets. Some of us even learn to handmake articles ourselves - to hold the tools and carve the wood. Other designers sail the deep waters of pure thought and academic discourse, never in generations to set foot on land in their search for the legendary white whale of theory. Still others sit on shore, tools in hand, dreaming of the day they'll have a boat and can sail the design sea.

So for many of us, tools do matter, whether we hold them in our own hands or trade for goods crafted with them. The key question for you, O maker of tools, is do _your_ tools matter.

I would say that if I were to design a brand new application destined for a .NET release somewhere farther than six months out, then your tools would be of very great interest to me. In fact, I've already forwarded much of this thread along to some of the development artisans I trade with. If I were to design minor revisions to an existing application, even an existing .NET application, your tools will probably not help. If I were to design an Ajax web component, your tools will probably not help. If I were to design an application in a Java shop or for a command line or for a mobile device, I'll put your tools in a drawer and ask the artisans to use something else. If I am trying to illustrate an early concept to show to a design session, something altogether other than Blend is called for.

Your tools, after they are fully sharpened, show potential for being powerful shapers of the Microsoft wood. The XAML syntax is readable. The integration with Visual Studio looks promising. I have hope of using them myself, or working with skillful craftsmen who do, in some future project. But for now I hew the wood of the Java tree with plans made in Visio and surfaces in Photoshop and code in Eclipse and Ant.

Michael Micheletti
On 4/12/07, Chris Bernard <Chris.Bernard at microsoft.com<mailto:Chris.Bernard at microsoft.com>> wrote:
What do others think? Do tools matter in Big D design from an execution perspective?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 29640 bytes
Desc: image001.jpg
Url : http://lists.interactiondesigners.com/pipermail/discuss-interactiondesigners.com/attachments/20070413/495844fa/attachment.jpg

Comments

13 Apr 2007 - 1:25pm
Matt Theakston
2007

My thinking is if you "just build it" you are going to have to be pretty
magical not to fall into some old design traps. I had this conversation with
a classmate (working also i should add) on the el home. Is there a tool out
there to prototype more complex interactions, say with what is possible with
ajax/flex etc? We thought not. Does that mean we should just scrap the
prototyping process? We thought not. I'd be interested to see what people
currently use at the protyping stage for such apps? Or is everyone just
skipping it and building them..

Matt

DePaul HCI

On 4/13/07, Chris Bernard <Chris.Bernard at microsoft.com> wrote:
>
> Michael, this is great feedback and the 'do your tools matter' is
> important. But are we confusing having tools 'matter' with being 'important'
> for a given task? Eclipse and Ant aren't very important for folks that work
> in the world of .NET but they surely do matter and in fact probably
> influence how the tools in .NET work and vice versa. I suspect that
> regardless of if folks work in the world of .NET, or Adobe or the myriad of
> open source variants or jump among all three that the tools, processes and
> frameworks in all of these worlds influence the others (and this is a good
> thing).
>
> And perhaps I'm being overly vague here too in my question as I certainly
> concur that tools do matter when it's time to 'carve the wood'. Do tools
> like Eclipse, Visual Studio or Photoshop or Flash matter than much in the
> early phases of the design process (around research, analysis, synthesis and
> conceptualization?) or what I'm calling the Big D part of design?
>
> I think we could make a strong argument that tools like Photoshop and
> Flash do for many folks but is even that wise if you're using them to flesh
> out an app that will be built in <insert technology here>?
>
> Perhaps the conundrum I see here is that I suspect many people (present
> company excluded) use prototypes the wrong way, or make them too real too
> soon without understanding the implications of execution (This is a somewhat
> lesser known contributor to the Vista development debacle BTW). This is even
> further compounded by the fact the some of the interactions and patterns we
> design for simply have to be built for people to 'get' them. It's pretty
> hard to show the utility and interactivity of a one page shopping cart (let
> alone measure or test it) without a pretty good representation of the final
> artifact. It gets even more dicey when were using one technology platform as
> a proxy for another in this process as we can get in the weeds pretty
> quickly or design interaction scenarios that can't be supported by the
> application logic of a platform or the backend (often legacy) that you're
> plugging into.
>
> I'm also curious how we reconcile this with many of the current trends in
> Web development. For example. Let's look at an application like Basecamp
> from 37signals.com. What's the best way to bring that application to life?
> What's the best way to prototype it. In Photoshop? In Flash? Or just build
> it?
>
>
> Chris Bernard
> Microsoft
> User Experience Evangelist
> chris.bernard at microsoft.com<mailto:chris.bernard at microsoft.com>
> 312.925.4095
>
> [cid:image001.jpg at 01C77DB9.15A1B750]<http://visitmix.com/>
>
> Blog: www.designthinkingdigest.com<http://www.designthinkingdigest.com/>
> Design: www.microsoft.com/design<http://www.microsoft.com/design>
> Tools: www.microsoft.com/expression<http://www.microsoft.com/expression>
>
> From: Michael Micheletti [mailto:michael.micheletti at gmail.com]
> Sent: Friday, April 13, 2007 10:07 AM
> To: Chris Bernard
> Cc: Christian Sosa-Lanz; IxDA Discuss
> Subject: Re: [IxDA Discuss] Expression Blend a "review"
>
> Chris,
>
> Designers sail past different shores of a large sea. Some skirt close to
> the land of the developers and sometimes walk onto the beach to trade fish
> and curiosities for handmade trinkets. Some of us even learn to handmake
> articles ourselves - to hold the tools and carve the wood. Other designers
> sail the deep waters of pure thought and academic discourse, never in
> generations to set foot on land in their search for the legendary white
> whale of theory. Still others sit on shore, tools in hand, dreaming of the
> day they'll have a boat and can sail the design sea.
>
> So for many of us, tools do matter, whether we hold them in our own hands
> or trade for goods crafted with them. The key question for you, O maker of
> tools, is do _your_ tools matter.
>
> I would say that if I were to design a brand new application destined for
> a .NET release somewhere farther than six months out, then your tools would
> be of very great interest to me. In fact, I've already forwarded much of
> this thread along to some of the development artisans I trade with. If I
> were to design minor revisions to an existing application, even an existing
> .NET application, your tools will probably not help. If I were to design an
> Ajax web component, your tools will probably not help. If I were to design
> an application in a Java shop or for a command line or for a mobile device,
> I'll put your tools in a drawer and ask the artisans to use something else.
> If I am trying to illustrate an early concept to show to a design session,
> something altogether other than Blend is called for.
>
> Your tools, after they are fully sharpened, show potential for being
> powerful shapers of the Microsoft wood. The XAML syntax is readable. The
> integration with Visual Studio looks promising. I have hope of using them
> myself, or working with skillful craftsmen who do, in some future project.
> But for now I hew the wood of the Java tree with plans made in Visio and
> surfaces in Photoshop and code in Eclipse and Ant.
>
> Michael Micheletti
> On 4/12/07, Chris Bernard <Chris.Bernard at microsoft.com<mailto:
> Chris.Bernard at microsoft.com>> wrote:
> What do others think? Do tools matter in Big D design from an execution
> perspective?
>
>
> ________________________________________________________________
> 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
>
>

13 Apr 2007 - 1:31pm
Josh
2006

Chris,

Interesting comment at the end Re: Basecamp. I moved from a UX/Product
Manager role at a company firmly entrenched in .Net to a company developing
in Rails. One thing I've noticed in the Rails arena is a change in the way
developers work. Beyond all of the framework debate, I've found the biggest
benefit of the Rails community to be the willingness to jump in and build
and build again. When there are discussions in IxDA about prototyping tools
like Flash, I always want to respond with "why use Flash or Photoshop as a
prototyping tools if the web application won't be built using Flash or
Photoshop?" (note admittedly it's a bit different story when talking about
desktop software). I've seen working database driven Rails web application
prototypes built in less than an hour, and I'm not sure it would be much
different with any of the newer frameworks.

I have this sneaky suspicion that the shrink-wrapped software development
mentalities have trickled into the Web world, but the old rules don't really
apply anymore. We don't have to have a "perfect" product to launch, it's not
difficult to make changes/fix bugs, and there is no reason that we have to
launch any web application as the same application to every user (meaning we
can multi-variant test). Change use to be the enemy because it was difficult
to change, but now the ability to change our web applications is a strength.
When you have the opportunity to work with developers who aren't scared of
change, the world completely changes.

To address Matt's comment about design traps... you can build multiple
versions as fully functional working prototypes using the framework that
they'll be in when they're launched and test them. The whole idea that
something is can be "built" and "done" on the Web is wrongheaded. Something
can be launched, but it's NEVER done.

Sorry for the diatribe. I guess the point in the context of the thread was
"just build it". You can change it.

--
Josh Viney
EastMedia Group
http://www.eastmedia.com

13 Apr 2007 - 3:18pm
Chris Bernard
2007

Two quotes come to mind, one about film and the other about improving a home.

The film one is, "Films are never completed by a creator, they are abandoned." The one about a home is (apologies for the gender bias but I want to repeat it as I heard it), "When a man is truly finished improving a home, he dies."

But I digress...I think there clearly are some distinct advantages to Web focused development strategies that play on the strengths of dynamic and script-based languages. I'd also add that I think this is what is driving some of the models around WPF, WPF/e, Flex and Apollo too with things like MXML and XAML.

I continue to see a mash-up of workflows that take the best of the shrinkwrap (what I'd really call desktop) world and see it combined with the best of the Web. In the case of .NET that's clearly what technology like XAML and WPF are trying to do. It's just as easy to push updates to an internet aware auto-updating application as it is to update a centrally located codebase in a Web app (well, not just as easy, but it eliminates a principle shortcoming that desktop software had when distributed via shrinkwrap). Notable examples of this include how tools like Firefox and iTunes work in addition to OSX and Vista.

Rails and Ruby might very well be the most design friendly programming language and framework out of there right now but I bet that it's still a challenge for all designers to embrace. (And I'd put WPF in a similar boat too for now although our intent is to get Blend to a point very soon where a designer can do just about all they would ever want without having to touch code).

I'd also suggest that for every easy thing the Web has enabled for software development there are some constraints we've inherited too. We make JavaScript do some incredibly complicated and laborious things that create great user experiences but at some pretty large development, performance, maintenance and compatibility costs. Much of this cost is borne by the capital intensive nature required to support large, successful Web based applications that don't take advantage of the power available on the client. For example, online photo editing ala Photoshop in a browser may be possible but is it a good idea? Do we want everyone in the world bouncing 2 to 4 meg photos around the internet when they've got idle local computing resources that could do the job better?

Managed code and locked down environments like Flash can sometimes provide similar or better interactions without all that development pain. User experience is critical but the other bar that experience will be measured by is how much it costs to design, build and maintain it. Over the past 10 years or so the advantages here have typically gone to the Web but I wonder if that pendulum is going to start swinging the other way now as desktop applications become more internet aware? I think the reality is that the future might well get intentionally fuzzy in this regard and we'll often be designing digital experiences for multiple channels. I wonder if a one size fits all approach will work in the future?

Chris Bernard
Microsoft
User Experience Evangelist
chris.bernard at microsoft.com
312.925.4095

Blog: www.designthinkingdigest.com
Design: www.microsoft.com/design
Tools: www.microsoft.com/expression

-----Original Message-----
From: discuss-bounces at lists.interactiondesigners.com [mailto:discuss-bounces at lists.interactiondesigners.com] On Behalf Of Josh Viney
Sent: Friday, April 13, 2007 1:31 PM
To: IxDA Discuss
Subject: [IxDA Discuss] Do tools matter in Big D design from an execution perspective? Formerly Expression Blend a "review"

Chris,

Interesting comment at the end Re: Basecamp. I moved from a UX/Product
Manager role at a company firmly entrenched in .Net to a company developing
in Rails. One thing I've noticed in the Rails arena is a change in the way
developers work. Beyond all of the framework debate, I've found the biggest
benefit of the Rails community to be the willingness to jump in and build
and build again. When there are discussions in IxDA about prototyping tools
like Flash, I always want to respond with "why use Flash or Photoshop as a
prototyping tools if the web application won't be built using Flash or
Photoshop?" (note admittedly it's a bit different story when talking about
desktop software). I've seen working database driven Rails web application
prototypes built in less than an hour, and I'm not sure it would be much
different with any of the newer frameworks.

I have this sneaky suspicion that the shrink-wrapped software development
mentalities have trickled into the Web world, but the old rules don't really
apply anymore. We don't have to have a "perfect" product to launch, it's not
difficult to make changes/fix bugs, and there is no reason that we have to
launch any web application as the same application to every user (meaning we
can multi-variant test). Change use to be the enemy because it was difficult
to change, but now the ability to change our web applications is a strength.
When you have the opportunity to work with developers who aren't scared of
change, the world completely changes.

To address Matt's comment about design traps... you can build multiple
versions as fully functional working prototypes using the framework that
they'll be in when they're launched and test them. The whole idea that
something is can be "built" and "done" on the Web is wrongheaded. Something
can be launched, but it's NEVER done.

Sorry for the diatribe. I guess the point in the context of the thread was
"just build it". You can change it.

--
Josh Viney
EastMedia Group
http://www.eastmedia.com
________________________________________________________________
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

13 Apr 2007 - 4:01pm
Michael Micheletti
2006

Hi Chris,

I used to prototype a lot in HTML/Javascript when I worked more on
large-scale web applications. Then I moved to a small specialist company
working much more with installed applications and SDKs. Here, paper
prototypes are my friend. I work on sketches and specifications somewhat
concurrently, testing as I go using paper. I usually test at the component
level and don't try to mimic the entire application.

What I like about testing paper prototypes is that I have a way to solve the
common design situation where there are two or three competing solutions to
a problem. I can create a paper prototype for each solution, try each one
out, and know right away how they work without having a developer build
anything. Perhaps Ruby or other environments really are quicker than cutting
out a couple dozen paper shapes and hallway testing with a few people, but I
know that code sometimes grows frail with overhandling and needs refactoring
after too many quick changes.

I'm not too worried about taking time creating paper prototypes and informal
testing. The time and stress saved by the development team from not building
the wrong thing, tearing it down, fixing bugs, and rebuilding it again with
people yelling at them makes it all worth it. Helping developers to not
build the wrong thing is one of the most important things that I do.

Ok off to take my own medicine now and work on the fourth rev of design
sketches...

Michael Micheletti

On 4/13/07, Chris Bernard <Chris.Bernard at microsoft.com> wrote:
>
> I'm also curious how we reconcile this with many of the current trends in
> Web development. For example. Let's look at an application like Basecamp
> from 37signals.com. What's the best way to bring that application to life?
> What's the best way to prototype it. In Photoshop? In Flash? Or just build
> it?
>
>
>

13 Apr 2007 - 9:26pm
Dave Malouf
2005

I think the permise of the original question is off a bit b/c I'm not
sure I understand what "Big D" design is. Is it to say that it is
"Strategic Design"? Is it to say that it is everything design?
experience design? I know I throw around the term a lot myself but I'm
finding it less and less useful as of late (I'm starting to feel a
personal backlash towards the term.)

I would say all design requires tools. Why? Because at some point you
have to communicate your ideas. You can have the best ideas in the
world, but if they are poorly communicated, they are meaningless. And
then, even the best strategic design without proper execution is also
meaningless, but if you couldn't even communicate the strategy well in
the first place, then, you probably didn't get a chance to execute
anyway.

So all design has "craft" or as your buddy from ID recently put it,
you need skills. The way my teacher in Industrial design class put it
is that there is theory, the ability to recognize good design (I'll
call it crit) and then the ability to do which he associated with
muscle memory. So, I'lll sum that up with "Knowledge, Criticism, and
Action". At every level of fidelity of design those 3 things exist and
you cannot go lower in altitude at any given point unless you have
done the right actions with the right tools.

All this is to say that at a certain point your level of fideltiy in
order to accurately articulate your ideas will require that point
where the rubber meets the road, or in the case of software design,
where the visuals meet the interactions.

In Industrial design, you can't live with foam or primer. Yes, these
are good for "sketching" your ideas, but at some point when you make
your pitch you create an appearance model and tweak that as well. The
level of detail is great on purpose.

Now it could be said that concepts are best developed at the sketching
level, but design does not stop at concepts. Concepts are good, but
you will always need to bring execution to those concepts.

When it comes to prototyping, whether it is in "throw away" or
production quality or something in between, at some point you have to
hit reality of constraints, as the constraints themselves become part
of the problems that require design thinking to solve. Working inside
those constraints at some level of the problem solving exercise in my
mind is a requirement of good design. Avoiding the constraint level
and you will create new problems during production.

Normally, I will fight tooth and nail to say that prototypes should
not be part of production, but lately, my tune has changed and it is
really because I have found that I require control more than I require
technical freedom. I have been a scope exploder my entire career due
to a lack of what I'll call tactile design of prototypes, or proof of
concepts, and it has caused a loss of control of the vision of my
designs putting the final execution in the hands of those that "don't
get it".

Since this was connected to the Blend software, i saw Blend as a
tremendous opportunity for me to get that control back in a tool that
was meant for designers (as it was included in a DESIGN suite of
tools). If someone, anyone can fulfill that promise to the design
community to get the control we need of our designs, that company that
does that will bring a huge value to IxD.

Is Flash, in the Flash/Flex/Apollo combo it? Right now MS doesn't have
that tool, maybe Blend 2.0 will be it.

Or!!! is it more about creating tighter units of collaboration where a
designer and a UI engineer work the way cooper intended the Designer
and Design Communicator to work. I mean why have a technical writer
(the original role that Cooper is describing) when the communication
of the design IS the product's creation. Maybe this is the co-designer
relationship we should be looking at.

-- dave

Syndicate content Get the feed