I’ve not decided yes or no on that question, I’ve read a lot in the past few months on the topic and I’m still not convinced or swayed either way.
Here’s my open transparent written exploration of how I am navigating this concept.
UX Design vs UI Design.
Its important to split a hair on this one, UI Designer in my definition is someone who can work on the aesthetics of a component whilst a UX Designer is the one who contemplates how that component is to be used by humans (I could go much deeper in this topic but another blog post for another day?)
I state this concept out loud, as when I read success on how UX + Agile came together in XYZ team, I often question what they are measuring success in terms of UX and more to the point what disciplines were in the room and what were the problems being solved. I’ve not read a lot about how the sausage was made, its more “trust me, UX + Agile works” belief system which to me is simply not scientific enough to subscribe to. I need proof of life.
The UX Scouting Model.
There’s a number of articles written on this, but for me I call it the UX Scouting model, whereby you have a set of effort that works ahead of a sprint, its the type of work that solves the problems of UX before the engineers arrive at a point in time to start assembling.
On paper, this seems like a reasonable approach to the problem of dealing with iterative design, and I’m inclined to believe this is probably the only model I can think of that will yield a successful shipping cycle. Having said that, i think this kind of model is more suited towards a validation / mentoring of UX model than an UX problem solving exercise.
What do i mean?
I put it to all that what is occurring is a reactive iteration occurring on the software whereby you’re taking a slice of the feature catalogue and reacting to how it injects itself both technically and visually into place. This is where I think the failure points occur, as its where a seasoned UX Designer shows his/her skill set the most. The ability to foresee what’s next beyond the current iterations (ie sprint) and are also trying to forecast the next few moves ahead (heh maybe a good interview technique for a UX expert is to play chess with them).
Having this foresight is in my opinion a very rare amount of talent to have, and once that person(s) have this, getting them to also negotiate with both stakeholders and engineers on such direction could also reduce the skill pool down even further. It doesn’t stop there, as at times the engineering side of the fence line aren’t open to adjustments in thinking, as it means more time/cost to them and the project. It’s then you face the compromise concern, as once that card gets thrown into the room, its easy to bias the stakeholders or owners of the said software to side with an efficient release over an effective one.
It’s how a lot of software ends up with a degree of “false affordance” – meaning, you get packets of the software where it has a perceived level of functionality that does what it’s expected to do, but in the end it either goes un-used or un-noticed or even more so, it’s sole purpose is to placate the end user and stake holders into believing the problem was solved.
Let’s get it right next time?
Historically, Microsoft as a company has always duke it out over the battle between function vs form, and all to often function has won out in the end – despite the highly paid talent of UX leads being in the room. The stark reality is that time/cost are a factor one cannot simply deny, and its essentially what makes UX + Agile an attractive proposition, as it means get it done, get it done early and you can always get it right in the next release.
Microsoft typically takes three shipping cycles to get it right, when I say right, I mean “good enough” which in many ways is the ready, fire, aim approach. Apple at times seem to approach the equation from a ready, aim, fire model.
They don’t always get it right, but the amount of “luck” Apple have had with their product lines over the years, can lend itself to the concept that maybe they are siding with Form over Function every time. The company presents itself as being more about the industrial design of the solutions vs the good enough approach and it probably is why they often lead with a linear model of development + release.
Does UX + Agile work inside Apple? I don’t know, I can speculate that probably it doesn’t and that the engineering side of things makes way for UX – ie Function follows Form.
Back to the point, UX + Agile is sometimes hidden under the covers of evolution, whereby the said persons can run parallel or ahead of the said development teams and are able to react according to the growth of the said feature(s). However, when the time comes for a UX refactor, does it not get pushed aside into the next major release cycle with an open promise to get it right then.
If that does occur, then is that cycle dedicated to UX refactor in its purist sense? or is it just the same rinse/repeat formula whereby you have an iterative situation unfolding.
So, UX + Agile isn’t the answer?
I think the concept of Agile is fine, its the execution of it that I think is where the story kind of starts to fall a little to the way side, I think from a UX standpoint you really need to outline the features ahead but do so in a way that is suited to a ready, aim, fire model. It also needs to lend itself to a dedicated chunk of time purely to refactor the function of a solution to accommodate the consistency and goals of form. Having said that, that “Form” needs to be defined early and it needs to be framed in a way that everyone involved can subscribe to easily enough (heh, the joke is on the UX itself, as in order to sell everyone on the UX vision, they in turn need to ensure its palatable enough for them to recall, thus UX sells UX ..funny)
I’ve not decided as yet that UX + Agile is a formula that works, I can’t decide that just yet as I feel we in the software industry are back to pioneering mode. We settled on a rinse/repeat formula for so long that it started to breed mediocrity in the way software is designed, developed and deployed. Given the device market has created an interesting interruption in the way we approach mundane tasks, it in itself has elevated the B2C or B2B markets in a way that forces the ideation phase of software to take more risks.
The problem isn’t with the ideation being unwieldy or requiring strict time boxing, it’s simply we may have all forgotten to add the UX tax to the software builds – meaning, costs just increased.
Cost increases aren’t swallowed well, so the reality is what is likely occurring in UX + Agile teams is that there is more of a UI Designer validating and placating the said engineering side with “Good job, keep using DataGrids” mentality vs.. a UX Designer asking that folks think differently and outside the box.
On paper, agile is fine. In practice, well, grab your UX six shooter and lets ride off into the west and see what we find out next.