|
|
|
|
|
Designing with Expression Blend™
Design before you Blend
Not too long ago I was doing some design work for
a large software company in the Pacific Northwest. I was
asked to deliver my designs in XAML, using Blend as a tool
for creating the XAML and C# as the code-behind. “Great!”,
I thought, “I’ll learn some new skills and I’ll be able to
deliver the executed designs directly to the development
team.”
Project
management also saw the opportunity for saving time and
streamlining process. If the designer (me) could execute
his ideas in Blend, the development team could just pick up
the presentation layer from my hand-off and add the tricky
bits to make it fully functional.
I have become comfortable with Fireworks for
wireframes, Illustrator for final design illustrations and
icons, InDesign for redline spec
documents and the latest version of Visual Studio
for prototype development. I am able to move with ease in
these applications and I’m able to produce deliverables that
have meaning and value for my clients.
I imagined
that Blend would condense my own process. I would move from
wireframes directly to final design execution. I mentally
hosted a private little laugh at six sigma protagonists; my
new scorn & ridicule for their tyranny was making me giddy.
A few weeks later: Delivering the design
With the wireframes and prototyping done, at last
it was time to start putting the final design together.
Instead of using Illustrator to create the final screen
shots and then InDesign to redline those shots with
descriptive text, I fired up Blend – for the first time.
I gradually
learned how to use Blend, but it took a great deal of
precious time. Now I was really pressed. The project
manager was biting his nails and was stopping by my office
with increasing frequency, asking “Can I see where you’re
at?” My days grew longer, my weekends vaporized and my
unbilled hours grew out-of-control as I attempted to work my
way out of the hole and salvage a valuable future
reference. I was living the consulting nightmare. You've heard the urban legends about dedicated developers wearing disposable gloves in order to avoid keyboarding nerve damage; well here's the best place to buy
latex gloves, or nitrile gloves. My advice is to change gloves often.
Finally, I
delivered the executed design to the development team. I
was so proud. No redline document. Who would ever need
that? I was delivering the fully executed design itself.
The entire presentation layer had just been handed off! I
went back to my room-away-from-home that Friday night and
slept long and easy.
Monday morning
I accepted all the accolades for the clear, beautiful
designs and everyone marveled at the new paradigm – so much
time had been saved. “Yes.” I flatly droned in agreement,
“Wonderful.” My voice may have trailed a bit, but nobody
noticed. I was grateful to be done.
I knew that
another version of this product was already in the pipeline,
so I wondered how I should approach this revision. Perhaps
I should just start working in Blend all the time, doing
wireframes, prototypes and moving quickly to executed design
all in the same application.
Surprise, Surprise
Later that same Monday, I
was called back into a meeting in the project manager’s
office.
He explained, "We've got some changes that we need to make to
the way it works.”
(continued
at top of next column) |
|
|
|
(continued
from left column)
“Why?” I asked.
“We don’t have enough developers to do everything that you
put in the design.”
I tried to bring recent history to bear: “But we agreed on
everything that’s there. Remember? The requirements, the
wireframes, the prototypes?”
He sighed, “Yeah, but we never had a spec to sign off on
before you went ahead and
did everything.”
I was flabbergasted. He was telling
me that some final decision-making, the tough decisions,
had been deferred pending a final design specification. And
now, my just-delivered XAML was being used as a final design
review.
So I had not delivered the executed
design after all. I had taken a really long time to deliver
a non-redlined final spec. And final review was only
just now beginning.
There were other problems with this:
- The deadline for developers to
start developing had come and gone.
- What I had delivered was not
just text and pictures. It was code. It was complex.
It was not as easy to change as simple text &
illustrations.
- The only people who could
review my design were those team members who had every
single piece of the full coding IDE installed.
- It’s impossible to put code
behind a presentation layer that is going to change
fundamentally. So now, the development team was waiting
on another design delivery from me before they could
even begin to work. So much for catching up on my
sleep.
- I still did not have a final
design spec that we’d all agreed upon. There was
definitely no time for that now, but when were we all
going to agree on what was going into this software?
None of this
was Blend’s fault. It was my fault. I had been so anxious
to ditch a tedious and very requiring part of the design process
that I had quickly jumped onto the “Ditch the spec!”
bandwagon.
Don’t make the mistake that I made
Here is the
lesson that I learned: Designs need to be communicated
before they can be executed. There needs to be a
document that focuses the attention of the team and demands
resolution from all stakeholders. Having a clear, detailed
target specification is the ultimate design deliverable.
I love
Microsoft Expression Blend™ and
I am using it all the time. It is a powerful tool for
creating immersive, cinematic user experiences. I love the
Win/Web flexibility that XAML promises. Our design studio
has decided to publish a set of XAML controls and I am
heavily involved in that project. I also hope to finish
writing a book on Blend techniques. I am a Blend
apologist. With Blend, you can deliver executed designs and
control every pixel of the presentation layer. But it is
not a tool for communicating design specifications.
Don’t make the
mistake that I made. Deliver a design spec before you start
working in Blend.
- Dave Walker |