Outside of the code: Development with design (thinking)
By Jonathan Farrell, Hook&Loop
When I first learned about design thinking, it seemed like such a natural process—but it wasn’t my process. The problem is I’m a developer, and I’ve been taught about planning, requirements 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 the coding process would affect the user and the overall experience. I’ve realized that design thinking can be useful for anyone looking to deliver positive outcomes for users’ needs — developers included.
At Hook&Loop, Infor’s creative think tank, we are driven by design and innovation. Developers work with a group of designers, information architects, and user experience experts. It’s no surprise that we want to feed off their creative flow and adopt some of their principles. Sometimes we even want to let design drive the development process.
What is design thinking?
Design thinking is an approach to solving problems by 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 not 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.
Where do Agile methods fail?
Agile has become such a buzz word that companies throw the term around like it’s the silver bullet to eliminating productivity issues. But sometimes Agile isn’t the best process. Many teams blindly embrace and follow these standards because, well, it’s Agile.
Agile has been praised for faster time-to-market, quicker adaptability to ever-changing user needs, and better aligned collaboration between teams and disciplines. But every project we undertake falls on a different spot on the Agile spectrum. There is no universally applicable methodology. Without the proper guidelines, Agile can even lead to some fundamental issues in a design-driven environment:
- Code sloppiness: UI tweaks, on-the-fly decisions, making a change but keeping some of the old code around happens because it’s quicker — that’s reality, but also sloppy.
- Near-perfection: When everything is an iteration, it can be hard to lock down both the architecture and the design. As we take pride in our work, nearly perfect isn’t nearly good enough.
- Over-management: If you need to pivot mid-sprint, how do you react? Do you have to wait for sprint planning? What if you do something that’s not in the Agile playbook? Sometimes Agile is not very agile.
How can design thinking help?
We need to be able to iterate based on user testing, innovate to drive the experience, and adapt to new challenges. Many of our projects rely heavily on research and design, and there is a large element of Waterfall-style project management.
Research. Design. Develop. 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. If design is driving the project, include development in the design process. You may only need one voice, the development representative. This diversifies the group and gives development an opportunity to contribute to the solution. Some of the benefits over traditional Agile methods are that it creates plenty of time for:
- Research: Know your users, drill down to exactly what the key principles are, and make sure early designs are going down the right path.
- Design: Having plenty of time to define the overall design is important. There will be iterations, but having a cohesive design language at the onset will help with future decisions.
- Architecture: Creating a scalable architecture on the fly is challenging. Putting in the initial effort to create a system that adapts to change gives you a solid foundation, with room to grow.
Keep your project management muscles agile but don’t back yourself into 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 use some design-thinking strategies—especially brainstorming with everyone involved. Come together as a team, discuss approaches, and try them. Let developers think like designers, and let designers think like developers—and let everyone keep the user in mind. In a design environment, collaboration can be more beneficial than handoffs.
- North America