Design by studying and testing with users (2 of n — Product management from ground up)
The prelude
Townscript with its steady growth in the Do-it-yourself events marketplace has assimilated all the features that a contemporary event organizer may need but sometimes at the cost of a delightful and intuitive user experience. Our aim in making our product(s) market leaders was clear with the vision in sight — a process that involves regularly interviewing users, getting their inputs, prioritising the pain points, conducting design sprints, testing prototypes, iterating over them and bam the solution is here (a comparison with how product is a human body and it needs regular diagnosis, prevention and cure to keep it fit). While we made couple of failed attempts at different steps of the process, we never let go of our determination. Our fresh UX designer, Sanketh Sampara was full of energy — the only things we needed were someone to
guide us with at least our first project and obviously a project. Looking back at our product backlog, our past user interviews and discussions with internal teams, we decided to improve our download attendee data flow as our first step into the culture of DPC.
The Help
Looking at our enthusiasm, our co-founder Sachin Sharma took to himself to get us connected with someone to help us out. He reached out to his friend Swaminathan Jayaraman and got the ball rolling with our introduction meeting. Swami’s passion for UX design lit the first lamppost on our path. He agreed to conduct sessions with our whole product team on the importance of and his experiences on conducting user interviews to finalize the exact problems that are to be solved. The team got to understand the process with a couple of mocks in which the power of asking the right questions was revealed. Once completed, the team signed off with a promise to ask the right questions, identify the problem being faced by the user and take a collective responsibility of solving user problems
Preparation
Our coach on this, Swami had given us an energizing prep talk and now it was time to prepare ourselves for this exercise. A step-by-step preparation was followed.
- Noted all Jobs to be done based on our past interactions with organizers
- Prepared a nice looking script with details on persona of the organizer, context in which the organizer used attendee data and what was the end use that the data was put to, and of course the goal of our study
- Listing down the qualified users (from major event types and attendee size)
- Sending interview invite to these organizers and scheduling interviews with them
Interviews
After going through a tough part of scheduling the interviews with users, our interviews started. Each interview presented different challenges ranging from discovery of the lurking needs of organizers to filter only relevant information, discovery of shocking scenarios wherein organizers do not even use the platform for data but rely on notebooks. Our UX designer interviewed in depth all the users and derived exact problems that we should focus our efforts on. We had some key findings from the interviews.
We shared all the above findings with our development team to make everyone feel what users feel while using the functionality and what are the end goals that they are trying to achieve.
Design Sprint
After knowing what organizers need, the time was to find a solution and what is better way than to do it collaboratively. This is where we follow Google’s design sprint process but only in spirit and not specifically with the same time frames. Below is what we did.
- Stage 1: recruiting the design sprint team. We got a QA engineer, a developer and a customer success team member to find the solution with us
- Stage 2: shared the findings with the team and noted down all the problems that are being faced and hence need a solution. Prioritized the problems — well, not really since there were only a few to focus on (We skipped formally making the user map at this step)
- Stage 3: Each of us came up with his/her favorite elements or components that solve similar problems in other products/platforms
- Stage 4: We then created our individual sketches and put them on board to discuss them out in details
- Stage 5: We finalized on what may be the best option of solutions for organizers
- Stage 6: Recruited organizers for the test and Created the prototype in parallel.
- Stage 7: Created a test plan with the tasks and scenarios that an organizer would carry out to validate whether our solution is good
- Stage 8: Tested with the real organizers. This may come as a simple step but one of the most difficult things since we had to do couple of mocks to hone our questions and the way we interacted with users. Not all organizers we recruited turned up for the tests and we ended up conducting tests on only 4 organizers. Even though 4 is not big but we had started seeing a pattern that while downloading attendees’ data users did not expect filters (basic or advanced) to be applied outside the download modal. We then made small iterations on the design to bring out the correlation between applied filters and download of attendees.
