Designing in Phases

Designing in Phases

By: Amanda Poh | SIAT Student
  13277 reads

This article was originally published by Hootsuite.

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 when it came to the design and implementation of a project. 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 built and understand from different perspectives what it takes to ship a product.

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. 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?

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, forgotten 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:

1. Create an Easy Transition

Consider how you’ll be introducing your designs to existing and new users. What’s the onboarding process like? How will they be introduced to the new experience? The following questions should help you think through the different considerations and steps needed in order to reach your end vision.

  • 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?
  • Are there certain features that are more important/crucial than others?
  • What parts are crucial in solving the problem you’re designing for?
  • What will you introduce first and how?
  • Are you replacing a behavior 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?

2. Consider How it will Scale

Design 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 user’s behaviors 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?

 3. Creating your MVP

By 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 it should also be a delightful experience. We want to create something that’s lovable and memorable. 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.

* A use case is specific scenario that contains a set of actions to achieve a particular goal by the user. An edge case is a use case that might occur very rarely or only at an extremes (maximum or minimum). Often, developers will have the best idea of the majority of use cases that will be need to be built since they’re the ones building it. As a designer, working with a developer is crucial to pinpoint all the use cases that need to be designed and accounted for. Keep in mind, certain use cases will be more important over others, so the level of design/development effort will vary depending on the use case.  


 Beyond the Article

 
Posted on August 24, 2017