From the beginning Agile has felt very developer-centered. Some major questions regarding the new roles of requirements, design and testers have been discussed as we are trying to find useful ways of working together. My experience with agile projects so far has been very differentiated. The key success factors for the projects I have been in are: working together, sitting together, delivering working functions every sprint, close collaboration with the users, developers that understand the idea of good enough coding and foremost the team spirit of doing things together. Unfortunately many so called agile projects still seem to be completely unaware of the core values of Agile - requirement analysts only changed their templates and now try to write complete requirements in a user story format - forgetting that every story is a promise of a conversation, interaction design and usability is regarded as cosmetics and therefore less important by project managers that think that everyone can design and developers that focus on the beauty of their code. this rant could go on ...
It is therefore very encouraging to dive into the book Lean UX by Jeff Gothelf and Josh Seiden which I think focus very much of the important core values of SW development namely to solve real problems for real customers by constant iteration and feedback. Here the interaction designers have given a lot of thought of how they can be of the best help for the team effort. This requires a mind-set where no heroes are allowed in the fairly common manner that one person comes in temporarily, solves a problem and then leaves. Instead the interaction designer is part of the team and acts more like a facilitator for the design effort. Certainly the skills and knowledge are used but more in a collaboratve way saying - I have a suggestion on how to solve this, let me show show you and then YOU can give your input so that we end up with a design that is accepted by all!
The pillars of Lean UX
The authors refer to three core processes that together support Lean UX. These are the Lean startup, agile development and design thinking. I have a hard time making a clear distincion between them as they share a lot of common ground. They are all highly iterative, focus on business value and collaboration. There are some core values of each that are emphasized for each core process.
- Lean Startup - we have an idea of what we want to build. This must solve some form of existing problem. Instead of spending loads of cash on building something we make an MVP - minimum viable product. It is iportant that the product is not only minimal but also viable - it is NOT about creating something crappy - rather to test a hypothesis we have.
- Agile development: working in small, collocated teams with much interaction with the customer, delivering working software in small increments that each focus on outcome - solving real problems.
- Design thinking: focus on solving prolems by suggesting solutions. Requires a user interface. We have an idea of what is the problem and design something that we think will solve it - then go out and get feedback from users. Analyse and then redesign and the process starts over.
The Lean UX process
Start by trying to understand what the problem is, make assumptions on what we need to solve. Then suggest ways of solving this by creating one or more prototypes. Also write down what signals you can get in order to validate or invalidate your assumptions.
In the beginning your prototype may be handdrawn on paper, later interactive in Balsamiq and to get close to reality a coded prototype maybe even with some real data in it. The important thing is that you have an MVP that actually works for getting feedback.
Now run experiments. This can be in the form of a landing page, a structured usability test, interviews, site analytics and more. The important thing is to know what you need to find out and to run experiments so those questions can be answered.
What Else?
There is a description of how to create and maintain a style guide which is good info for interaction designers. The book ends with how to integrate with agile and make organisational shifts.
My Own Reflections
I feel that the message here is pretty clear and along the same lines that I am already thinking. The main points I take with me is to let the design drive the project even earlier on. I have been mostly focused on impact mapping. Prototyping like this may very well be a much better way than to start writing requirements for the GUI -parts. I have decided do learn how to make interactive prototypes in Balsamiq and maybe in Powerpoint as well.
It is a fairly easy read and I specifically like the strong focus on solving real problems together with the users. It is definetly time for the UX movement to take more place in our often dysfunctional projects.