You wouldn’t know it if you talked to me now, but I was a little late to the lean UX bandwagon. I was by no means an immediate convert. If you’re still wondering what the hub-bub is all about, maybe my not-so-straight journey can fill you in.
Setting the stage
When the concept of lean UX was picking up steam in the design world, I worked in an environment that was about as not-lean as you can get. I worked on a 100-person team distributed across 2 locations and time zones, making software for the Army. So to paint a better picture for you: take the slowness of enterprise software, multiply that by government bureaucracy, add a dash of molasses, and you’d have us.
OK, OK, I’m exaggerating, it wasn’t that bad. Just trying to get your attention. 😉
I worked with immensely talented people who strove to be as fast and efficient as possible while also providing the reliable quality and sound engineering that such an important and potentially risky endeavor deserves. I’m incredibly lucky to have worked with them all.
However, we were far from the type of environment where lean UX grows wild. Just being distributed can be a huge barrier for any team, and we also had extra practical concerns to handle in security, deployment, and more.
But I neeeeed my deliverables
Our design team had spent several years making progress for design in our organization. We’d been working hard at wiggling our little tentacles into all the nooks and crannies of the software process. (It was not quite waterfall, but not agile either in those days—more like a spiral process. But I digress.)
A huge part of that progress was made on the back of deliverables. Our documents meant different things to different teams, but they became valued by developers, testers, project managers, and even made their way into customer presentations. Part of this was also the maturing of our design group itself, as we got better at communicating our ideas to larger groups and selling them more effectively. As the deliverables became more valued, they also got heavier and heavier. People started wanting them to serve other purposes of comprehensive documentation or roadmapping. They were always a work in progress, but they served a vital purpose nonetheless.
So when coworkers started talking about lean UX, and its somewhat “f@$k deliverables” attitude (at least on a superficial level), I was quite the skeptic. Here is the classic Smashing Magazine article our team initially read on the subject. If someone had been trying to sell me on it, this wouldn’t have been the sales pitch to pick for me at that moment. I thought of our deliverables as the currency of collaboration. I absolutely positively hate it when people are ignored or left out, particularly developers or teams in another location. As designers and people who prize empathy so highly, we have to remember to have empathy for our coworkers, too. (If you can’t tell, this was—and is—a bit of a passion of mine.) I felt strongly that to abandon deliverables and replace them with nothing would only result in a lot of confusion, poor communication, and people being left out.
Ironically, the very reason I clung to deliverables was also one of the reasons Lean UX wanted to throw them away. I was already in a lean UX mindset, caring passionately about interdisciplinary collaboration, but I didn’t know it yet.
Ultimately, the focus on abandoning deliverables combined with the buzzwords and hype turned me off. The suggestion to move away from deliverables and make more prototypes made it initially inaccessible to me. Our software was written in Java, and getting prototyping hours approved could sometimes be a laborious process. We also had heavily drag-and-drop, unstructured software—not something that can be easily prototyped in any of the commonly available frameworks. Anyone advising me to abandon the very thing that had helped us make so much progress seemed impractical to say the least.
I completely blew it off as another superficial fad. I would later learn that the deliverables I clung to weren’t quite as important as I thought and that they could be lighter weight and still do their job. I also later learned that practicing lean didn’t have to be quite as dogmatic as I might have thought. I still think “deliverables” are important. I highly recommend writing your thoughts and rationale down. Next week when you totally forget what you were thinking right now, it saves you time if you have jotted down a few simple notes (as long as you haven’t authored a 300 page novel for one screen). Also specifically in the case of distributed teams, having something to reference when you might not be at work (or might be asleep!) can be valuable and worth it. I have just expanded my definition of what a deliverable can be to something a lot more lightweight and simplified.
Back to our story. Time passed.
The book Lean UX was published. A friend read it, curious about the hype, and felt kind of neutral about it. She liked it, but didn’t change much in her practice as a result.
I figured it was a trend that would come and go in my life.
LITTLE DID I KNOW.
Meanwhile… I had been educating myself on a variety of business topics for a while, as I have an irrepressible entrepreneurial streak. It occurred to me one day, that although I was surrounded by people who used the term “MVP”—or minimum viable product—I didn’t really know that much about the concept. I was pretty sure those around me didn’t understand it either. I felt like I understood. I had used the term for at least two years at that point. The words had seemed so initially smart, but also intuitively clear. I guess I thought I understood it the moment I first heard it. (I actually had no clue. In hindsight, I can’t believe how long I used this word with no idea of its origin.)
Again—little did I know….
A fateful internet search
For some reason that day, I decided to google “MVP” to see if I could learn something more about how exactly to make such a thing.
What a fateful internet search. It changed the course of my life and all my thinking thereafter. Honestly, I’m not overdramatizing. The first thing I watched was this video:
I have no idea how this video was the first one I found, but it was the perfect one—a very early (and old) one that discussed some of the exact problems I was facing.
And then this one:
^^^^ If you’re only going to watch one video today, let it be this one. ^^^^
If I could force everyone I ever work with to watch this video, I would do it. (I try. 25% success rate, I’d estimate.)
*Ding!* New zealot created
It was like someone had turned the light on in a room I hadn’t realized was dark. I had to know more. I was a creature obsessed.
I spent a lot of money on books, and enjoyed every penny of it. I devoured The Lean Startup, and suddenly saw beyond the hype. Before I was even finished with it, I had ordered three more lean books.
(As an aside, someone could have predicted this. I probably should have seen it coming. My mom, who I highly respect and admire, has been a coach of lean manufacturing for thirty years, and frequently talks with me about her work. Apparently lean is in the blood.)
Before I get back to lean UX, the reason I say this was life-changing is because ultimately I ended up later quitting my job. I set up shop as my own business to work on my own products and business models—this website being one of several—all with lean startup concepts and thinking as the foundation.
A return to lean UX with a new perspective
The second lean book I ordered was of course Lean UX. I decided I was wrong to have brushed something off without having really understood it and read the book myself. I gobbled it up in a few days, and while I was stirred and inspired by the interdisciplinary thinking and agile ways… I still didn’t yet see where to go from there or how to fit it into my current practice at my job.
I liked it, but I didn’t immediately change anything. I kept finding myself thinking as I read, of course this is the right way to do things! Of course! That’s what I’m already doing.
And yet.
It wasn’t. I began to catch myself.
Gradually I noticed some parts of my process weren’t as inclusive or interdisciplinary as I thought. I had fallen into a habit of practice that was easiest and most efficient for me, but was not necessarily the best. (In particular, it can seem so much easier to design things independently and then share ideas with the team, rather than taking the time to come up with ideas together.)
My first baby steps
So when I started on a new project, with a project manager that was a fan of lean and learning new best practices, I was determined to force myself to do the exercises step by step as the book described. If only as an experiment, getting in the spirit of things!
I started with personas, collaborating on the fly with our client. I didn’t do it quite like the book suggested, partly because I adjusted on the fly and partly because I was new to the process. (But perhaps that’s what lean UX would advise doing anyway.) However, my first lean UX experiment was exhilarating. As I sketched a stick figure with a sharpie and started jotting down notes, clients jumped in with details, decking him out with accessories, beads of sweat, likely foods he would be eating, that all informed my understanding in a way I would have never gotten using my old methods.
It was a good early win. I was determined to keep going. It was exhilarating and addicting.
Next I graduated to a design studio with our team, a friendly, jovial, excited bunch that was an easy audience. It was still a little scary/awkward/uncomfortable initially, but the results were worth it. They were two-fold:
- A diversity of ideas generated that were all quite good
- A much deeper buy-in and cohesiveness on the team in general
It was like an engraved invitation to work together as a team on the design, and beyond.
Here are some great links on doing design studio workshops if you’re looking for more details beyond the book.
- Design Studio Workshop: Adding Up the Benefits by Jared Spool at User Interface Engineering
- Design Studios: The Good, the Bad, and the Science by Jim Lindstrom on UX Booth
- How to Run a Design Studio in 90 Minutes or Less by Al Abut from Zapier
What’s all this add up to?
I thought my journey would interest some people because it was not an immediate understanding, but a much more roundabout process. And yet in the end, lean ux and lean startup have become something I am very passionate about.
So if you are still a skeptic, I encourage you to maybe take a second, deeper look. You can start small, or start big. Not every practice might make sense for your team and your situation—but I’d encourage you to try things out, if possible, before you decide. Just as in user research, it’s always better to experiment and find out directly for sure, than to try to decide in the ivory towers of our minds.
I also share this because, no matter how good of a job Jeff could do writing Lean UX, I had to do the work to get the benefit. I had to be ready for it. I had to try. I had to do some soul searching. I had to apply the ideas in real life before I really came around. So I also share my experience, because maybe you like me moved on, and didn’t quite come back to it, or didn’t have fateful google search that led to a lean obsession, or you have just forgotten about it. This is my moment to say—dig deeper. It’s worth it.
Going further
There are a thousand places you could start, so I’ll try to only pick out a few of the my favorites. There’s tons more info on my Resources page.
- First of all, read the book if you haven’t already: Lean UX.
- I also would highly recommend: UX for Lean Startups.
- You might consider starting as I did with The Lean Startup.
- If this all sounds interesting to you, you might also consider checking out the Balanced Team movement.
