Every so often I find myself in a conversation with someone who wants to put UX design into a typical agile or scrum process together with the engineering team, and if they are religious about agile workflows, sometimes it even becomes an argument.

Now, before we start, it’s worth mentioning that I am not talking about “design sprints” here. Google (and others) published books about doing design in goal-oriented chunks and it’s not the same as doing code in sprints.

I am talking about taking your agile development workflow, which was intended for coders, and forcing your designers to work the same way.

I am talking about breaking your UX design into small task-based stories (tasks for the designer, not the user!), with concrete estimates about how long it will take, and keeping track of your burndown rate or whatever.

I have never seen it work… for the designers. Because UX work — not UI work! — is not like code, no matter how much you want it to be. There are always unknowns: users.

Unless you have a few hundred users in the room with you, the whole time you’re designing, you have to interpret their needs, wants, motivations, interpretations, and behavior.

Computers don’t have opinions about your code.

Computers don’t give up if they are in a bad mood.

You don’t have to interview computers to find bugs.

You will never launch your code because it looks good, only to find that your computer gets confused half way through. (I really HOPE nobody ever does that…)

You never get documentation that tells you two opposite answers for the same question.

You never start writing code without knowing what the computer wants to do with it.

You never meet computers that only speak languages you don’t know.

You never code for computers that have 15 other tabs open, drink craft beer, and who still believe that vinyl albums are inherently better than digital recordings.

Two different computers will never run the same code and produce different results just because they grew up in different cultures and one of them feels disrespected by your choice of variable names.

****

Agile wasn’t made for code. It was made for coders.

And it seems to work pretty well! I have nothing against it, believe it or not! Most of my jobs have used some form of that process, and if it works for the dev team, then I am all for it!

And for the record — which should obviously be recorded on vinyl, otherwise that record would just lose it’s humanity, you know? — I am not talking about “lean” or any similar approach to iterative design. That is also a big confusion about “agile” when it comes to design.

You can approach design with a lean, MVP-focused, research-driven, iterative mentality without going anywhere near an agile/scrum workflow. Let’s keep those ideas separate.

For some reason, people think that agile workflows either work for everything in life, or you just don’t understand it. But that’s a religion, not a method. You’re not religious about agile development, are you?!

In the same way that proper UX process is not going to help your code very much, a proper development process is not going to help your UX very much.

There are plenty of unknowns in code, and there are plenty of creative and unpredictable things, and UX and code effect each other if your team knows what they are doing… but the huge difference is: code isn’t for users.

(At this point, you may be tempted to think that I don’t understand how good code can be much more usable for other developers. If so, you have just missed the point…)

Processes and workflows designed to make coders work better are all about the coders.

Processes and workflows designed to make users work better are all about the users.

Huge difference. You know what the code should do, you know how the computer will use it, and you know, immediately, when it works.

None of that is true for users.

****

UX never “works”.

If someone asked me if the winning design of an A/B test “worked”… I wouldn’t know what to say, except “for some users, yeah.”

If you ask a coder if their code works, they can say “yes” or “not yet”.

Give your mind a second to chew on that. UX can only increase or decrease the probability of success. That’s a fundamental difference between computers and people.

There is no such thing as a design that works for 100% of users. Even a one-page site, that has one huge, clear button in it, with big red arrows pointing to it, and a label that says “click this or we kill your family”, with a video of a terrorist holding your family hostage, will have a bounce rate higher than zero with a decent amount of traffic.

But if code doesn’t work for 100% of the computers it was made for, then you might have a big problem (or you’re dealing with Internet Explorer, but that’s an article for another day…)

When was the last time you wrote code by getting people from outside the company to help you gather ideas? Every developer should shiver at the thought.

The only thing that makes your designs better is understanding your users, measuring things in the real world, and knowing that you will launch things — often — that don’t “work”.

Even Google’s design sprints can produce designs that are terrible. And unlike agile and scrum, design sprints were made for design.

A good UX process is not just about how efficiently you work, or how well your team works together. A good UX process is about how well you solve user problems and business problems.

How would your coding workflow look if your goal was deep understanding rather than efficient delivery? If the “research phase” of developing a new feature was 90% of the work, every time…

Would you choose agile?