Designing in Phases
In the summer of 2017, I had the pleasure of joining Hootsuite’s Product Design team as a UX designer for all things mobile. I first came to Hootsuite looking to get a taste of the tech industry and am so thankful to have spent 4 months in such an inclusive, collaborative, and welcoming environment. Even though I was just a co-op student, there were endless projects and opportunities that I was able to have full ownership over. This creative freedom and level of responsibility was a rewarding learning experience, mainly thanks to the amount of mentorship I received along the way. By working alongside UX designers, user researchers, developers, and product managers, I got to see my designs being developed, learned the process and what it takes to ship a product.
Often as design students, we’re taught to create meaningful, delightful end-products. We develop a vision for our designs and create mockups of this ‘ideal state’. But what we fail to consider is how to follow through with our ideas. How will your designs be implemented? How will they be built? How will it be adopted by users? How will it scale over time?
One of the most valuable lessons I learned at Hootsuite was the importance of evaluating your design before breaking it down into phases for release.
All this requires careful consideration between multiple stakeholders, including you, the designer. A fellow UX designer at Hootsuite, Guillaume D’Arabian, describes it with this pyramid-shaped model that illustrates the relationship between business, design, and technology. By finding the right balance, you’re able to meet the needs of your customers. The real challenge however, is maintaining this balance over time and adapting to unexpected circumstances–from customer feedback, unaccounted use cases, and edge cases.
So what do we mean by phases?It’s great to run developers through mockups and the vision of your design, but when it comes to putting a product out into the real world, it takes time and multiple iterations. In order to achieve your vision, you need to break your design down into phases to account for how it will be released.
Phases represent the scope of a particular sprint or release. They’re helpful for everyone because they define the priority of what needs to be built, show how each element or feature will be implemented, and create a shared understanding of how your product will evolve. In order to determine the priority of what needs to be built, it takes a level of strategic, technical, and customer understanding. This is where the pyramid comes into play.
A lot factors emerge when defining the scope for each phase: from the business strategy of your product, the complexity of each feature, the bandwidth and resources available within your team, the known behaviors among customers, and adapting to customer feedback.
Here are 3 key considerations to keep in mind when designing in phases:
Create An Easy Transition
- If you’re proposing a redesign or a new feature, how will you transition core users to your design?
- How will you introduce new users to your design?
- What will you introduce first and how?
- Are you replacing a behaviour or creating one?
- Have a general understanding of how your design will be built. What are the more complex pieces? What are the easiest pieces to develop?
- Are there elements within the existing product that can be reused in your designs?
- What pieces are crucial in solving the problem you’re designing for?
Consider How it’ll ScaleDesign is never finished. It’s important to consider how your designs might adapt or scale over time, while keeping your vision in mind. In general, this is a good exercise to test the longevity of your designs. And even though you might not be able to predict it all, this might just help you define potential phases down the road and identify future areas of opportunity.
- How will your users’ behaviours change as they transition from being a new user to an everyday user?
- How will your design scale to a high volume of users?
- How will your design scale as it adopts new features?
Creating your MVPBy now, you should have a general idea of how to create your MVP (minimum viable product) for the first phase/release. Coined by Frank Robinson and popularized by Steve Blank and Eric Ries, the term MVP refers to “the smallest thing that you can build that delivers customer value.” Your MVP should be able to address the core problem and provide basic functionality, but most importantly, create a lovable experience. With every release, your customer feedback will either validate or refine your ideas, helping you plan for the next phase of release.
As UX designers, we’re trained to be considerate of our audience and our users—but this also applies to our own teams. The most successful teams are built out of strong relationships. In order to build a successful product, it’s important that we stay mindful of everyone’s needs.
About the AuthorAmanda is a Co-op UX Designer on the Product Design team at Hootsuite. Working closely on Hootsuite Mobile, she’s worked across multiple teams from Publisher, Plan & Create, the iOS and Android core team, as well as the first team for Hatch–an incubator program at Hootsuite. During her off time, you can find her visiting local events, thrift stores, art exhibitions, or taking street photography.