Is UX a waste of time? The Final Chapter

*Spoiler alert – it’s not. But there are some stuff we need to fix.

Issue 3 – ‘That’s Agile, baby’

Agile. Stupid Agile. This is where I lose the Agile Evangelists.

Fact is, Agile is great for clients. It’s great for PMs, and the wider company image to show that “we’re human, we all make mistakes, let’s figure it out”.

And actual ‘real’ coding development works well when Agile methodology is managed right – with a strong team – although it’s got to be said a little better on the Back End side.

Still, there’s nothing more heart breaking for any developer when you’ve poured your heart and soul into something and gone the extra mile burning the midnight candle (and, let’s be honest, we all want the world to be amazed at our work), only to be told someone has changed their mind. And your work will be scrapped. But thanks for the effort anyway.

‘That’s Agile, baby.’

But where Agile takes a sly kidney punch when the referee isn’t looking is in the “post UX” phase where UX changes are requested, and is our final ‘big issue’ with modern UX these days.

Late to the party

By definition (yes, we’ve all read the Manifesto … from good old 2001 – and great to see they really put a lot of effort into the site design! – http://agilemanifesto.org/principles.html), Agile not only allows change but promotes it. “Welcome changing requirements, even late in development”

I’m on board with that, there’s nothing worse I imagine for a manager who takes over a new role and a car-crash of a project, to see it’s all going down the pan. Time to reign in that bad boy. Swap that custom-made parallax slideshow in checkout for something more useful instead.

But … wait a second, I was too busy nodding at the broader manifesto points …. did they really just say ‘…even late in development’?! What on earth?! Who are these crazy old guys?

So where does this all sit with wireframing?

For most of us, “Agile” is another word for “Change”.

In an ideal world, the plan we all signed up for would be:

1. wireframes are agreed upon – the meat & 2 veg of our UX world;
2. UI designers (or moonlighting UX’ers) jimmy them up into high fidelity designs.
3. BA’s and Tech Leads consult the designs, break them down where possible, and assign story points against the various tasks.
4. Front end and Back end work is started, to work around each other, then tested, rinse and repeat.
5. Everyone is happy.

But what happens during the development phase if someone on the client side has a change of heart, and changes the wireframe? This is the million-dollar question.

I’ve seen the drama (and sometimes ‘carnage’) from both potential outcomes. Either it’s fair on the design company, or the dice rolls on the side of the client. Either development work is still carried out, tested, and points backed by the design company – even though the work is not needed anymore and the client isn’t happy.

Or, development work is suddenly stopped, and any dev points ‘in limbo’ on that task are lost forever. The company is at a loss, and work is started all over again on that task (in the hope that this one is going to stick).

In an ideal world, design changes would be made at the wireframe level before they are ‘signed off’. Or tasks would be so granular and so miniscule that’s it’s not a major setback. Or signed-off stories currently in the Sprint would be honoured.

But that’s not always feasible. Some tasks do need to be a 13 or 20ptr.

To meet deadlines, wireframes can be quickly pushed out the door as it’s difficult for some dinosaurs to see “the bigger picture” of what it would look like when “live”. Radical changes to stories in workshops can derail BA’s time (but maybe they secretly enjoy the drama, so that’s not an issue!), so everyone is on a potential for a hiding.

“I think a change, a change, would do you good”

With UX, maybe change isn’t always a good thing.

But what’s the alternative? 1990s ‘Last of the Mohicans’ Waterfall? Well, shocker, on some levels, maybe yes. http://www.base36.com/2012/12/agile-waterfall-methodologies-a-side-by-side-comparison/

Waterfall flows rigidly through the 8 steps to clean living. When a step is done, everyone gets a pat on the back, it’s signed-sealed-delivered, and on to the next one. Change? Forget it. But the client knows what they’ll get. The company knows they’ll get paid to deliver what the client wants. Timelines? Yep, we can stick to them because some dude won’t come along and throw a spanner in the works.

“Woah, woah, woah – so you’re saying Waterfall is better??” Yes. For the UX to FE/BE Transition Phase.

But I’m current, I’m hip. Agile is like a religion to some, but there’ll be some “Nimble Water” (copyright Jordan Taylor sometime in 2017) 2.0 methodology around at some point that combines the best of both worlds, so I’ll just wait for that and jump on the bandwagon. Might even go to a Nimble Water meet-up. Agile fans do like their meet-ups. And it’s always good to be in with the popular crowd.

Don’t believe me? Work as a Front End developer on a major project with a client who can’t make their mind up with wireframes, and you might change your mind.

And it’s the poor UX’rs who get it in the neck from all angles as they’re the ones who came up with the wireframes in the first place.

But what can we do to stop it happening?

• Better, more interactive prototypes – forget lo-fi mock-ups, if you have a Chief who “wants to test the water before they agree to something”, fire up your Axure skills and show them what it’ll look like.
• Improve channels of communication – grab time from decision makers. Physically. Tie their shoe laces together, and a few times around the chair legs for good measure.
• Offer a choice – where usually this is a bad thing, when working under a board of decision makers, two paths can help ideas to stick. Decision makers back their horse (people love being in control, even from just a simple AB decision), and at worst they’ll usually fall back to Plan B. If BA’s are warned in advance, a switch doesn’t always mean tears and going back to the drawing board.

Or, if nothing works, jack it all in and go rogue (a.k.a freelance)! It’ll only get worse on the project you’re stuck on!

If you’re a good UX’r I’d love to hear from you, there’s plenty of opportunities out there where your skills will be appreciated.

Missed the earlier two articles? Catch them here.

Is UX a waste of Time – https://www.linkedin.com/pulse/ux-waste-time-jordan-taylor

And Part Two – https://www.linkedin.com/pulse/ux-waste-time-part-two-jordan-taylor

That’s all for this series. We’re taking a break from UX and by popular demand watch out for “I learnt the secrets of marketing from an episode of Spongebob Squarepants” – I promise, it’s a good one! Coming soon!

—

Jordan Taylor has been developing websites since he started using Dreamweaver way back when it was in version 3 (yes, that far back) and everyone loved tables. He has worked on UX and Front End projects for many global ecommerce projects including Gucci.com, Superdrug and Dr Martens (and a few others where the UX management was not so good!). He is currently a UX Architect on a major SaaS development project, and the lead on an NDA-driven Front End only team of stealthy ninjas for high end “on shore” Hybris and Demandware projects, called Rapid Commerce.