When I first learned about design thinking, it seemed like such a natural process. The problem is, I’m a developer, and I’ve been taught about planning, requirements gathering, sprints, and scrums. I’m supposed to be an agile thinker, not a design thinker. But outside of the code, I am an empathetic human being, and I’ve always thought about how the coding process would affect the user and the overall experience. We need to look at how design thinking can be useful for anyone who that is looking to deliver positive outcomes for users’ needs — developers included.
At Hook & Loop we are driven by design and innovation. The development team works within a group of talented designers, information architects and UX experts. It’s no surprise that we want to feed off of their creative flow and adopt some of their principles; sometimes we need to let design drive the development process.
What is Design Thinking?
Design thinking is an approach to solving problems. Design thinking is centered around truly understanding user needs and opening yourself up to trying as many things as possible before coming up with a solution. It works well in design, so why don’t we use this approach for development? We can analyze, experiment, and remain flexible to the approach that best suits the problem, the needs of the project, and the capabilities of the team. Our software, after all, is made for the user, not for the process, correct?
Where Do Agile Methods Fail?
Agile methodologies, or the iterative process for project managing development and design, have become such a standard buzz word that companies throw the term around like it’s the silver bullet that will solve all of their productivity issues. Regardless of how trained and focus we are, projects vary in time and complexity and sometimes Agile just isn’t the best process. Many teams blindly embrace and follow these Agile standards because, well, it’s Agile, and it’s what everyone is talking about. Every project we undertake falls on a different spot along the Agile spectrum. There is no universally applicable method. Problems will be problems, people will be people, and timelines will be timelines.
Agile has been praised for faster time to market, quicker adaptability to the changing needs of the user, and better aligned collaboration between different teams and disciplines. But despite what the text book says, everything isn’t always perfect. Without the proper guidelines, Agile can lead to some fundamental issues in a design driven environment:
- Code sloppiness: Quick changes, on the fly decisions, UI tweaks. These things happen. Needing to change something but keeping some of the old code around because it’s quicker?—?that’s a reality. And things can get sloppy fast.
- Hard to produce perfection: When everything is an iteration it can be hard to really nail down both the architecture and the design. When we pride ourselves on perfection, nearly perfect isn’t good enough.
- Over management: If you do something that’s not in the Agile playbook, what happens? If you need to pivot mid-sprint, how do you react? Do you have to wait for spring planning? Can you change scope mid-sprint? Sometimes Agile, by its very nature, is not very Agile.
How Can Design Thinking Help?
We’re driven by design so sometimes we need to focus on design. We need to be able to iterate based on user testing, innovate to drive the experience, and adapt to new challenges or feature requests. We have many projects that rely heavily on research and design. For these types of projects, there is definitely a large element of Waterfall style project management. Research. Design. Develop. Work can be funneled Kanban-style through the developer and that allows us to track progress, iterate quickly, and provide feedback on the rate of completion for the client. Let’s translate this to a design thinking approach.
One of the key concepts of design thinking is to bring a diverse set of people together to find a solution. So, if design is driving the project, include development in the design process. You don’t need a whole team, just a voice, the development representative. This diversifies the group and gives development an opportunity to contribute to the solution. How else can this help?
- Plenty of time for research: It’s always good to know your users, to drill down to exactly what the key principles are and to make sure that early designs are going down the right path.
- Plenty of time for design: Having plenty of time to really nail down the overall design is very important. There will be iterations and improvements later in the project but having a cohesive design language at the onset will help with decisions down the line.
- Plenty of time for architecture: Coming up with a sensible, scalable architecture on the fly is challenging, by putting in the effort at the beginning to create a system that can adapt to changing needs as the project progresses gives you a solid foundation with room to grow.
Stay Adaptive
Keep your project management muscles agile but don’t back yourself in a corner. Don’t be afraid to experiment. Don’t be afraid to work with designers. Keep the bits that work and change the bits that don’t. Along the way, try to utilize some design thinking strategies–especially brainstorming and open it up to everyone involved with no boundaries on the ideas that people can suggest. Come together as a team, discuss them, and try them. Let developers think like designers and let designers think like developers with everyone always keeping the user in mind. In a design environment, collaboration can be more beneficial than handoffs.