The Missing Red Line
It was 2008 and if you were a designer at Microsoft, as I were, you would hear about Windows Presentation Foundation all the time. It was the promised land. As easy and interactive as Flash while still real. You could make real Windows Apps and more importantly for us designers, you could build your prototype in Blend, the visual editor for WPF, and your developers could open it up in visual studio and just hook up the backend and all would be joy and happiness.
No more redlines. No more confusing documentation. No more silly static screens.
I was in.
I was working on Windows Server and related Windows Management technologies. We were working on a set of components that all the various Windows Server teams could use instead of creating their own lists, navigation, preview panes, task panes and so on from scratch. Our team had counted and there were 13 different list implementations across the various Windows Server teams and quite a few different scrollbars. We were going to deliver a design pattern library backed up by code. A great place for a design team.
Our product and design team in Redmond had been at this for a while. We had all the basic components roughly designed and speced out but we didn’t have a partner team yet. We needed someone to sign up to build or re-build their app with our new components to make it real.
A team in Shanghai signed up. They were going to re-implement Active Directory Users and Computers in C#/WinForms and eventually jumped on board because we convinced them that unless they went all the way to WPF they’d still be one step behind.
So we went to work. We interviewed Active Directory Users, we learned about the Active Directory technology, and I built a prototype to communicate the design.
It was a prototype of the full product. A good friend of mine and one of the developers on the component library team built an Active Directory demo data generator and helped me hook that up so the prototype also felt real. It didn’t save between sessions and it crashed occasionally but overall it captured everything in the product and whenever we changed designs I changed the prototype. It was a great communication tool.
And then the project was suddenly very real. The team in Shanghai was building the app and the team in Redmond kept building the components. And in true WPF fashion I worked in a mix of Blend, Visual Studio, and Source Depot (similar to Git, just internal to Microsoft). The prototype was used less and less as the real product took over.
And then one day as I opened up the app something was very wrong. The Navigation pane and the task pane headers were completely misaligned.
I opened up the editors and took a look at the code and realized that the two components were built in such a way that they didn’t know anything about each other. Their headers would grow and shrink independently of each other and the fact that they had been aligned so far was mere coincidence.
I was flabbergasted. Why would the smart and design-oriented developers on the component team build it that way? Was it not obvious that those two panes needed to be visually aligned?
Of course it wasn’t obvious. Further more, the developers had taken some architectural choices that made it really hard to fix. They pointed out, and rightfully so, that some apps in the future might not have Task panes or might be so simple that they would not need Navigation panes. And because of that they had isolated the two components completely.
This was seven years ago and I still remember it to this day. In my eagerness to ditch the static screens and the tedious repetitive work of redlines I had bought completely in to the idea of the prototype as the documentation. I had left out that single diagram that could have explained the relationship between all these components and prevented this issue.
And with an issue like this popping up. Something this big and obvious, of course there were many smaller problems that we needed to dig out. None however had the same massive architectural implications.
Prototypes are great. Today’s tools like FramerJS and Origami make it incredibly easy to built prototypes that let you actually experience the product before you build it and no diagrams or static screens can do that.
But prototypes cannot communicate intent. They can’t communicate why two elements are or are not aligned. Similarly prototypes are not good at communicating all the screens in the app. You still need some kind of inventory or diagram for that. Prototypes are crucial. They let you experience the product. But prototypes are not the silver bullets I thought they were. That morning seven years ago really drove that home.