Why do developers dream about UX sheep?

I woke from an interesting dream the other morning.

I was in a theatre for a conference of some type and this hard core developer comes up and asks me to tell him and his team about our approach. So, I walk up the steps to this group of hard-core coders, three very experienced guys, arms crossed. Their body language made it clear that their expectations were pretty low.

So I start by saying, “some people call it visualization, others prototyping, we just call it design” which elicited snorts of derision. “But we create usable prototypes to test with real users and real interactions” which led to more derisive comments on proprietary platforms that create inefficient code and waste.

Hold on a second. Let’s reimagine this within the framework of agile/scrum or lean. So I start over.

I say to them: Imagine in your agile environment, you can focus development on performance, security, data integrity and iterative improvement to the interface? Imagine that you could eliminate the risk that the product manager has focused too much on the buyer persona rather than the user persona? Imagine that you could have a scenario where the most important parts of the software always get built even if the team can’t agree on a way to split up that epic? Imagine a sprint kickoff where there are no discussions on the relative priorities of stories based on the development team’s perception of importance, but rather based on actual users spelling out their needs?

How about lean? How about a scenario where the product/market fit is validated with real potential users? Not the proxy of friends and family or other informal methodologies. How about a scenario where you can quickly build, test and iterate without coding? How about a scenario where you can do your initial concepting and vetting and pivoting, pre-alpha? Imagine that you could create a minimum “valuable” product on your first iteration instead of a “viable” product?

In both these frameworks, we take the iterative process of figuring out what users need and how to align that with business needs and raise it out of a strictly “development” process. It becomes “pre-development” (or a Sprint 0 if you prefer) instead of wasted cycles within the development effort.

“Great hypotheses, but how does this work in the real world?” you may ask. Over the years, we have fine-tuned this process working with many clients. It works on mega-projects and startup products. Projects come in on time, on budget and in scope. Want to learn more? Take a look at the case studies below.

Originally published August 17, 2015