Methodologies: What to choose, and Why?
Often, when starting a new project or working with a new client, a common question is what methodologies I work on, it doesn’t really matter if it’s gonna be pure design or with a whole team for development.
To tell the truth, I don’t really like to answer this question, because even when some methodologies (when done well) deliver a successful product, some may just deliver, period.
Marriage might be a sacred thing but when talking about methodologies is not a thing you want to do, as a UX Designer you do not want to marry a methodology for the rest of your life. You have to care about your client and more importantly your project and avoiding vicious circles, should be your priority. Marrying a methodology it’s not bad nor the best. But if you let me be a little honest I’m a believer of uniqueness. And yes I do have my favorites (forgive me but it is not like methodologies are my children and have to love them equally), but I do believe every project should be treated as a unique organism. Its DNA and the way to build it is meant to be different, even when the foundations and its core may be the same.
Nowadays, you can become a parent in different ways, the same happens with projects, if you are looking forward to becoming a parent, adopt, surrogacy, in vitro, regular intercourse, and many other are the options available. The end result is, you have become a parent, the way to achieve the status has its variables.
Not all methodologies suit every client, company or project. And sometimes even when you can find one that suits, it might not be perfect for two projects even if this two are for the same company.
Iteration is a must, your main goal is to find the perfect solution and balance between all of them, your client and/or project needs and your final user.
The most popular methodologies I will talk about here are Agile, Lean Startup and Design Thinking, plus I’ll give out some notes on the newly popular GV Design Sprint. There is no right or wrong for my own beliefs but knowing their strengths and weaknesses will help you find the one or how to tweak the one for your project.
One of the most common methodologies in the IT industry is Agile, and as you can recall this methodology best characteristic is to be efficient in a really small amount of time, getting doable goals and with the option of improving itself periodically.
This methodology is based on the also very common Agile Development, which was created to improve the efficiency of teams to achieve goals and deliver products or features faster. If you want to know more about agile and the history of it you can look for a quick reading from Jeff Gothelf – “Lean VS Agile VS Design Thinking” this may not be a book that will blow your mind but will give you some deeper background of what all these methodologies are about.
Principal features of Agile UX Design.
- Work in short cycles (2-3 weeks)
- Reflect accomplishments, learnings, new insights & new steps.
- Analyze results
- The course of actions can be changed if needed.
Inspired by the Agile Manifesto, Agile UX is the integration of the User Experience Design and the Agile Software Development Methodology. This is the Design team and the Development Team working together.
It all resumes into a continuous dynamic system that is regularly optimized, augmented and improved.
- Limited vision of scalability
- Team level practices (scrum cards, pointing)
- Incorporating feedback is simpler
- Risks & consequences are easily known.
- Potential chaos growth when scaling out to 10-100 or 500 teams
- Optimization is local
On the other hand, we have Lean UX that, some people easily confuse with Agile UX and even say it is useless, and let me explain why I can not agree with this.
Lean UX is the application of the User Experience Design methods into product development. Lean UX started here, at Lean Startup, but, UX is applied to it. Lean UX is suitable mostly for startups, with one main objective, building an MVP (Minimum Valuable Product).
As I mentioned before this methodology is usually confused withe Agile UX because it mostly uses the same base, except, when something is not giving the expected response, this feature should be deprecated.
For a good MVP there should be 2 questions to be answered:
1- What is the most important thing?
2- What’s the least amount of work needed to learn that?
Diverted intention leads to a (not always) what is the fewest number of features we can get away with and still ship this product. Product owners must ask themselves along this path always, what is the thing most likely to make it fail?
Accepting this method as for innovative teams requires more than just continuous work but also, taking decisions based on results, even when release dates are fixed.
- Fast feedback
- Clear goals
- Probability to fall into meaningless intention to deliver against the results, causing cost of time, development effort and even money.
Jeff Gothelf has said it before, Agile help us deliver in regular cadences, Lean help us determine what to focus on, but, what is Design Thinking? and How does it work? and even more importantly, how is it gonna help me as a designer, my client, the users, and the complete project?
It all started within IDEO in the 1990’s, Design Thinking teaches teams to take an empathic look at the customers to understand the core needs through a series of exercises to come up with solutions. The principal goal of Design Thinking is to Empathize, that’s how they came up with the “honeycomb” that explains the process. The exercises have been modified over the years and even taking in mind the needs of the projects and the clients’ needs.
The honeycomb is very clear by itself and there are several courses, books, and information out there of how to take this process all the way.
Whilst other processes have very specific goals and short cycles, Design Thinking is kind of a way of life, every company and every project should have a Design team working in a Design Thinking Methodology to improve their products, yet, not having a specific goal could limit the vision of the company and get lost into an eternal cycle that may never stop or take you anywhere.
- Teams build a shared language and common sense for the upcoming project.
- Teams are perceived as a waste of time that could have been used to write code.
GV DESIGN SPRINT
Jake Knapp resumes very well the GV Design Sprint in their official website to as “The sprint is a five-day process for answering critical business questions through design, prototyping, and testing ideas with customers.”
It all started in the heart of Google Ventures’ need to improve their processes they needed faster, yet, equally effective ways to bring up concerns and solutions to main issues or problems for their startups.
They found a way to get through a great process in five days. finding problems their companies did not even know they had and take great care on the real things that matter the most.
It all sounds like magic, but as every process, it is special and very jealous, it is not a magical spell to get thousands of investors and make billions on each company that uses it, but clearly, it is a good tool we can use in your company too.
It requires a true compromise from all members involved. And sometimes this compromise is not taken as seriously as it should.
- Design Sprints are a fast and efficient way to reduce uncertainty and to boost development cycles in a Lean Startup environment.
- Is a shortcut that allows us to go from the idea to learning without actually building anything.
- It reduces the risks of making bad decisions as we get an initial validation in just five days.
- Even though you run a well executed Design Sprint, you can come out with a very bad idea.
- Making wrong assumptions will likely lead you to design for somebody who is not the person who is supposed to use your product and ultimately test and validate your solution with the same wrong target.
- Teams constantly tend to look for a confirmation of the old ideas during the workshop.
I certainly do have my favorites, yet, each project should follow its own needs and its own priorities, following each methodology literally may or may not be what you need, so take in consideration tweaking the processes is allowed. These methodologies are proven to be effective for what they were built for, but also your project is unique, think of it as one of a kind, you can start following a method that suits better but when you see something is just not bringing the results you were expecting bend the rules, think out of the box and spread your wings, many have done this for their own companies, policies, or methods, dare to do so, and fly free over the velvet skies.