Bringing Designers and Developers to an Agile Methodology
There has always been a big difference between how designers and developers work. With the new wave of technology, the design and development teams must work closer together than they ever have before. The Agile framework is widely accepted with development teams, but how do you get the designers involved?
Our Sourcebits team has worked hard to integrate both activities into one high-functional crew, that works towards one unified goal together: the creation of a product. Think about it this way – a football team couldn’t function without all the different parts of the team working together. The coaches are the designers of the game. They plan out each play so that the team flows together to get a win. The players are the developers. They are executing the designs, but if the two don’t work well with one another, there is no way the team could pull out a win. And just think, they have 1-week sprints.
So, how do you get everyone integrated into Agile, including designers? There are three different aspects to look at:
The whole process starts with the right people who should bring the right attitude.
- Come to terms with reality: First things first, accept that the beautiful mockup and specs you created will become irrelevant as soon as you hit “Print”. Technology is changing. Your competition is coming out with something news. iOS is updated. Whatever it may be — something will change before you get to production. Designers and developers both need to be flexible. Coaches have to think on their feet if their “designs” aren’t working for the team and the players might need to make some adjustments as well. Embrace the fact that nothing is stable.
- Don’t overthink: Don’t get hit by analysis paralysis. Try replacing overthinking with practice. Shut up, grab a pencil, and show it. Ever see a coach draw out a play on a chalkboard? It’s much harder to explain an abstract concept by just trying to talk it through. Relaying concepts in a visual way helps stimulate the brain to think through problems in a holistic and actionable way. It also minimizes the amount of documentation that is produced during the project and thus makes the process more minimalistic and nimble.
- Conscious team effort to eliminate artist ego disease. It’s a common human condition. It’s not a bad thing to want validation for something you’ve worked hard on, but there comes the trap. You develop an idea until it’s absolutely perfect with the goal of all the praise it will get you. It happens in void because “it’s a secret until it’s perfect”. It’s sensible to force oneself to think of the work as continuous chipping away and check-ins instead of grand reveals and presentations.
- Mindset shift: In reality, the client’s opinion doesn’t matter. It may seem backwards, but think about it. What they want is not always what is going to be successful. We need to take a closer look at what the USER wants, not the client. It’s okay if the client doesn’t like what is being built, as long as it is validated by the target audience. It’s important to make a distinction between validating what we create and not fall into a trap of trying to validate ourselves.
- Only by embracing risk you can turn it into a weapon: When you start a project, you don’t always know how it’s going to end up. Take a risk and turn it into an advantage. If coaches didn’t take risks with their plays, they’d all be repeating the same plays over and over again and the game becomes predictable and easily beat. With the Agile methodology, there is room for ambiguity and experimentation. You don’t need to know exactly what needs to be built a priori. When the team works with the expectation of change and failure, the fear of it dissipates and creative energy kicks in. The more attempts you make, the bigger the chance of success. And if they are small and quick, the cost of failure is small.
After you’ve got the right people with the right attitudes in the right place, the next step is refining how you do things. What is your process? What tools and method are you using?
- Planning: Design runs at the very least 1-2 sprints ahead of everything else. Developers need their space. Their workflow benefits from structure, i.e. having specific and set-in-stone use cases. Designers need freedom of a different type: the freedom to explore and go on tangents. You want to give them space to be creative and innovative with their craft. The coaches plan out their plays ahead of time to give their team time to practice and find the best way to complete each one. Running 1-2 sprints ahead gives them room to take risks and when your ready to go, design is ready to commit.
- Interactive Prototyping: If you work with Sourcebits, you will never see a static mockup, wireframe, sketch — none of that. We still create these internally, but everything that is presented to the client is interactive. With the interactive prototypes, we attempt to shift everyone’s mindsets so that they think in terms of the actual, living product as opposed to a static composition of colors and shapes. That brings out a very different type of feedback, one that is much more useful to product strategy and real feature development.
- Creativity vs. Discipline: We encourage our team members to try new things, but we still need to make sure we deliver. This approach really teaches the team when to say “Stop”. It’s about finding the balance between making the product perfect and getting it to the client in a timely manner. The underlying message to the team is that imperfection is not a bad thing and quality is expressed in steady progress, not how polished the pixels are.
- Continuous Validation: Continuous validation is the best way to get valuable feedback, but not just from the client. Getting approval from the client is just one step in the journey, but the end users are the most important piece of the puzzle. We conduct usability studies with random people — strangers, employees, family, etc — to get their honest, spontaneous feedback on how the product works. We attempt to touch a wide spectrum of use cases, not shying away from the extremes at all. Very often negative feedback turns out to be the most constructive.
The final step to implementing Agile in the design process is determining how you actually are going to accomplish the process.
- Tools: Determining what tools you are going to use is crucial. Sketch + Invision are a powerful combination that allows us to create, prototype, collect feedback and track progress. The vast majority of the interactive prototypes that we show to our clients is done in Invision. For special cases of highly customized interactions, we bring out the heavy artillery, such as Flinto or Adobe After Effects. Either way, we strive to put a lifelike product in everyone’s hands rather than just ask for critique on static art.
- “The Starbucks exercise”. We like our usability testing process lean and fun. A Product Director is in charge of the usability studies. They go to a Starbucks, sit at a table and put up a piece of paper that says “come test my app and I’ll buy you coffee”. And it works. The casual setting helps remove bias. Since we’re analyzing behavioral reaction to how the product works, it needs to be spontaneous, without expectations and prejudice. All the learnings are reviewed with product strategy in mind and immediately validated in a stand up on the next day. We iterate on the new findings, build a new prototype and go to Starbucks again. The process of iterations and validation continues until we are either happy with the result or we run out of time or budget in the sprint.
Combining the right attitude, process and practice are how we’ve found success with the Agile methodology. It allows our teams to ship faster and increases the likelihood for the product to be successful and relevant to the market.