Lean Discovery Series
A junior UX Designer’s accounts of a better discovery process
Foreword
It has been a little over 5 months since I started working as a UX designer at MAQE and one of the projects, of which I have been part of since the very beginning, has come to an end. This being my first time working within a web development team, I’m not sure if I can judge how well the project had been progressing, however based on the positive feedback we kept getting from our clients and the ever dwindling tickets on our Kanban board, I’d say that we had been doing something right. But what the hell was it?

Making software is hard
It’s not easy to finish a software or web development project, let alone in a way that leaves the client happy and wanting to bring in more work. According to The Standish Group’s CHAOS Manifesto 2013, 60% of all software projects fail. They didn’t deliver what the client wanted, went over budget, were delayed or never saw the light of day. I had my own fair share of failures in my freelance career working as a web and graphic designer. And when I compare those failures to the successes like this project, there are many issues in common that contribute to what makes or breaks a project and all point to one thing: The Discovery Process.

My Introduction to Lean Discovery
When I moved back to Bangkok in January 2015, after working as a freelance designer in the UK and Germany, I didn’t expect much from the creative industry in a country, where the majority of people valued design merely as a means to make products and services more visually appealing. At least that was what I remembered, when I left Thailand seven years ago.
I had just found my footing in the city, when I chose to attend a panel discussion, organised by the BKK Web meetup group, about web proposal best practices, that would profoundly change my view of design in Thailand. What started off as any other tech talk, became suddenly much more compelling the moment this guy from MAQE was weighing in about the importance of doing workshops with clients, approaching design as a problem solving tool and leveraging Lean methodology as part of something called Lean Discovery. I was all ears and caught myself ticking off points on an imaginary checklist in my mind. At the end of the presentation, I knew that I wanted to work there and learn about this Lean Discovery thing.

The Lean Discovery Series
Six months in and having gone through a number of Lean Discoveries, I feel that I am ready to share some of my first hand accounts, from the perspective of a budding junior UX designer, who is just getting to learn and apply Lean Discovery as well as leveraging its many tools, techniques and social technologies to improve the way a web development project is done. In essence Lean Discovery is a five day workshop, where we work closely with clients to properly nail down what they want us to design and develop, all with the end user in mind. This is done by collaboratively exploring problems and designing solutions in forms of prototypes that we get to test on real users. The outcomes of the tests are then evaluated in order to prepare better proposals and requirements for a project that truly addresses the right problems.

However, in the spirit of Agile software development, I want to break things up a bit and cover each lesson I have taken away from this experience in more depth as part of the Lean Discovery Series, starting with: Understanding Your Client