UX Tip: Just because you can count change, doesn’t make you a mathematician

I was watching a MIX2010 video from Microsoft’s head UX guru, Bill Buxton on how specifically developers and designers engage with one another. There was a throw away line he put out there, which was stated in reference to developers whom often think that because they have a bit of design muscle deep down that they too can contribute to the design discussion –

Just because you can count the change in your pocket, doesn’t mean you’re now a mathematician.

I laughed when I heard this as yes, design is an art (who knew) and often at times we take it for granted a lot more than we probably care to admit out loud.

For me personally, given I’ve visited countless developers in a variety of scenarios in the Microsoft space, one constant theme I see continues to emerge, developer art.  This consistent pattern is the exact fit for the above analogy.

Allow me to explain further..

Developer Art


Developer art is the composition of a interactive solution that almost looks good enough to ship, but when you start to tease away at the various threads (i.e. DataGrids) you begin to see that there isn’t a lot of structured thought put into place behind the “Why” the screen is structured the way it is. In that, they often tell a story as to why it’s important to cram as many UI elements onto a screen making full use of all the pixels you are given and then some. It has certain hints of developer based design and structure but it comes across very adhoc and chaotic in thought.

“Oh yeah, I’ll add that button in later..”

I admire their intent (truly), but sadly this is really just re-echoing bad habits into a new medium and all we’ve really done going forward is polished the cumbersome UX and it’s attached pixels with a brighter gloss – the problem continues to live on though, and user’s are expected to jump through hoops due to poor software development planning and useless deadlines that in reality are more than likely going to increase the problem rather than decrease it.

Note: Most devs i’ve engaged with this, are aware of this as well, and are openly keen to get this fixed (very encouraging days ahead).

That being said, developer art tends to lead into Pixel Cramming

Pixel Cramming


Having a large screen is tempting to do a lot with, but in the end we must remember an important fundamental about humans, in that we like to chunk information into pieces that make sense to us. We listen to a story and isolate important pieces, in that we tend to skim read large documents and isolate important facts / figures. We often hear a story and isolate key pieces of information and bank that into our working and/or short-term memory.

Chunking is a clue to how your end users approach things in general, yet with developer art UI, it tends to be blatantly ignored. The reason being is, most of the time developers want to take a large resolution of pixels and fit as much data and finite amount at that, onto the one screen – because users like to analyse all of this data is usually the response I often hear.

I could inject countless research papers here on how humans + density = cognitive overload and the chances of recall and/or visual encoding are diminished as you layer more and more amounts of data. I don’t though as depending on how you deliver that message can lead to an emotive discussion focused around the words “I think”, less “I know” (which is really the base primitive used to instantiate an argument randomly.

Instead I come at it from another direction, that is asking the developer(s) to consider layering complexity.

Layer in Complexity.


I often tell developers to start easy and then layer in density or complexity (as you learn more about your end users expected habits or paths of access).

I do this for a number of reasons.

Firstly it’s a sneaky trick I play on you, as it forces you to think about the big picture first from an end users perspective, whilst it then removes you from that pesky habit of getting bogged down in the finite details (engineers play chess with UI, they are always trying to guess 3 moves ahead).

Once you structure the surface of your UI in a way that mimics the way humans process information, you just may stand a great chance at producing some UI that doesn’t feel like a page out of the classified section.

Secondly, another reason as to why I ask you to layer in complexity/density is that it can help safeguard you from creating lots of virtual problems that probably don’t need solving. What I mean is that approx 80% of your end users are likely to only use 20% of your features, which in turn means that if you were to ship V1 as a very basic piece of software without the cascading density of UI you would in turn raise questions within your user base that are mostly likely going to yield you a lot of “I know” to questions that are probably coming up with “I think” today.

(Behind the scenes you are effectively doing an on the fly qualitative analysis on your said upcoming software’s development approach).

What If I were to come into your developer enclosure tomorrow, walk up to your feature task board and steal 30% of the features away from your product randomly. How would your end users react? I know how you’d react, but really, how would you’re end users react. Would they even notice it’s missing and if they did notice it was missing what story would they in turn tell you about why it’s important. Once they do tell you this information, and I only agree to give you half of the features back, how would you weight the importance against what you already have today done or still on the board.

My point, you do this anyway, you often start out with a healthy amount of feature requests, but through the inertia of development these features get squashed, contorted and at times glossed over in the development process. It’s a really negative impact on what started out with so much positivity.

Bottom line is this.


Engage a UX Professional as well as a UI Professional, as in the end they think about these various points allot (at times both from different angles), and typically see the world for the chaos that it is and less inclined to care about you the developer (It’s not you, it’s not me either, it’s them, ya know, the end users). If you don’t already, do some persona development around your product and it’s important to do this. If you have done this, then grab some wall space and scrap book various clues about the end user for all to see. Remind yourself daily who it is your developing for and why. Ask yourself “Which person’s life am I going to ignite with this feature being done perfectly, done in an ad hoc fashion and/or not done at all”. You should have an answer to this with a degree of confidence that should be shared by all.

Does this mean all design is hands off to developers?

Yes and no, if you aren’t passionate about the concept of what design is, you really need to step back and let someone who is genuinely curious about solving problems for end users through interface design and less about shipping schedules or how brilliantly they orchestrated their MVVM architecture. As the ironic thing about development patterns is you’re building software to make life easier for developers to be apart of? funny, why can’t you do the same for the end users?

I’m not an expert, far from it, I’m just experimenting out loud with all of this, but the more I data I gather, the more I start to see how all these puzzles fit and all to often, developers are trying to be too many roles at once and well, humans are never really good at multi-threading – hence we chunk.

Related Posts: