How we use Loom across Product, Design, Eng and QA

Okay. So here's how we use the doom as part of our product design engineering and QA workflow. How loom compliments that just to set the context, we're a fully distributed team across every time zone in the world, practically.

Um, so we have 24, seven designer, Missouri product manager, that's in Harland and a developer in the Philippines, uh, in this example are working on a story.

Um, so we use loom, um, to basically, um, make sure that asynchronous communication can be as rich and meaningful as possible as a common core part of our, of our process.

Um, so here we're using notion actually as our public tracker. Um, so for example, we'll have our whole product stories in here, but doesn't have the mock-ups requirements and stuff at the top.

We have disinformation where you have like a PM nuMe. Um, you'll see. Also we have designers. So first kind of a PM, we'll kind of have a goal kind of explaining the story, setting the context again.

Um, that would be request central $8 billion button. Um, so you know, it does, Neeland trivial, then a mock up a Windsor kill.

I'm going to give you more context. I'm talking through it, blah, blah, blah. That goes into winter with respect and everything like that.

And there's Windsor mock-ups, whatever else we have we use for kind of workflow diagrams and stuff. Normally, if it was a bigger requirement, we'd have written a bigger point document back to it should be one for this, but it's not linked then designer hair, Jason, but he also, when he's ready for review, he sends it out to everyone for, um, before it goes to engineering as well.

It could be multiple passes of this, but here then he'll do, uh, up to spec. He'll do a version as well.

And just in case it's seven minutes, he jumps into that, you know, he drills into Figma and he gives us a walk through a Figma, kind of like adds the context and we can all get feedback on it.

So it's like a show and tell. So it's really, really powerful. Um, and that's pretty great. You can sit in all that in comments, blah, blah, blah.

We use that. And sometimes a common thing is a pain to try itself on loom is imperfect. Uh, and how we know about this is probably like Jason would drop into our slack channel.

He would drop into a design channel, Hey, this is ready. Here's the loom, have a look at it. Um, and he can capture all the feedback and then he'd do another version, drop it in there as well.

So everyone who subscribed to that slack channel kind of gets a notification of that. We don't organize these in any groups or anything like that.

We try and give them good label. Um, but apart from that, um, it's very, very powerful. You've not contextual comments, you know, great job, whatever, you know, background music, whatever it is, some internal jokes there as well.

But usually it's very helpful, um, where it does get a bit lost is like, oh, we got fig comments. We've got loom common Signum slack comments that we do have to figure that out.

And, you know, we've figured that out, but it works very well, um, for asynchronous communication. Um, then as we go down there, it gets assigned to engineering and engineering, pick it up and then great milestones, uh, depending on the task in get lab.

Now we're going to get lab and I'll show you how engineering then uses Lumada to be true as well. Um, I'm not as involved here right now, but for example, tag this up, um, the story has been created.

And then when the engineer kind of goes through a template to checklist, put an Allume walkthrough of the code. So this is stem opportunity code and also a demo of what they built as well.

So like they use it here as well. And kind of typically we have two ways, again, I'm walking through what they've done and the court would have to navigate that.

So something to code review to can much dispersed, um, and the QA team can look at this as well from the kind of demo of actually here it is working.

Maybe don't wanna show it in storybook or something like that, which is great. Um, so he walks through, you know, his implementation of that or any kind of any alterations from design that he's under.

He thinks they're a good thing to do. Then obviously we have QA, um, and they put in some notes here and it goes through the whole process.

We tag it up since moving on to place and then QA, when they have bugs, they record the books in loom as well, and draft them in there to give more context to the engineer what's happening.

Um, and again, the engineer can push the fixes on that. It gets processed and there we've got we're ready for staging ready for life.

So that's kind of how we use loom embedded at all stages. So product managers explain what we're doing, here's what it is.

Here's why we're doing it as more context and empathy to it. Design does exact same thing. They walk through it when it presented.

It's great for the handover and engineering. When you are handed over to other engineers for code review, they then do this, and then they create the decode and decorate the demo and then QA, that does that.

And then anytime we're using the app, we find bugs, we recorded them, submitted into our slack channel, and then they go into issues as well as the input to that as well.

So it just really goes high fidelity communication in an asynchronous way that allows us to be, um, you know, I think, uh, more communicated.

One of our core values is over-communicate and loom is the backbone of that. I would say.