RedUX : Measure twice, cut once… : UX Patterns
For many years I’ve looked at how some teams in the enterprise do “Agile”, and smugly thought to myself, that’s not Agile, that’s short cycles of Waterfall.
Actually I am not alone in this belief, because there are names for it…Agile-Fall, or Water-Scrum-Fall, or… you get it.
The reason I feel this way, is because I’ve worked for many years to integrate UX practices into the Agile cycle, and I’m pretty familiar with how that cycle is actually implemented. Especially in the enterprise. Prior to my UX life, I wrote code, so I’m familiar with that side of the cycle as well.
One of the standards by which I measure “Agile-ness” is a statement I heard a few years back…”If you are not throwing away code, you are not iterating.” This had the ring of truth to me, and I’ve always applied it in my assessments of just how Agile a team may be. Of course when I ask teams… “How much code have you thrown away?”… I am often met with blank stares. Sometimes I get statements like “Developers are expensive, why would we spend time re-writing working code?” or “We decided it was more important to get to the next feature than to refactor.”
I’ve never been an “Alpha-Coder”, you know, someone who delights in abstracting code to the point where its no longer readable. Or someone who gets wound up about a wonderfully obscure Regex expression. Meh. I’m the guy that would say, it works, lets move on.
My viewpoint changed when I moved into UX. No longer am I of the “good enough” crowd. No longer am I satisfied with a UI that works, but does not delight the user. I’m a zealot now, an “Alpha-Designer”. I want to delight and empower users with my designs.
But… the same thing applies to design that it does to code. Iteration is a must! Designs must be evaluated, discarded, revised, re-started, etc. So the same measure applies…”If I am not throwing away designs, I am not iterating.”
So “Whats the difference?” you ask?
It’s a difference of cost. Coding is expensive, especially in the Water-Scrum-Fall world. Using coder time to create features that a user may reject, is horribly expensive. Embedding a UX Designer streamlines the iteration process. Iterating a design in the mockup phase is much cheaper than throwing away code. We are still iterating, we’re just doing it more efficiently.
Its the old “Measure Twice, cut once.” maxim in action. In the software development sense, the UX Designer is doing the “measuring” and doing it twice ( or more ). The coding team is then free to just “cut” once. This reduces code waste, delivers an iterated product, and does so on a quicker timeline.
Don’t get me wrong, code will still need to be thrown away, but it will be for good reasons… maybe something worthy…like more abstraction.
Oddly some of my favorite contributions as a UX Practitioner are not the designs that went on to become features, but the designs that caused features to not be developed at all. This may sound a little disingenuous at first read, but think of it this way… if I can help the customer to see that a feature is un-needed, I can eliminate that feature from the backlog for the entire team. For the entire team…
That’s right, I’m not just improving efficiency, I’m multiplying it.