Learning UX in a Lean Environment Part 2: The Journey Not the Destination
Guest post by: Kofi Aidoo, Intern
Author Greg Anderson said “Focus on the journey, not the destination. Joy is found not in finishing an activity but in doing it.”
As I sit back in my Brooklyn abode and reflect on my last 3 months at The Starter League (TSL), an independent “school” that teaches entrepreneurs and enthusiasts the technical skills to venture forth with their own ideas or for some like me make a change in their career, it’s this quote that comes to mind.
In my last post I was adapting to Learning UX in a lean environment. Today I will wrap up my experiences and learnings in my final 6-7 weeks as I tried to maximize my learning while building my own application.
Here’s what I learned:
#1 – Always make time for others! This is the most important thing that I learned. While battling it out over the last few weeks I hit a few roadblocks both as an individual and also within the confines of the team. Help always came from one of 2 colleagues in the web development class and UX classes. One of them was basically at TSL to build his business back in his native country and had little time for deviation, the other was still working remotely and had other deadlines besides his 3x a week class. Both were technically advanced and really understood backend development as well as front end design. They would spend the time to review concepts or explain html and it was humbling. So take the time to help. You will benefit from the learning and camaraderie that develops.
#2 – User Stories are key. User stories are quick ways to put features into sentence form. Each sentence places the feature in context with the user. At TSL there were a few conversations where developers were dismissive of the need for UX in the development of an idea. Many didn’t see the need. Yet they were still dependent on a UX tool in order to develop their ideas. Developers were taught the value of user stories and the development of good user stories in order to know what to build both for a Minimal Viable Product, as well as, for the whole system. It was refreshing to hear the developers I was working with demand User stories and want to work through the research and process to refine them even more. Demonstrating the value of UX to developers in such a simple term as the User Story is a good way to bridge the gap between front end backend.
#3 – Understand all your technical limitations from the beginning. When I decided to build my application I was fortunate enough to find 2 very competent developers who wanted to be part of the process. They understood the value of UX, and, as I said in the paragraph above, were even involved in the process of defining the MVP and user stories from the beginning. Yet all was not smooth sailing. Having defined the MVP and even going through a wireframing session with them on whiteboard, my other UX/HTML teammate and I began to build the frontend from scratch using our own html and css that we had defined. Yet when it came time to integrate front end with backend (or so we thought) actually doing so was not as simple. Our ground up html didn’t mesh with their template based system and it would take too long to integrate. So in the end we had to rebuild our html to make it easier for the devs to integrate the product which,with the time left, meant we didn’t “finish” the MVP by the end of the program. Still 3 of 4 of us are committed to continuing on the project and it feels like an exciting beginning.
Finally, the biggest lesson I learned from the whole program is that UX is NOT, I repeat, NOT a lean process. It takes time. Everyone wants to move fast and iterate quickly, but we still need to reference good solid research. The best ideas address a witnessed or experienced user need. A properly researched and wisely applied strategy will uncover the breadth of your user needs. It will also reveal other exploitable areas. This requires time spent with the users and the data to produce the right insights. The UX process can be used to inject momentum into a multi-stage agile development process and when done so can be very beneficial. But an agile UX process seems to be self defeating and limits the strength and power of the output from UX work. Can the UX process be aligned with a good research strategy to support a lean and agile development? I would say yes. But, can an agile process replace a good research strategy, I would say no.
Like all journeys my time at TSL was not as straightforward as I would have liked but in the end I will say the experience was definitely more than worthwhile and I would recommend the Starter League to anyone who wants to dedicate the time to learn in a welcoming, active environment. I’ve been given the feeling that I know and understand UX much better, but I still have a lot more learning to do. Thankfully I now have the confidence to go learn anything whether it be HTML and CSS, visual design or even J-Query. And that has, more than anything, been the greatest value of this experience.