Full Product Lifecycle pt.3 — Implementation — Designing along Development
In part 2: Testing new ideas before wasting tons of time and money, we discussed running a Design Sprint to validate your idea with your customers and reduce the risk of jumping into development and building a product your customers won’t use. In this article, we go in depth about scheduling features and working with cross functional teams to design and build the tested product.
Why you can’t use your sprint work
The prototype completed during the design sprint was done to test and validate a high level concept. The outcome should inform direction but the final product will require much more detail. Development will need specifics on what they are building, where it will live in an overall ecosystem, and how things function based on different states.
Planning Design and Development
I’m familiar with SAFe(Scaled Agile Framework) so I’m going to be using that as the main development framework in this example. To that point, your project needs to be broken down to epics, features, and user stories. Epics are basically a group of features, features are a group of user stories, and user stories are the fine details that outline how it should be developed. We primarily design at a feature level which informs the user stories that go into the backlog and prioritized. During project increment planning, where we schedule the upcoming work for the next 12 weeks, we choose which features are going to be developed based on the amount of people working on the project. We make sure to point out any design dependencies on features and make sure we plan to deliver the work a sprint ahead of development. We also work with any other dependencies that develop APIs the development team might need. Once the work has been planned we can start working on the planned features. Another key thing is to plan enablers, upcoming features that can have research started earlier. These are features we start researching so once the feature is scheduled it will already have some understanding. We also plan for beta or product support when we’re launching the product in order to allocate time for anything that may be found when the product is in the hands of users.
Design process
Kick-Off
Now that we have the features planned the team meets for a kick-off. This is usually an hour long meeting per feature to get an more defined understanding. The meeting can have stakeholders, project managers, and any other experts involved. During the meeting we discuss the goal of the feature, the problems we’re trying to solve and any predispositions. The predispositions we try to understand are:
- What do we know?
- What do we not know?
- What are your assumptions about the project?
- Who are our users?
- What are your assumptions about the users?
Answering these questions will help inform what needs to be researched. We might not know how they’re solving this problem currently, or if something can be done legally, in which we’ll need to find out.
Research & Insights
After getting that understanding about the feature, we know where to start researching. We can look back at previous data or look for more if need be. We ideally like to have observations around the customer, competitive research, and what currently exists. We also gather documentation around best practices and any patterns that may currently exist. These existing patterns may influence the behavior around what your customer is familiar with. Finally, we gather any inspiration that may not directly be a competitor but have similar functionality. We compile this data into insights that will help designing the feature.
Concepts & Concept Systems
Once the research has been complete the team reconvenes to draw out the feature. Using the research done the team can align at a low-fidelity solution. If there are people with doubts multiple solutions can be identified and tested. The main thing is to get concrete testable solutions at a low fidelity stage. It’s much easier to erase a drawing than re-design a prototype.
Prototype
Once the solution has been agreed upon at that low-fidelity stage, its time to turn it into something consumable by a development team. They need to see the way it should look, where it will live, how it will behave when actions are taken, how different states are handled, and have access to any assets used. We primarily use Figma for this along with some other tools for various use-cases(such as Principle to show animations). This prototype can also be used for additional testing to ensure its usable and solves the users problems before going into development. Ideally you can get to this stage in a week, leaving a whole week in the sprint for testing.
Beta Release and Including Metics
Once you’ve developed enough features to equate to a minimal marketable product, ideally, your company should launch a beta for users to try out before releasing to everyone. This is to make sure it functions as it should and catch any thing missing earlier. Once your team is ready, it can launch to everyone. It’s important to note that there should be marketing accompanying your tool to help inform your user-base what your product is and how it will benefit them.
When does it end?
This process goes on until you’ve solved the problem of your users. At the point in which it costs more to build new features than value it brings to your company then you should evaluate how your product has changed their journey, identify new business initiatives and repeat the cycle.
Conclusion
After prioritizing what you’re going to build, each feature needs to go through a design process which includes understanding the problem its going to solve, any predispositions your team may have, research, alignment on low-fidelity designs, and a testable prototype development can reference when building the product.
In part 4: When is a project finished? we’ll go into depth about the cost of running a project, when to stop, and what to do next…
Ritzie Design Studio is constantly on the hunt for knowledge and improving the way we design products. Let us know what you think in the comments section and follow us for more discussion around process and designing products!
