Recruiterbox Design Process
In the book design of everyday things, there is a mention of design is a very complex thing and needs to involve people from multiple parts and roles of the company but usually it is not done. Very few companies involve people from multiple roles and disciplines. At Recruiterbox, we borrowed heavily from the sprint book by Jake , John & Braden and created a design process that helps us rapidly come up with solutions within two-three days for complex and vague problems. We involve people from customer support, engagement, design, engineering, product owner and managers in our design process.
We approach our design meetings with the following objectives
To get everyone to a common understanding about the problem to be solved
To arrive at a starting point for design
To break down the values that can be delivered incrementally to customers
To derisk the risks in terms of perceived customer value & tech constraints
We pace the sessions across multiple days depending on the outputs from each session. We have been able to quickly churn out designs involving everyone possible.
We rank top in the user friendliness in capterra - http://www.capterra.com/applicant-tracking-software/#user-friendly
Outline/structure of the Session
Outline of the session.
Problem definition - The product owner gives an overview of the problem and why we need to solve. Every one are given a sticky pad to keep writing any questions popping up, one sticky at a time. They also note down their thoughts but do not speak up (Just make sure every one participates, a writeup here)
Questions - Some time is given to the team to go through their notes and write down the questions and put them on the board, the product owner keeps grouping the questions based on the theme. These questions are why, what, when, who nature. We skip the how to implement part for later sessions.
The product owner goes through the questions along with the designers and scopes the solution space. Risks and assumptions are identified in the process and noted down on the wall.
User Journey Mapping - Based on the solution scope, a rough user journey map is drawn to get everyone on the same page. This draft keeps changing over the entire exercise.
How will we implement questions - After scoping, stating risks and assumption, the team then puts up their how will we implement a scenario or condition question. We collect all the questions, remove duplicates and out of scope ones. If the final list is greater than 10, we either cancel our exercise or revisit the scope to keep it manageable.
The team breaks for the day with a home work to find inspirations from existing designs and present it to the team.
Demo - The entire team brings the results of their findings and present it to the team. Each one takes turns to tell what they found in the public domain potentially solves the problem and why they liked it.
Sketch - The team then sketches their solutions which may or may not answer all the questions about the implementation and put it up on the wall like a gallery.
Walkthrough - Each person gives a walkthrough of their solution, feedback is captured and put next to the sketch.
Storyboard - The designer and product owner picks up the sketches which solve the problem well and map a story board to reflect the user journey map.
Values to be delivered and sequence - From the storyboard the engineers derive the values to be delivered and in what order to deliver so that we can keep delivering week on week.
We validate if all our objectives are met, archive our sketches and get to implementation
How to involve people from all disciplines in the design process and make them participate as well.
Product Managers, Engineering Managers