UX case study
02

Story index for AgUnity: a solution for collaboration with a transitional global team

Just a little something to improve handoffs and collaboration

First implementation: June 2023

Picture this: you are in a small but global team that is not able to meet all at once. You need to keep everybody in the loop about the story you are working on: another designer, an ever changing team of developers, your product manager, marketing team, and sometimes a client as well.

We worked hard to make fast delivery but something always got misunderstood along the way, fell through the cracks or we even were straight up missing parts of functionality we wanted to deliver.

I found myself in that scenario over and over at AgUnity. Every time a new quarter rolled in and we had another project plan, I kept wondering how we could make the communication better and make sure stories are being executed on properly and efficiently. This led to me putting together what I called a “story index”.

Visual for what the story index looks like in Figma

This is essentially how our design files looked like zoomed out at the time of hand off (in this case 1 Figma page = 1 story).

Story description

The usual “as a user, I want to...” or just a note along those lines

Context

Anything relevant to those seeking more context behind the story at hand. Such as any writing from the client, UX artefacts/thinking, links to other documents to refer to, etc.

Those would be gathered via many methods and not really well documented in an easy to find way, so placing here the ones related to the story was handy.

Flows

Broken up tasks our user would be able to do once this story was delivered. Here specify which user(s) will use this we go through each step of the task.

This facilitated many things: walking through designs in meetings, use as reference for questions and discussions at any point of development, client testing and back and forth with QA, easily identifying anything that could be split into another story to avoid scope creep, easily identifying any gaps in what we want to deliver and so on.

Components

List of any UI components that were added or modified because of this story. With links to them in the component library file (most of the time).

Pages

Any existing or new pages this story covers. When listing pages weren’t relevant (like when working on our mobile app) I would just remove this section.

Requirements

This is a culmination of notes, literally anything, that those involved need to know to deliver this story.

Including but to limited to: product requirements, specific user needs, notes about implementation decisions we made when reviewing or handing off to devs, about how things should display, etc.

Behaviours & special cases

Anything else that is part of this story but can be visually explained separately from what a flow covers. This is so that main flows are not too convoluted.

Such as: empty states, error states and validation, scrolling behaviour, specific responsive behaviour, how other features may affect this one, and so on.

Why in Figma?

Other than the introduction and initial discovery, the story designs in Figma were always used as reference throughout our development cycle (product team brainstorm, client presentations, design reviews, hand offs, even 1 on 1 question sessions with the devs).

Was the story index always put together linearly with great level of detail?

No, for most of the cycle (as above) I would take ad hoc notes, in somewhat the shape as you see above. Then I would do an effort to at least clean stuff up and finalize it to be in a readable state for the hand off, but there could be updates, changes, or fixes even after as we had more devs eyes on it.

Why do this?

Honestly to keep my sanity. Keeping track of so many answers and versions of explorations we’d done for multiple user stories at a time was just getting too much.

Did it work?

It didn’t solve every single thing, but after a few months using this I could finally feel like the people involved were on topic more often than before and frequently using it as reference, and we were delivering cleaner features so I would call that a win.

Thank you for reading!