Creating a designer & developer workflow end to end.


When I was at Microsoft we had one mission really with the whole Silverlight & WPF platform(s) – create a developer & designer workflow that keeps both parties working productively. It was a mission that i look back on even to this day with annoyance, because we never even came close to scratching the surface of that potential. Today, the problem still even with Adobe and Microsoft competitive battles in peace-time hasn’t actually been solved – if anything it kind of got slightly compounded or fragmented more so.

Absorbing the failure and having to take a defensive posture over the past five years around how one manages to inject design into a code-base in the most minimal way possible, I’ve sort of settled into a pipeline of design that may hint at the potential of a solution (i say hint..).

The core problem.

Ever since I think 2004, I’ve never been able to get a stable process in place that enables a designer and developer to share & communicate their intended ideas in a way that ends up in production. Sure they end up something of a higher quality state but it was never really what they originally set out to build, it was simply a end result of compromises both technically and visually.

Today, its kind of still there lingering. I can come up with a design that works on all platforms and browsers but unless i sit inside the developer enclosure and curate my design through their agile process in a concentrated pixel for pixel way, it just simply ends up getting slightly mutated or off target.

The symptoms.

A common issue in the process happens soon after the design in either static form or in prototype form gets handed off to the developer or delivery team. They look at the design, dissect it in their minds back to whatever code base they are working on and start to iterate on transforming it from this piece of artwork into actual living interactive experience.

The less prescriptive I am in the design (discovery phase) the less likely i’ll end up with a result that fits the way i had initially imagined it to begin with. Given most teams are also in an Agile way of life the idea that I have time or luxury of doing a “big up front” design rarely ever presents itself these days. Instead the ask is to be iterative and to design in chunking formations with the hope that once i’ve done my part its handed off to delivery and then it will come out unscathed, on time and without regression built in.

Nope. I end up the designer paying the tax bill on compromise, i’m the guy usually sacrificing design quality in lieu of “complexity” or “time” derived excuses.

I can sit here as most UX`ers typically do and wave my fist at “You don’t get us UI and UX people” or argue about “You need to be around the right people” all i want but in truth this is a formula that gets repeated throughout the world. It’s actually the very reason why ASP.NET MVC, WPF and Silverlight exist really – how do we keep the designer and developer separated in the hope they can come together more cleanly in design & development.

The actual root cause for this entire issue is right back at the tooling stage. The talent is there, the optimism is there but when you have two sets of tooling philosophies all trying to do similar or close to similar things it tends to kind of breed this area of stupidity. If for example i’m in Photoshop drawing a button on canvas and using a font to do so, well at the back my mind i realise that the chances of that font displaying on that button within a browser is less likely to happen then inside the tool – so i make compromises.

If i’m using a grid setting that doesn’t match the CSS framework i’m working with, well, guess what one of us is about to have a bad day when it comes to the designer & developer convergence.

If i’m using 8px padding for my According Panel headers in WPF and the designs outside that aren’t sharing the same constancy – well, again, someone’s in for a bad day.

It’s all about grids.

Obviously when you design these days a grid is used to help figure out portion allocation(s) but the thing is unless the tooling from design to development all share the same settings or agreed settings then you open yourself up from the outset to failure. If my grid is 32×32 and your CSS grid uses 30% and we get into the design hand over, well, someone in that discussion has to give up some ground to make it work (“lets just stretch that control” or “nope its fixed, just align it left…” etc start to arise).

Using a grid even at the wireframing stage can even tease out the right attitude as you’re all thinking in terms of portion and sizing weights (t-shirt size everything). The wireframes should never be 1:1 pixel ready or whatever unit of measure you choose, they are simply there to give a “sense” of what this thing could look like, but it won’t hurt to at least use a similar grid pattern.

T-shirt size it all.

Once you settle on a grid setting (column, gutters and N number of columns) you then have to really reduce the complexity back to simplicity in design. Creating T-shirt sizes (small, medium, large etc) isn’t a new concept but have you even considered making that happen for spacing, padding, fonts, buttons, textinputs, icons etc etc.

Keeping things simple and being able to say to a developer “Actually try using a medium button there when we get to that resolution” is at the very least a vocabulary that you can all converse in and understand. Having the ability to say “well, maybe use small spacing between those two controls” is not a guessing game, its a simple instruction that empowers the designer to make an after-design adjustment whilst at the same time not causing code-headaches for the developer.

Color Palettes aren’t RGB or Hex.

Simplicity in the language doesn’t end with T-shirt sizing it also has to happen with the way we use colors. Naming colors like ClrPrimaryNormal, ClrPrimaryDark, ClrPrimaryDarker, ClrSecondaryNormal etc help reduce the dependency of getting bogged down into color specifics whilst at the same time giving the same adjustment potential as the T-shirt sizes had as well – “try using ClrBrandingDarker instead of ClrBrandingLight”. If the developer is also color blind as in no they are actually colorblind, this instruction also helps as well.

Tools need to be the answer.

Once you sort the typography sizing, color palette and grid settings well you’re now on your way to having a slight chance of coming out of this design pipeline unscathed but the problem hasn’t still been solved. All we have done really is created a “virtual” agreement between how we work and operate but nothing really reinforces this behavior and the tools still aren’t being nice with one another as much as they could be.

If i do a design in say Adobe tools I can upload them to their creative cloud quite quickly or maybe even dropbox if have it embedded into my OS. However my developer team uses Visual Studio’s way of life so now i’m at this DMZ style area of annoyance. On one hand i’m very keep to give the development team assets they need to have but at the same time i don’t want to share my source files and much the same way they have with code. We need to figure out a solution here that ticks each others boxes as sure i can make them come to my front door – cloud or dropbox. That will work i guess, but they are using github soon so i guess do i install some command line terminal solution that lets me “Push” artwork files into this developer world?

There is no real “bridge” and yet these two set of tools has been the dogma of a lot teams lives of the better part of 10 years, still no real bridge other then copy & paste files one by one.

For instance if you were to use the aforementioned workflow and you realize at the CSS end that the padding pixels won’t work then how do you ensure everyone see’s the latest version of the design(s)? it realises heavily on your own backwater bridge process.

My point is this – for the better part of 10 years i’ve been working hard to find a solution for this developer / designer workflow. I’ve been in the trenches, i’ve been in the strategy meetings and i’ve even been the guy evangelizing  but i’m still baffled as to how I can see this clear linear workflow but the might of Adobe, Microsoft, Google, Apple and Sun just can’t seem to get past the developer focused approach.

Developers aren’t ready for design because the tools assume the developer will teach the designer how to work with them. The designer won’t go to the developer tools because simply put they have low tolerance for solutions that have an overburden of cognitive load mixed with shitty experiences.

5 years ago had we made Blend an intuitive experience that built a bridge between us and Adobe we’d probably be in a different discussion about day to day development. Instead we competed head-on and sent the entire developer/designer workflow backwards as to this day i still see no signs of recovery.

Related Posts:

VS2011 “Reimagined” – Class View

Note: The below is an attempt to contribute to the discussion around Visual Studio vNext and what I think personally should eventuate into features for future generations of Visual Studio. The objective behind this is not to declare the UI examples as “done” but more to provoke a discussion around ways in which the tool itself could become more intelligent and contextually relevant to not just developers but also those of us who can do both design and code. I plan on compiling this into a more comprehensive document post public feedback.


Today, the ClassView inside Visual Studio is pretty much useless for most parts, in that when you sit down inside the tool and begin stubbing out your codebase (initial file-new creation) you are probably in the “creative” mode of object composition.

Visual Studio in its current and proposed form does not really aid you in a way that makes sense to your natural approach to writing classes. That is to say, all it really can do is echo back to you what you’ve done or more to the point give you a “at a glance view” only.


The class view itself should have a more intelligent by design visual representation. When you are stubbing or opening an existing class, the tool should reflect more specifics around not only what the class composition looks like (at a glance view) but also should enable developers to approach their class designs in a more interactive fashion. The approach should enable developer(s) to hide and show methods, properties and so on within the class itself, meaning “get out of my way, I need to focus on this method for a minute” which in turn keeps the developer(s) focused on the task.

The ClassViewer should also make it quick to comment out large blocks of code, display visual issues relating to the large blocks of code whilst at the same time highlight which parts of the codes have and don’t have Attributes/Annotations attached.

Furthermore, the ClassViewer should also allow developer(s) to integrate their source and task tracking solutions (TFS) via a finite way, that is to say enable both overall class level commentary and “TODO” allocation(s). At the same time have similar approaches at a finite level such as “property, method, or other” areas of interest – (i.e. “TODO: this method is not great code, need to come back refactor this later”).

Feature breakdown.


The above is the overall fantasy user interface of what a class viewer could potential look like. Keeping in mind the UI itself isn’t accommodate every single use-case, but simply hints at the direction I am talking about.



Inside the ClassView there are the following Navigational items that represent different states of usage.



Usage by

Derived By

The “Derived By” view enables developers to gain a full understanding of how a class handles known inheritance chain by displaying a visual representation of how it relates to other interfaces and classes.



This inheritance hierarchy will outline specifically how the classes’ relationship model would look like within a given solution (obviously only indexing classes known within an opened solution).

  • The end user is able to jump around inside the minimap view; to get an insight into what metadata (properties, methods etc.) is associated with each class without having to open the said class.
  • The end user is able to gain a satellite view what is inside each class via the Class Properties panel below the minimap.

Class Properties.


Interactive Elements.

  • The end user is able to double click on a minmap box (class file representation) and as such, the file will open directly into the code view area.
  • The end user is able to select each field, property, method etc. within the Class Properties data grid. Each time the user selects that specific area and If the file is opened, the code view will automatically position the cursor to the first character within that specific code block.
  • The end user is able to double click on the image first circle to indicate that this code block should be faded back to allow the developer to focus on other parts of the code base. When the circle turns red, the code block itself foreground colour will fade back to a passive state (i.e. all grey text) as whilst this code is still visible and compliable, it however visually isn’t displayed in a prominent state.
  • The end user is able to click on the image second circle to indicate that the code block itself should take on a breakpoint behaviour (when debugging please stop here). When the circle turns red, it will indicate that a debug breakpoint is in place. The circle itself right click context will also take on an as-is behavior found within Visual Studio we see today.
  • The end user is able to click on the image Tick icon (grey off, green on). If the Tick state is grey, this indicates that this code block has been commented out and is in a disabled state (meaning as per commenting code it will not show up at compile time).
  • The end user is able to click on the image Eye icon to switch the code block into either a private or public state (public is considered viewable outside the class itself, ie internal vs public are one in the same but will respect the specifics within the code itself).

Stateful Display.

  • Each row will indicate the name given to the property, its return or defined type, whether or not it is public or private and various tag elements attached to its composition.
  • When a row has a known error attached within its code block, the class view will display a red indication that this area needs the end users attention.
  • The image eye icon represents whether or not this class has been marked for public or private usage (i.e. public is considered whether the class is viewable from outside the class itself – ie internal is considered “viewable” etc.).
  • Tags associated to the row indicate elements of interest, in that the more additional per code block features built in, they will in turn display here (e.g.: Has Data Annotations, Codeblock is Read Only, Has notes attached etc.).


My thinking is that development teams can attach tabs to each code block whilst at the same time the code itself will reflect what I call “decorators” that have been attached (ie attributes).

Example Tags.

  • image Attribute / Annotation. This tag will enable the developer to see at a glance as to what attributes or annotations are attached to this specific code block. This is mainly useful from a developer(s) perspective to ensure whether or not the class itself has the right amount of attributes (oops I forgot one?) whilst at the same time can provide an at-a-glance view as to what types of dependencies this class is likely to have (e.g use case Should EntityFramework Data Annotations be inside each POCO class? Or should it be handled in the DBContext itself?..before we answer that, lets see what code blocks have that dependency etc.).
  • image Locked. This ones a bit of a tricky concept, but initially the idea is to enable development teams to lock specific code blocks from other developer(s) manipulation, that is to say the idea is that when a developer is working on a specific set of code chunks and they don’t want other developer(s) to touch, they can insert code-locks in place. This in turn will empower other developer’s to still make minor modification(s) to the code whilst at the same time, check in the code itself but at the same time removing resolution conflicts at the end of the overall work stream (although code resolution is pretty simplified these days, this just adds an additional layer of protecting ones sandpit).
  • image Notes. When documenting issues within a task or bug, it’s at times helpful to leave traces behind that indicate or warn other developers to be careful of xyz issues within this code block (make sure you close out your while loop, make sure you clean-up your background threading etc.). The idea here is that developer(s) can leave both class and code-block specific notes of interest.
  • Insert Your idea here. These tag specific features outlined so far aren’t the exhausted list, they are simply thought provokers as to how far one can go within a specific code-block. The idea is to leverage the power Visual Studio to take on a context specific approach to the way you interact with a classes given composition. The tags themselves can be injected into the code base itself or they can simply reside in a database that surrounds the codebase (ie metdata attached outside of the physical file itself).

Discussion Points..

  • The idea behind this derived by and class properties view is that the way in which developer(s) code day in day out takes on a more helpful state, that is to say you are able to make at-a-glance decisions on what you see within the code file itself. At the same time providing a mini-map overarching view as to what the composition of your class looks like – given most complex classes can have a significant amount of code in place?
  • Tagging code-chunks is a way of attaching metadata to a given class without specifically having to pollute the class’s actual composition, these could be attachments that are project or solution specific or they can be actual code manipulation as well (private flipped to public etc.). The idea is simply to enable developer(s) to communicate with one another in a more direct and specific fashion whilst at the same time enable the developer(s) to shift their coding lense to enable them to zero in on what’s important to them at the time of coding (ie fading the less important code to a grey state).

Going forward, throw your ideas into the mix, how would you see this as being a positive or negative way forward?

Related Posts:

Decoding the use of grey in Visual Studio vNext

Visual Studio team have put out some UI updates to the vNext release. The thing that struck a chord with this update is how flat and grey it’s become, that is they’ve taken pretty much all colors out of the tool and pushed it back to a grey based palette.

Here are my thoughts:

On the choice of grey.

Grey is a color that I have used often in my UI’s and I have no issue with going 100% monochrome grey provided you could layer in depth. The thing about grey is that if it has to flat and left in a minimalist state it often will not work for situations where there is what I call “feature density.”

If you approach it from a pure Metro minimalist approach, then it can still work but you need to calibrate your contrast(s) to accommodate the end users ability to hunt and gather for tasks. That is to say this is where Gestalt Laws of Perceptual Organization comes into play.

The main “law” that one would pay attention to the most is the “Law of Continuity” – The mind continues visual, auditory, and kinetic pattern.

This law in its basic form is the process in which the brain decodes a bunch of patterns in full view and begins to assign inference to what it perceives as being the flow of design. That is to say, if you designed a data grid of numeric values that are right aligned, no borders then the fact the text becomes right aligned is what the brain perceives as being a column.

That law itself hints that at face value we as humans rely quite heavily on pattern recognition, we are constantly streaming in data on what we see; making snap judgment calls on where the similarities occur and more importantly how information is grouped or placed.

When you go limited shades of grey and you remove the sense of depth, you’re basically sending a scrambled message to the brain around where the grouping stops and starts, what form of continuity is still in place (is the UI composition unbroken and has a consistent experience in the way it tracks for information?)

It’s not that grey is bad, but one thing I have learnt when dealing with shallow color palettes is that when you do go down the path of flat minimalist design you need to rely quite heavily on at times with a secondary offsetting or complimentary color. If you don’t then its effectively taking your UI, changing it to greyscale and declaring done.

It is not that simple, color can often feed into the other law with Gestalts bag of psychology 101, that is to say law of similarity can often be your ally when it comes to color selection. The involvement of color can often leading the user into being tricked into how data despite its density can be easily grouped based on the context that a pattern of similarity immediately sticks out. Subtle things like vertical borders separating menus would indicate that the grouping both left and right of this border are what indicates, “These things are similar.”

Using the color red in a financial tabular summary also indicates this case as they are immediately stand out elements that dictate “these things are similar” given red indicates a negative value – arguably this is a bit of digital skeuomorphs at work (given red pens were used pre-digital world by account ledgers to indicate bad).

Ok I will never use flat grey again.

No, I’m not saying that flat grey shades are bad, what I am saying is that the way in which the Visual Studio team have executed this design is to be openly honest, lazy. It’s pretty much a case of taking the existing UI, cherry picking the parts they liked about the Metro design principles and then declaring done.

Sure they took a survey and found responded were not affected by the choice of grey, but anyone who’s been in the UX business for more than 5mins will tell you that initial reactions are false positives.

I call this the 10-second wow effect, in that if you get a respondent to rate a UI within the first 10seconds of seeing it, they will majority of the time score quite high. If you then ask the same respondents 10days, 10months, or a year from the initial question, the scores would most likely decline dramatically from the initial scoring – habitual usage and prolonged use will determine success.

We do judge a book by its cover and we do have an attractive bias.

Using flat grey in this case simply is not executed as well as it could be, simply because they have not added depth to the composition.

I know, gradients equal non-metro right. Wrong, metro design principles call for a minimalist approach now while Microsoft has executed on those principles with a consistent flat experience (content first marketing) they however are not correct in saying that gradients are not authentically digital.

Gradients are in place because they help us determine depth and color saturation levels within a digital composition that is to say they trick you into a digital skeumorphism, which is a good thing. Even though the UI is technically 2D they do give off a false signal that things are in fact 3D? which if you’ve spent enough time using GPS UI’s you’ll soon realize that we adore our given inbuilt depth perception engine.

Flattening out the UI in the typical metro-style UI’s work because they are dealing with the reality that data’s density has been removed that is to say they take on more of a minimalist design that has a high amount of energy and focus on breaking data down into quite a large code diet.

Microsoft has yet to come out with UI that handles large amounts of data and there is a reason they are not forthcoming with this as they themselves are still working through that problem. They have probably broken the first rule of digital design – they are bending their design visions to the principles and less on the principles evolving and guiding the design.

Examples of Grey working.

Here are some examples of a predominately grey palette being effective, that is to say Adobe have done quite well in their latest round of product design especially in the way they have balanced a minimalist design whilst still adhering to visual depth perception based needs (gradients).



Everything inside this UI is grouped as you would arguably expect it to be, the spacing is in place, and there is not a sense of crowding or abuse of colors. Gradients are not hard, they are very subtle in their use of light, or dark even though they appear to have different shades of grey, they are in fact the same color throughout.

Grey can be a deceiving color given I think it has to do with its natural state, but looking at this brain game from National Geographic, ask yourself the question “Is there two shades of grey here?”


The answer is no, the dark & light tips give you the illusion of difference in grey but what actually is also tricking the eye is the use of colors and a consistent horizon line.


I disagree with the execution of this new look, I think they’ve taken a lazy approach to the design and to be fair, they aren’t really investing in improving the tool this release as they are highly most likely moving all investments into keeping up with Windows 8 release schedules. The design given to us is a quick cheap tactic to provoke the illusion of change given I am guessing the next release of Visual Studio will not have much of an exciting set of feature(s). The next release is likely to either be a massive service pack with a price tag (same tactic used with Windows7 vs. Windows Vista – under the hood things got tidied up, but really you were paying for a service pack + better UI) or a radical overhaul (I highly doubt).

Grey is a fine color to go full retard on (Tropic Thunder Quote) but only if you can balance the composition to adhere to a whole bunch of laws out there that aren’t just isolated to Gestalt psychology 101 but there is hours of reading in HCI circles around how humans unpick patterns.

Flattening out Icons to be a solid color isn’t also a great idea either, as we tend to rely on shape outlines to give us visual cues as to how what the meaning of objects are and by at times. Redesigning the shape or flattening out the shape if done poorly can only add friction or enforce a new round of learning / comprehension and some of the choices being made is probably unnecessary? (Icons are always this thing of guess-to-mation so I can’t fault this choice to harshly given in my years of doing this it’s very hit/miss – i.e. 3.5” inch disk represents save in UI, yet my kids today wouldn’t even have a clue what a floppy disk is? …it’s still there though!).

I’m not keen to just sit on my ivory throne and kick the crap out of the Visual Studio team for trying something new, I like this team and it actually pains me to decode their work. I instead am keen to see this conversation continue with them, I want them to keep experimenting and putting UI like this out there, as to me this tool can do a lot more than it does today. Discouraging them from trying and failing is in my view suffocating our potential but they also have to be open to new ideas and energy around this space as well (so I’d urge them to broker a better relationship with the community around design).

Going forward, I have started to type quite a long essay on how I would re-imagine Visual Studio 2011 (I am ignoring DevDev’s efforts to rebrand it VS11, you started the 20XX you are now going to finish it – marketing fail) and have sketched out some ideas.

I’ll post more on this later this week as I really want to craft this post more carefully than this one.

Related Posts: