How much would you invest in a pixel?

I am a massive fan of World of Warcraft again; yes, it is sad isn't it? Last night I was playing my usual allotment of time watching pixels update on a screen vs. interacting with real humans and something I witnessed struck a chord with me.

The 'flash of genius' for me was when I was playing a typical Player vs. Player (PVP) round of Battleground(s). This is a part of the game that essentially randomly aggregates a group of people spread throughout the entire WoW realm(s) into a 10vs10 etc match.

It's basically unbridled chaos and it really highlights some components for me that I find fascinating as to watch the herding mentality of us humans in an avatar driven game is kind of predictable. For instance, I was the first out of the gate when the match started, I rode my horse towards a spot that was the second closest and because I was the party leader, many other players followed me. I arrived at the spot and just waited. Out of the six other players, three stayed after 20sec has or so of making decision whilst the other three grew what I can only imagine as being bored and rode off in search of a fight.

imageWhat is so profound about this is how easily I convinced others to wait beside me in a place that had no real plan other than "well, if the sh*t goes down, we defend with our lives" as the core plan. We had no vision of what was about to happen beyond that and we had no clue as to how we would all work together as we just met each other in game only 5mins beforehand. Here we are armed ready to fight and hoping we can figure it out as we go.

We died.

This is much like most teams I've been in over the past few years, I keep hearing about a good team is one that is in sync with one another but in the end that only lasts for the first flag/waypoint as beyond that a lot of variables occur that in turn causes a de-synchronization from occurring. 

In the above example had I been paired with a healer and another tank/dps (tank or dps are basically characters whose sole job is to hit hard and often as a healers job is to keep everyone alive while they do so) we may have stood a chance of survival. As we all had a role to play and whilst the plan was distilled into a core class structure, we still have a series of objectives that must be upheld.

A healer must be protected at all cost, as well that character is your tipping point between living and dying but at the same time a healer must keep back from the fight - as much as possible. A tank/dps job is to draw fire and get deep into the melee as much as possible and the more you can tie up your enemy's focus the greater the chance of a win.

In software, this concept has not entirely lost, as a UX/UI person(s) job is to figure out how to keep this software from dying of bad usability death. The coder's jobs are to underpin it with large amounts of code to keep structural integrity intact if they do not do their jobs rights, it can in turn create more work for the UX/UI person to go fix. If the UI/UX person does not do their jobs, right they can in turn suffocate the work of the coder - so it is a partnership.

A great software release respects this partnership to the end. Good UI/UX and Good Code = Good software.

If you randomly put together a team of mixed classes and pin your hopes on the agile a way of life then well you are no different to my WoW example. An assumed leader leads a group of you into a spot that has no agenda or plan other than "don't die please".

How you live or die is based purely around how fast you can communicate with one another about what tactics you can deploy to uphold this basic principle of preserving one's life.

All it takes however is one person to break ranks, to be the Leroy Jenkins (See Video below) and well it comes unstuck and fast. We all die of a horrible humiliating death - (aka miss our deadlines etc.).


Agile is not enough, is my overall point. I think agile works if you are solely focused on being a tank/dps class (coder). If you mix in UX/UI then that is where it keeps coming back with mixed results, there appears to be no right or wrong formula here.

The one concept I think - and it's only a theory - is that you need to at times stop fighting the code and give enough time for the healer (UX/UI) person to catch their breath, to drink some mana potions if you will to figure out how to navigate the next fight.

Lost in my metaphor?

What I am trying to say is that UX/UI in a sprint equation needs to occur every other sprint, meaning at some point in the process you need to arrive at a point in time where you the coders will have to refactor your UI / UX to accommodate the new direction in the design.

It sux.

It is however, the realistic way to accommodate the reactive design you have put in place and to be clear it has little return in investment other than user efficiency and satisfaction levels.

Now comes the question - how much do you invest in a pixel?

Answer that and you will have a better understanding of Agile, UI/UX + Code than I currently have.  As you now need to think in terms of how it all comes together and what value you place on the UI/UX component. Agile won’t necessary work in the way you think when it comes to intgerating your healer (UX/UI Person) into your battle group. At times you may not need them – that is until your hitting a wall and soon realize it would have been better to have them at the start of the fight vs end.

I can think of some rebuttals here - 'well you are doing agile wrong' or 'your team sounds like it wasn't assembled correctly' to which I simply respond - welcome to reality. Sometimes you have to play the game with a randomly aggregated team and it is not always a case of Greenfield project management.

Now, your move, how do you accommodate these variables.

Related Posts:

  • Jak

    Interesting, but I’m not sure I see how your version would be different to “Change the XYZ Button to be a Scrolling Overlay Whizzo Wheel” as a feature, along with a card for it, a time for the devs to incorporate it, then the UX guys take it to users for testing and put feedback in as a new story “Scrolling Overlay Whizzo Wheel needs to be slowed down to half speed”

  • @ Jak: Not saying that’s not doable, what if you need to re-factor the navigation or adjust the entire screen composition. More so, what if you need to take a screen and make it into multiple screens which then have impacts on not just validation (semantics) but also creates a massive ripple in your re-factoring – sure everything can be re-factored but it’s not about whether or not it’s technically possible. It’s more to do with with is it economically feasible.

    What if you’re in the last sprint and i say “We need to re-factor the entire project to accommodate the branding” – Assuming the person(s) funding the project approve of it now comes the wrestling match around how does one navigate this – nobody likes to go over already laid roads.

    There’s a number of scenarios you can throw at this equation and all are fixable if you have the luxury of both time and money. Just like in my game metaphor, you can always close that match and re-open a new one this time with same people but different approaches so in the end its really down to the core component of – how much is planned upfront vs how much you just adapt as each decision you make has consequences.

    Standing on the sidelines and pointing “ahh, you’re doing it wrong” seems to happen more so than ever in this space but i’m really confused as to who’s doing it right? I’ve seen both successful and failed projects and I can’t honestly say either did it right or wrong πŸ™‚

    I do know – me the healer – gets called in after the fact and some how i’m often expected to raise the dead (ie bringing in the UI/UX person last sagas…when in reality costs could of been severly reduced had the equation be adaptable enough to cope with a little bit of waterfall mixed with agile…*gasp*…i said the W word…)

  • Jak

    Nooooo you’re doing Agile wrong …. πŸ˜‰

    Well actually, you aren’t – but they are πŸ™‚

    Look, even in Agile, the rule is not “no upfront design” but is “as much upfront design as is required”

    Coders write code (or they should) to allow for change.

    If you decide to revamp the UI on day 80 of a 90 day project and the dev team say “thats 60 days work” then either they didn’t write very good code, or your changes are really fundamentally radical. If you want a total revamp and they say it’s 10 days work, now you have a negotiation and priority issue for the product owner – do they want the amazing new UI concept, do they want the other features on their backlog, or dod they want to slip the time schedule

    And why didn’t the UX person on week 4 of delivery find out the UI was fundamentally broken by testing and have his revisions incorporated into every feature afterwards?

    You seem to see UX as “special”, and honestly, it isn’t – it’s exactly the same problem as “architects” have had to deal with with Agile – you make smart decisions up front, you test and fail fast, you adapt as you go, you design for change.

    An architect under Agile may choose SQL Server – he has done his basic research, understands his product pretty well, and has a fair idea that SQL Server does the job. Four weeks in, the dev feedback is that the relational model isn’t matching what the business is telling them about the system model and they are suffering friction. The architect goes off, does some re-evaluation and decides that a document database is better suited.

    Did the architect get it wrong? Sure he did.
    Did he adapt when he say the problem? Sure he did.
    Did it cost the team a lot of time to switch halfway through a project? Yep, a lot.
    Would it have been better to figure that problem out up front? Yep absolutely

    How could that have been mitigated?

    Better requirements gathering, spiking risky parts early, getting better feedback to the designs early, and experience.

    All of which is identical to the UX problem …

    Understand your users early on and understand the problem they have, provide mock ups, sketches, prototypes, get user and stakeholder feedback, and go with what experience tells you is best

    Would it be better solved with up front design – sure to a point – but at some point you move beyond theoretical and move into implementation. At that point you have to iterate.

    Performance, feedback, revision

    You do as much up front design (UX or Software) as is appropriate – then you iterate.

    You build and design for change – the ONLY certainty is change

    You build and design to mitigate known risks

    You build and design being mindful of unknown risks.

    But non of that is anti-Agile – it just reinforces the case for Agile.