At Academy, we have done a great deal of thinking about process. We have interviewed industry leaders across Design, Development, and Product and universally the sentiment is…“ Why can’t we all just get along.”
When we started to think about it, relationships are built on the backbone of trust, and clear communication. So where was the breakdown? Well, every group seemed to have their own strategy of doing things. Design had Design Sprints, Product and Development had Agile, and each was trying to prove what was right or wrong about their process. This approach proved to be futile. We started thinking; perhaps there was a way to unify the approach so we could bring the best of both worlds into one fluid process. One Sprint handing off to another Sprint. We decided to call it a Product Relay™.
What is a Product Relay?
It’s a way for a team to unify their approach bringing the best tools from Design Sprints and Agile Development Sprints into one fluid process. We felt it was necessary to document this so that teams could see the whole picture more clearly.
What is a Design Sprint?
A Product Relay™ always starts with UX Research. We are going to want to conduct Stakeholder Interviews, Usability Tests, Field Studies, Data & Analytics, etc.
Then we are going to want to run a Planning session with our key stakeholders to understand all the problem areas, categorize, prioritize and organize them into various sprints.
Sketches get translated to Wireframes inside of Sketch to ease the transition to design later in the process.
Once we are ready to run our first Sprint, we will conduct a Sketch session where we invite our key stakeholders, field experts, design experts, tech experts, and product experts to sketch solutions to our problems. We will then democratically Vote/Decide on the path forward. This is an opportunity for everyone’s voice to be heard before it’s too late so make sure your “Decider” is in the room for this session.
We start our designs as wireframes that we build in Sketch. These days it doesn’t make sense to use any other tool. We find that building in Sketch allows us to keep our workflow much more streamlined. We try to set up our symbol management in advance so that it’s a seamless flow from Wire’s to Design. This may change as new tools arise but for now, this works well.
Once your Wireframes are complete, it’s important to get approval from your key stakeholders on the path forward. Once approved, you can get started with Design.
We like to use Niice.co or Pinterest to create a shared mood board. We then do an inventory of our symbols and create a Design Language System (DLS). As tools are constantly evolving, we are excited to start using InVision’s Design Manager system.
Once our DLS is built, we start rapidly working on our Design deliverable. We will present early styles to the management team to get their initial approval then a full design once complete.
Sample Design Language System
With their final approval, we move this into prototyping.
Using tools like InVision, UXPin, Framer Team, Marvel, etc. we build a prototype. We love all these tools, but our advice is to use the right tool for the job that is required. Investigate them to find the nuances. We generally use Craft for mobile prototypes as it provides the most seamless workflow. However, we are super excited for this! InVision Studio is arriving sometime in 2018 and looks extremely promising. Check out this video:
Once your prototype is built, we move this into a Usability Study. Our UX Research team will have found 5 participants to join us.
‘ 5 participants could reveal about 80% of all usability problems that exist in a product (Nielsen, 1993; Virzi, 1992)
If you are having trouble convincing executives of the validity of this, then point them to this article published by Nielsen himself:
He acknowledges that sometimes it’s good to test more, but what we are trying to do here is establish a baseline not receive an approval on a new drug trial. A baseline will give us something to look back on and compare too.
Our UX Research team will prepare a script that looks something like this:
Upon completing our study, the UX Research team would prepare their findings and present to the Key Stakeholders and Sprint Team.
We will review the results of our study and implement changes addressing the feedback.
Our designers will prepare the final files and work with Product to import them into Zeplin. This is a place for our developers to communicate directly with our design team and review a digital spec sheet of our project. This is just one of the many features offered in this tool. Among them are commenting, collaborations, stylesheets, code snippets, asset downloads, and more. Other tools we might recommend include InVision Inspect and Avocode.
While the designers start the communications channel with our developers, our product team will begin building a backlog of JIRA Tickets (Atlassian). We recommend starting with the backend APIs first to get ahead of the design team’s front end work if possible.
Once all the tickets are submitted the development team should feel ready to begin their first Agile Development Sprint.
Here is where our rockstar product managers help steer the ship. Their work in documenting backend APIs, User Permissions, User Flows, User Types, Feature Sets, etc. is pivotal. We are not big fans of massive amounts of documentation or paid tools like Confluence. We find the that using a combination of Google Suite Products will get the job done 99% of the time.
After documentation is complete, Product Managers will be responsible for breaking down the app into smaller digestible chunks for the development team organizing sprints.
We like to get a base app up and running that will provide the skeleton while richer features are built out later in smaller sprints.
The point is to build components fast, test in small beta groups along the way, then delivering a final release when all the bugs are fixed.
We like React JS for most things but use the right tool for the job here.
There is a multitude of ways to test in various forms including both in the quantitative and qualitative side. Your UX Research team will be able to advise you more on this as it entirely depends on the status of your product in its lifecycle, baseline data, tools available, and much more. The point is: hire pros to do this and don’t be afraid to earmark this in your budget. We do, and it’s worth every penny.
Once you have received your analysis, it’s important to marry your quantitative data with your qualitative data to ensure they are in sync. If they are not or are not meeting industry standards, then you have a problem and should dive deeper into the cause. This is an excellent opportunity for another Design Sprint!
With all our data syncing up it’s time for Launch. Let’s put this little rocket into the market and see how it flies. Sorry I couldn’t resist. Same goes as before though; you’re going to want to keep an eye on your analytics and set up key milestones to measure your KPIs again as they may change as your user base evolves.
Where Do We Go From Here?
The team at Academy UX & Design Thinking Studio is super passionate about Product Design, and our sincere goal is to help teams work better together. We believe this process is the first step towards a common understanding: but further, a tool to more clearly communicate and understand each other’s roles, responsibilities, and commonalities as we seek to build a better world around us, together.
If you would like to learn more about Academy UX & Design Thinking Studio and how we can help, please reach out to us at academyux.com