First of all, this is not the redesign I’ve been alluding to for the past few months, rest assured. However, as part of the redesign (that I’ve been working on over this weekend), I needed to upgrade the current blog to transfer all my posts over. The upgrade broke the old theme, hence the visual changes.

Bigger changes coming soon, the new blog is looking great (if I do say so myself). Stay tuned!

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.

I had been playing a game with Vince (Japan), Eric (Lincoln, NE) and Jason (Omaha, NE). Vince and I were neck and neck for most of the game, and at the end it looked like he was going to win. In fact, the word-by-word score showed Vince winning, yet somehow the win went to me:

Vince, determined to have an untarnished Scrabble record, encouraged me to investigate the discrepancy. I’m nice, so I did. I opened the “Contact Us” page on Scrabulous, and found there was an FAQ about scoring already:

Now, it turns out that the rules do, in fact, explain the discrepancy: The player to run out of tiles first ends the game and gets the point value of everyone else’s remaining tiles, while the other players lose the value of their own tiles. So, indeed, the scoring seems to be accurate.

But I have a hard time believing the tone that these guys are taking with their users. Saying “please” a couple times doesn’t take away from the fact that the FAQ question is essentially saying, “We’re perfect, you’re wrong, go away.” Furthermore, this particular case had very little to do with word scoring; rather, it had to do with an end-of-game rule that nobody was familiar with - the end score clearly conflicts with the word-by-word totals. Instead of getting me straight to the rules, the tone of the FAQ makes me want to email them out of spite since they’re treating me like a stupid user.

Early on in the MHCI curriculum, professors emphasized that Help is one of the four pillars of UI development. (Unfortunately, they didn’t emphasize the other 3 so I can’t remember them to save my life.) It’s clear that scoring is difficult for people to figure out, and it would improve users’ experience to add a little something to help them understand scoring inside the game.

In this case, the tone is just inappropriate. Users aren’t being mean, or attacking the developers’ ability to program when they have scoring questions. They’re trying to figure out how the game is played. A contextual link next to the scores (”How are my scores calculated?”) might fix the issue all together, and obviate the need for rude FAQs.

A couple years ago, I wrote about Windows XP’s habit of updating overnight and restarting the computer without user input. This caused its share of problems, but today Adobe topped it.

Back story: Apparently it was a big update day for Adobe, because I had almost 200 MB of updates to download and install. This process was taking a couple hours, so I went into a meeting with my coworkers. The meeting ends and I return to my computer. After a couple minutes, an unnerving dialog appears:

And here I am with Visual Studio open, an unsaved mock-up in Illustrator, two functional specs, and a half-written email. Freaking out, I desperately try to decide what to save first (meanwhile my boss is asking me what’s wrong since I’m making such a spectacle). After 15 seconds (much less than a minute!), my applications start closing. Despite my best efforts, the applications shut down before I could save any of them, losing a fair chunk of code and design in the process.

How did we go backwards in restart usability? The tradition from the 90s tended to be, “Your computer will restart now. Please close all open applications and click OK.” I have my gripes with that, but at least that didn’t give you a time limit!! I’ve watched a lot of web designers and developers work, and the one common thread is that they have many applications open at once. No matter how critical the restart is to the updating process, the decision to put a timer on the restart was an awful one.