BLOG by zaiss

Reality for designers who work in Microsoft shops has changed in the past year, mostly due to the fact that the Microsoft Marketing Machine has worked exceedingly well. The message - targeted primarily to developers, mind you - is that the Expression suite of products solves all your developers’ woes around translating designs into functioning code. The pain point is legitimate, and so the message has sunk in. It’s best exemplified in Wildermuth’s point #6:

Having previously worked for Microsoft (in the Developer Division, no less), I’m a pretty staunch advocate of alleviating this pain point. I’ve seen it break down efficiency in numerous organizations. So when I began a new job three months ago, I set out to make Microsoft’s vision of a smoother design-developer workflow a reality. Below are some lessons that I picked up that I think developers, designers, and managers should be aware of.

Two caveats before I rattle off the list. First, my current job involves working on a web application, and the application will be primarily in ASP.NET, not Silverlight. However, having worked with WPF and XAML quite a bit during my time at Microsoft, I think these points still do apply across the board, but if they sound web-specific, you know why.

Second, my job is a hybrid of program management and design, so I specify functionality along with the design. This might be more responsibility than a traditional design role, so my focus on efficiency might not be relevant to everyone.

On to the list…

1. It’s not “business as usual” for your designers.
When I see a sentence as simple as, “Using Blend is like Adobe Illustrator or Photoshop,” it makes me cringe.

I’m very positive on the Expression tools, but developers should be aware that Wildermuth’s statement is equivalent to saying, “Using Visual Studio is like Eclipse.” Technically accurate: You can write and publish code with both. But if you love Visual Studio and a non-technical manager told you, “Right, we’re all using Eclipse now!” you wouldn’t be thrilled. And when the same non-technical manager said, “But I read somewhere that using Visual Studio is the same thing as Eclipse,” that would likely further escalate the discussion.

The issue isn’t one of what can and can’t be done in different products, it’s one of efficiency. Nothing can change the fact that Adobe has been in the designer tool market for longer than Microsoft: Designers are naturally more efficient (and more comfortable) with Adobe products. From my standpoint, the way to get designers jazzed about Expression is to actually market to designers, not to their developer colleagues.

2. Designers will be writing code.
And I’m not just talking about markup or stylesheets. This is more an issue with an ASP.NET application than with XAML and Silverlight, since XAML is powerful enough to express almost anything visual that designers can envision.

If you aren’t living in the Silverlight world, however, things get trickier. Take drag and drop on the web, for example. Without Silverlight or Flash, that’s a JavaScript problem. One that technically exists in the UI space. Is this now a job for your designers?

And what about data access? I notice that Expression Web is fully equipped with all of the standard ASP.NET query capabilities. Technically, deciding what data is displayed is a UI problem, but in my case, designers would never be allowed to write queries.

I suppose the benefit is that Expression is flexible enough that, no matter where a shop chooses to draw the line between design work and development work, that setup will be supported. But there’s still a need for designers to play in development space.

3. Designers will be making development decisions.
Quiz time: What is the object below?

Designers might consider it a table, or a grid. But in the ASP.NET development world, it can be any of a number of controls for showing data: GridView, DataList, Repeater, or a ListView. All of these controls are available for use in Expression Web, but what will a designer choose? A simple HTML table? Maybe a Repeater, or a GridView? How about a ListView? (The last one’s rhetorical… as the facilitator of the ListView usability test, I can attest that designers are not the target audience for using a ListView.)

In the Expression world, when I propose a design, it comes with development decisions. For example, how do I design an Amazon-style drop-down panel? In order to complete the design I’m now blocked by development questions. In my case, I’m technically inclined enough to arrive at some answers - but that doesn’t save me from a long discussion (and some redesign work) when I toss the spec over the wall. For designers who aren’t as technically inclined, how do they proceed in expressing their vision?

4. Designers will start accruing UI development bugs.
So I’ve already written some code and made some decisions about which controls to use. The project goes over to the developers, who realize two days later that something isn’t displaying correctly, and it’s not the fault of code they’ve written. Now what? Do we keep up the pretense that developers will do no UI work to improve their productivity, and ship it back to the designer with bugs? Or do we let the developers make the changes, only to leave the project in a state that designers no longer recognize when they decide to redesign the product?

We opted for the former. And our developers got upset. While we had every intention of improving their productivity, instead we took a chunk of their traditional territory out of their control. Can you imagine seeing something wrong with your work and not being able to fix it? If you’re passionate about your job, that’d be pretty tough to do, and our developers are all passionate folks.

But the developers played along, and filed bugs instead of doing the work themselves. So that same work passed on to the designers, and that same work got done on designer time instead of designing new screens and moving the product forward.

5. Designers still aren’t producing the right artifacts.
This point might be contentious, but in the two projects I’ve worked on that were Expression-relevant, it held true. In these two projects, what was needed from the designers was a theme - something that could be generically applied - not just the design of one static page.

Expression can be used to create theme files, but there’s no visual way to do it. With themes, you’re not designing anything in particular; rather, you’re saying what something should look like once it’s implemented. When that story can be told with, “and it’s like Adobe Illustrator and Photoshop,” appended to the statement, I think someone will really have a home run on their hands. For now, though, it’s adding design-to-code translation work to someone’s plate.

6. Developers outnumber designers at your job.
Please share if you have a counter-example. I’m willing to learn. But with the exception of all-design shops, I have yet to see an organization that has more designers than developers. Despite usability’s recent upswing in popularity, there is still an extremely heavy priority toward building something than deciding what to build.

Put that in context with the first 5 points. Taken alone, none of those points may seem extreme, but when you envision your already-taxed designers taking on development responsibilities, the improved design-developer workflow loses its luster. In my case, I started three months ago with a company full of people universally eager to adopt Expression in order to make development easier. The consequences have had time to show, and now we’re going back to the old way - not because the workflow broke down, but it took up too much design time doing tasks that were traditionally oriented to developers.

What I think would be more compelling would be to focus on the other end of the designer-developer workfllow: How can you take a designer-made image and break it down into pieces that a UI control can consume and render? Admittedly that puts the onus back on the developer to do the translation work, but I’d contend that the larger numbers would absorb the productivity bounce a lot faster.