A Beast Called Disco: How to Streamline Design Discovery Processes and Make Life Easier for Your Team
Hello everyone! My name is Tanya Konyushenko, I am a product designer at Cooper. In this article, I will tell you how I discovered Design Discovery and implemented it in my product team. I think my experience will be useful for designers who have heard a lot about Disco, but do not understand what it means.
A year ago, I knew nothing about Discovery because I worked in custom development. I talked about the difference between designers in an agency and a product in in his previous article.
When I came to Cooper (it was still SberMarket back then), I was immediately introduced to the concept of Discovery, but I didn’t see the point in it. Now my attitude is completely different. Discovery is good, but it needs to be built correctly. My path to ideal processes was thorny…
But let's take it one step at a time. What is included in Design Discovery and how does it differ from the general Discovery team?
Design Basics-Discovery
Anyone who works in IT knows that in the development of new product features and support of old ones, there are two sequential processes:
Discovery – these are all the actions before the start of development.
Delivery — everything related to code creation.
Disco includes:
idea generation;
analytics on existing events, that is, on statistics that the product has already collected;
study of the research conducted;
creation of designer layouts;
quantitative tests of layouts;
UX interviews with respondents;
coordination with teams;
final preparation of layouts.
If you look at this process from a designer's point of view, you will find two partially parallel processes: design-disco (stages 1-3, 5 and 6) and design planning (stages 4, 7 and 8). In addition to the designer, the Design Disco involves a product manager, analyst and researcher.
Design disco ends the moment we answer the questions “what?” and “why?” — all that remains is to polish the solution, create a roadmap for the update, and implement what was planned.
I will show you what Design Disco is using a specific example.
A story from life
At the final stage of placing an order in Cooper, the buyer must select the time range in which the courier will deliver the order.
Sometimes people skip this block, which prevents them from completing their order and breaks the conversion.
We ran an A/B test where we implemented pre-selection of the first possible slot. The number of errors dropped, but the number of cancellations increased significantly.
At the Discovery meeting:
Together with the analyst, we came up with a hypothesis that the block is poorly visible, so users skip it, but the delivery time itself is important to them, and therefore automatic pre-selection leads to an increase in cancellations.
We did a lot of benchmarking (competitor analysis) with the product, and I drew up a lot of different solutions.
Then, together with the product manager and researcher, we selected several options that were to be sent for research.
The main selection criteria are clarity, flow simplification, and scalability. Scalability means that the new time slot display option fits into the screen development plans (and we can plan within Discovery for a quarter or several quarters in advance).
For this task, we opted for quantitative research to make sure that in practice people would not have problems with changing the delivery time. There were several iterations: separately we tested for comprehension, separately for First Click, separately for text formulations (which one is read unambiguously).
In our research, the two versions showed almost equally good results, so instead of an A/B test, we decided to do an A/B/C test and compare the old design with two new versions at once.
Seems logical, right? But there is a nuance: the ideal process does not emerge by itself, someone has to set it up…
And most often, this is the person who suffers from uncertainty more than others. Because anyone can build a process and manage it, not just a product. You just need to have the desire to systematize information, set tasks, clarify statuses with everyone, and conduct meetings.
Acceptance stage: denial
During my onboarding at Cooper, I, on the advice of my lead, set up meetings with three senior designers who had already established such processes in their teams. They told me what they were doing and how, and I listened to them with a smart look and even asked a few questions.
And then I went to implement Disco in my four small teams. I set the Discovery meeting on the first Monday of every two weeks, and the Planning meeting on the second Monday. We got a Discovery sprint and a Planning sprint, running in parallel, with a week's shift.
The teams entrusted to me previously consisted only of developers and did not work with designers, so the design processes were entirely within my area of responsibility.
As a result, every week I received new tasks for two weeks in advance, they were mixed up in my head and in sprints. The situation was complicated by the fact that the product managers from my teams periodically missed meetings, and then scheduled separate calls with me. Analysts came honestly, but I did not understand what and when to ask them. Also, at that time we did not have a dedicated researcher, and we had to knock on other teams for help.
After living in this mode for about five months, I made a strong-willed decision to delete the Disco meeting from the calendars. We did the same thing there as we did during planning anyway – discussed tasks and progress on them.
The Discovery process was found to be broken and unclear. I suspected that this was a pointless meeting for the sake of a meeting.
Without debugging Disco you won't get far
A couple of months after I rejected the Design Discovery process, my team composition changed: there were only two of them left on a regular basis (not counting occasional help for colleagues).
It would seem that it would be easier to focus this way. But no, the switching between tasks continued: we planned one thing, then abruptly changed course to another, and then returned to the first.
And then a demo meeting happened, at which a senior designer from our company told about her experience of debugging Discovery processes within the team and offered to help everyone interested.
At Dasha's there is an article about life hacks on how a product designer can improve Discovery processes in a team, this is exactly the experience that became the starting point for me.
We called each other. I wasn't so much interested in Discovery (I still didn't see the point in it) as in how to increase productivity and make work more understandable. I also wanted to know how she had twice received an A+ in the Perf Review – our equivalent of a 5+.
Dasha helped me make a list of problems:
chaos with task prioritization;
hypotheses and demands get lost in personal messages;
it is not clear what the development is doing;
there is no separate place to store analytics and research results;
analysts and researchers are given tasks without the opportunity to participate in the development of hypotheses;
no one understands the result of the work (what happens to the task later);
There is no discussion of the results of A/B tests – and it is unclear when they begin and end.
And then Dasha suggested bringing back Discovery meetings. But first, only for one team.
Second approach
It would be unfair to say that one meeting cleared everything up. It didn't. Rather, I saw a path I could take to make things better.
I gathered all the members of the Disco team. In addition to me, there is a product manager, a researcher, three analysts and (in fits and starts) an editor. And I prepared the work environment:
Started a separate chatso that we can discuss tasks and news, as well as record meeting summaries and sprint agreements.
Created a page on the internal wikiwhere I began publishing topics, as well as links to all the results of research and completed A/B tests.
Returned regular meeting on Discoto discuss tasks that will be worked on, priorities, routine work, results of A/B tests and research. Since the backlog is large, we decided to meet once a week.
From the title page of the Discovery section of the wiki:
Task plan for the quarter
Design planning in sprints
Tasks in Jira
Prods in Jira
All about inclusivity
UX Research (drop-down list of links with dates)
Analytics (drop-down list of links with dates)
A/B tests (drop-down list of links with dates)
Agreements with other teams
Backlog
The first meetings were not ideal, but successful. The analysts brought the results of the latest research. The researcher got an understanding of when he would be brought the mockups for research, and gave us his workload (since he also works with another team).
The whole team began not just receiving tasks, but discussing their appropriateness. We started arguing!
The product seemed to believe in my abilities and suggested that from now on I would record design changes and logic in the functional requirements for developers myself. And this turned out to be useful: developers look closely at FT and not so closely at mockups.
By the fourth meeting, we had cleared out the backlog and found a rhythm to be able to analyze all the necessary data before starting to work directly on the mockups.
At that moment I finally understood the meaning of Design Discovery!
Design Discovery is a process that helps unite the team, make work on tasks transparent, inform each other about the results in a timely manner, systematize the data already received, and plan normally for several sprints ahead.
After a month and a half in the new mode, I collected feedback from colleagues. There were no obvious problems, but we identified growth points. The meetings lacked structure: a clear agenda, i.e. a list of topics, and timing (we could only discuss one topic throughout the entire meeting).
End of A/B Testing Chaos
We are constantly testing. That's why there are a dozen iterations living in the mockups at the same time, which suddenly become relevant (or not).
Moreover, we are not the only ones running tests. Other teams may be running something that is within our area of responsibility. For example, the loyalty team may be adding something to the cart design to improve their metrics. Loyalty has a new component in the design, but I don’t.
I compiled a table right in Figma for all known A/B tests that directly or indirectly relate to our team, and once and for all stopped getting confused about which layouts are current and which are outdated.
It's simple: title, link to layouts in Figma, A/B test period, test result, and product name.
Such a table not only helps with synchronization, but also visualizes the work process and gives the opportunity to discuss with the team how much has been done and how great we are 🙂 In addition, I have something to bring to the Performance Review.
What else did I add?
I started showing the team intermediate mockups to increase the sense of involvement. It really works, the guys watch with pleasure!
I also started attending the Delivery team’s daily meetings more often to keep my finger on the pulse and communicate goals to the Discovery team as transparently as possible. This is also effective: everyone likes to see how the work is transformed into the final product.
High level – bring to meetings news from other teams that in one way or another concern us, and thus also increase transparency.
So what is the benefit of Discovery processes?
Our team has been freed from uncertainty. Everyone has a clear understanding of who is working on what, what will happen next, what has already been done so far, when we expect the next results and what these results are.
We have sped up design planning because all tasks are discussed and researched in advance. The product may change priorities, but additional meetings to discuss functionality are not required in this case.
We also deliberately reject some potential tasks if analytics show that it is pointless to take them on.
Some features end up in the backlog — again, because we decided to do so, not because we failed to plan. This happens when a feature depends on many teams; for example, if a bug is rooted in the home page, it’s strange to start fixing it from the trash.
New team members integrate into the process faster because it is already thought out and structured. And all team members know what they can influence and what the point of their work is. When our Discovery processes had already settled down, I received feedback that the guys in our team are more proactive and often offer something of their own.
More clarity – more satisfactiondo you agree? And after I set up this process, I was able to get an A+ for my work and finally became a Senior 🙂
Tell us in the comments about your life hacks in building design processes!
SberMarket's Product&data team runs social networks with news and announcements. If you want to know what's under the hood of a highly loaded e-commerce, follow us on Telegram and on YouTube. And also listen podcast “For tech and these” from our IT managers.
