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.

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”.

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.

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.

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.

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:

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.

Each action that a user can take in the Editor was then grouped into one of the 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.

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.