/ work

Real-time Collaboration




Product Designer
Product Manager


Jan 2020 - July 2020
Desktop screenshot of Venngage editor with 7 collaborators. Set on a muted purple background.

How real-time collaboration increased the number of users on a Business Team by 10x

Working with a team of 3 developers I designed and led the transformation of Venngage from a single-editing experience to a co-editing experience in under 4 months.  Users can now work off of one single source of truth—avoiding the back-and-forth that comes with versioning. And finally, co-editing in real-time, giving users the flexibility to work with their colleagues effortlessly.  This led to a 10x increase of users on a Business Team—significantly impacting our annual recuring revenue.

The nature of work is changing

Venngage—a drag-and-drop design tool—was primarily used by individuals creating simple posters, invites, and diagrams.  Over time, this evolved into small teams at medium-sized companies using Venngage to create marketing materials, internal communications, or job-aids for HR departments. Workflows changed too, evolving from individuals creating, to teams collaborating. But Venngage didn’t. It was built for individuals, not teams.
With the rise of Google docs, real-time collaboration quickly became table-stakes. This, coupled with evolving user needs, fierce competition, and the increased need for visual communication gave us the impetus to explore this problem further. Our CEO viewed this as a strategic advantage if we wanted to increase our market share and eventually move into Enterprise. I was tasked with finding a feasible way to transform Venngage from a tool used by one to a tool used by many.

Stepping back to understand the problem

Although I was tasked with the problem to solve, I took a step back to understand the current collaboration pain points and hear from customers to understand their job-to-be-done.

Collaborating or file versioning?

I started by mapping out what collaboration on Venngage looks like today. I wanted to see the point of view of both the creator and the collaborator. Users were basically sending copies of the same design to collaborate.
A flowchart explaining how users collaborate on Venngage
How users on Venngage collaborate today

Hearing from users

I interviewed 5 Business plan users to get an understanding of their pain points. My goal was to understand how they use Venngage, how they’re currently collaborating, and who they’re working with. I asked users to give me real examples of common workflows and how they used Venngage within them. In parallel, I reviewed customer support chats from September 2019 onwards. Using an affinity diagram, I grouped like conversations and saw patterns emerge around “real-time”, “collaborate”, and “multiple editors”.
A composition of two screenshots of a spreadsheet used to organize user research
Qualititative research on collaboration and exisitng Business Team use


I distilled my findings into 2 distinct jobs-to-be-done (JTBD). This ensured that we understood the problem well beyond just “build real-time collaboration”. It served as a reference point for the team throughout the project.
Help me and my colleagues collaborate on designs effortlessly so that we don’t have to send our work back and forth
Help me get feedback on my designs from colleagues so that we can move my work forward

Contraints, constraints, constraints

Early conversations with engineering quickly highlighted the effort required to build synchronous real-time collaboration. On the impact-effort matrix it fell squarely in the top right quadrant—high impact, high effort. With 2 engineers (at the time) it would’ve taken considerably longer or we would have needed more engineers. We just didn’t have the appetite. Senior leadership wasn’t ready to make this bet. We needed an MVP.
An impact effort matrix of real-time collaboration vs a potential MVP

Building an MVP

Knowing the constraints we were working with, I turned to the JTBDs I identified earlier. If we can’t build real-time collaboration, what can we do to help users move their work forward?
I breadboarded a few options with the following in mind:
How might we help users avoid sending designs back and forth?
How might this fit within the existing app? This was especially important considering the constraints we were facing.
How can we minimize the effort but still achieve high impact?
A Shape Up Breadboard of a potential flow to allow users to collaborateA Shape Up Breadboard of a potential flow to allow users to collaborate
Breadboards of a potential flows of how users might collaborate

Working from a single source of truth

After presenting both options—feedback received and the given constraints pointed me towards an MVP where users can collaborate on the same design, just not at the same time. No more sending designs back and forth. No more versioning. No more weird design names.
A screenshot of the Venngage Home page. A modal is displayed letting the user know they can't edit this design at this time
The MVP where we let only 1 user design at a time

A note on user testing

Normally, I'd run a series of user tests to validate designs before building, but I struggled to build a prototype that would help us get meaningful feedback—especially because how integral a two-sided interaction is to this experience. So we decided to ship the MVP and gather feedback from our users.

Measuring success

Using a product metric framework, inspired by the Intercom product team, we defined and tracked 3 success metrics—intent, activation, and engagement.
a line graph showing the change of invited paid members week over weeka line graph showing week over week change of % of shared designs a line graph showing the change of the number of users that clicked to edit a shared design
With promising metrics, I continued to monitor customer support chats. Despite simplifying the collaboration workflow an overwhelming number of users asked for real-time collaboration. Of all the customer support chats that I reviewed post-launch, 69% of users mentioned either “real-time” or “multi-editing”
69% of users still mentioned either “real-time” or “multi-editing”
I interviewed 3 of those users to get a better sense of their feedback to customer support. Why were users still asking for real-time collaboration?
Interviews revealed that what users gained with real-time collaboration was a removal of friction. They wanted to do work on their terms—sometimes with others and sometimes alone.
It’s great and all but it would be even better if I could go in whenever I want to
Sometimes people leave their tabs open so I have to chase them down to leave the design
It’s just not what I’m used to

Iterating on the MVP

With promising metrics and a strong response from users we decided to take the leap & iterate on our MVP. With a big piece of the puzzle—working from a single source of truth—already solved, our attention moved on to synchronous collaboration, with co-editing at the heart of it.

The Co-editing Challenge

On the surface, co-editing seems simple. When someone edits something, everyone sees it. But it's a deceptively complicated problem.
I distilled the challenge into this HMW question:
How might multiple people work on the same design at the same time without getting in each other's way?

Developing a framework: Levels of editing

I started by breaking down the editor into what I called "levels of editing". Each level had a unique set of behaviours and different usage patterns. Setting the canvas size, for example, is very different than editing a text element.
This framework coupled with usage data helped me define co-editing behaviours.
Venngage editor annoted with the different "editor levels"
The Venngage editor "levels of editing"
Each action that a user can take in the Editor was then grouped into one of the levels:
Table of the different editor actions grouped into one of the levels of editing
Every editor action grouped into one of the editing levels
Once I split the editor up into these levels I began to sketch behaviours from the point of view of the Creator and the Collaborator.
Every editor action grouped into one of the editing levels

A balance of tradeoffs

With co-editing, we had to strike a balance between various tradeoffs. Users want to move in and out of designs, adding and editing without constraints while maintaining a feeling of control, knowing that their work won't be deleted or edited.
This was especially important with widget level editing. You wouldn't want someone to edit the same text you're editing.
We also had to worry about latency. It could cause designs to be out of sync and that would be terrible for a co-editing experience. We needed to know when someone was editing. We turned to the selection state. When a widget is selected, it's locked for everyone else. Once it's deselected, it unlocks and syncs across all collaborators.
When a widget is selected, it's locked for everyone else. Once it's deselected, it unlocks and syncs across all collaborators.


We noticed an immediate effect on our metrics of success once we released to 100% Business users.
# of paid member invites
invite/share funnel conversion
WoW # of unique clicks on shared designs
% of Business Users with >1 person on their team

Next Steps

While this was a massive step forward for Venngage, there are definite next steps that we can take to improve the co-editing and collaborative experience.
One that we had to scope out in our first release were real-time cursors and what we called “bounding box identifiers”. Both play an important part of “Presence”. They help co-editors orient themselves in the shared space quickly and effectively.
Something else that we’ve now begun to explore, is expanding on the share experience to facilitate co-editing and collaboration. Venngage is still heavily geared towards creating --> downloading. With a shift in how people work and Venngage’s real-time collaboration, the emphasis will shift from a world where people download files to sharing links.

Lessons learned

This was one of the most complicated projects I’ve ever worked on. It was a deceptively complicated design challenge and highly technical. Along the way I’ve learned some lessons I hope you can learn from too:

Get very clear on the job-to-be-done (JTBD) and ask yourself how every piece of the design is serving it. When confronted with a low appetite and huge technical constraints, we turned to the JTBD and built an MVP.
Tackle large problems by breaking them down into smaller units. It'll be much less daunting that way.
When facing a problem in an unpredictable environment (e.g. co-editing in a drag-and-drop editor), take a first principles approach to solving it. Using the selection state was my way of doing that.
Working with engineers is an art. I talked about it in this presentation I made on how our team worked together.

More work

Screenshots of 3 screens from a pharmacy app called Nimble. Set on a muted green background. Illustration of website wireframe and a bar graph set on a muted blue background.