Article summary
When I started this journey I didn’t know much about the design process at Atomic. The interest stemmed from wanting to see the bigger picture. At my first kickoff, I was amazed to see the design team shine at facilitating activities to pull information from our clients. Then, before I knew it, there were mockups and stories in the backlog. I wanted to get more involved in that process.
To achieve this, I decided to have lunch with some designers in Ann Arbor. I had some questions I wanted answered. How do we go from kick-off to sprintable work? What’s the process of gathering business requirements and turning those into mockups? How do we gather abundant information, analyze the data, and turn it into a product backbone? What even is a product backbone? Here, I explain what I was hoping to accomplish on my journey to answer these questions, my key takeaway, and how devs can utilize this information.
What I Wanted to Accomplish
As much as I love code-crushing, I wanted to branch out and work on becoming a better consultant. After the accelerator program, my next goal is to become a tech lead. This means upping my consulting game. I wanted to demystify the process. How do designers and leads go from kickoff to sprintable stories? The first step is to identify what information is needed or missing and understand how to gather that information from the client. To know what information is needed, we need an understanding of the client’s goals, the organization, and the product we plan to deliver. Once we have this, we can brainstorm the possible risks and how to mitigate them.
Key Takeaway
A big challenge is understanding how to provide the most value to the client with the least amount of risk. This process involves comprehending the current problem, gathering the business requirements, and analyzing user needs. When we gather the necessary information and start to analyze the data we want to understand why we are here and who the users are. What are the pros and cons of the current system? And what are the concerns with the new system?
One way to gather this information is during the project kickoff. Facilitating an activity is a great way to accomplish this. So how do I pick an activity? Are there some criteria to point me toward the perfect activity for my needs? Well, no. Focus less on the actual activity and more on what the client wants us to understand. There’s lots of informal research that goes into this. Sometimes there are pre-kickoff meetings to get more information from the client before the actual project kickoff. Other times the research involves reading the user manual of the current product.
Analyzing the Data
Once the information is gathered there are many techniques for compiling it. Site maps are a good way to sketch out some options before too much design work is done. These can help establish how the new system can fit in. A product backbone will assist in visualizing the lifecycle of the new systems. Personas and user interviews can reveal frustrations with the current system and what works well. “Try This Exercise in Creating Personas for Software Design” explains how teams can use personas to their best advantage. All of these techniques help with gaining familiarity with the current product and the problem we are trying to solve.
Conclusion
Some challenges with design are getting the information needed and relaying this information. When more developers take an interest in this process, we lessen some of these challenges. When we all have a seat at the design table it establishes a more efficient knowledge flow and streamlines decision-making. If you see the bigger picture, you are better able to create products with the end user in mind. Do you have any interest in learning more about this process? Talk to the design team! And use Spin. It’s a great resource. Get more of the team involved.