Diagram and flowchart walkthroughs
Add context to complex diagrams in a digestible, efficent way with Loom's async video platform.
Transcript
Show Transcript
Hey, I'm Justin from the product team at Loom. And what if my favorite use cases for Loom is using it to record a voiceover over a diagram or a flow chart?
The thing about these kinds of visual assets, whether you're talking about an PRD or UML diagram on the end side or something workflow related, like I'm going to be talking about here.
There's only so much context you can provide in the diagram itself without hurting the value of the diagram. And so Loom is a fantastic tool for being able to walk through a workflow or diagram in a way that is shareable with other folks discussable by other folks.
So when I actually walked through this real life diagram, I think it probably was about 10 minutes of living. I'm going to do a sample of that in a real life walkthrough.
So here we go. Hey folks. So this is the execution flow that I'm thinking about for our delivery as we're moving forward this quarter.
So it's pretty similar to what we've been talking about, but really trying to get to the product team, the full product team involved as early as possible in clearly delineating how and product design and data are all going to be working together to identify solutions as a product team and not just going off into our own respective silos, I'm working on things independently.
So it all starts with a user story that can be defined by anyone. And that we're going to bring that to a cross functional solution workshop where we all work together on what the solution can look like.
And if we don't know enough to actually have a solution, we can gather more information here. This could be engineering led with the technical spike.
It could be design or product fled for user research. It could also be a data investigation. So get the information that we need in order to solution it and then break it down further.
And then when we're at a point where we actually have a really defined user problem in a really defined solution that we want to try out, we go through the actual design process.
So this is going to be not just UX design, but also data requirements, product design, technical breakdown. And we, from that, we'll have a very specific list of what do we need to do to ship this thing into just very specific atomic units that we can all work on.
And then we just iteratively work on that and we ship as soon as we can. We're going to be pulling stuff off the queue of items, as soon as it's available by priority.
And this way we're going to be spreading knowledge across the team and not just having single IC doing the work.
Everyone is picking up work as they become available. And that way, when we're maintaining this down the road, everybody will have knowledge as to what we've built.
As we ship, we ship continuously behind feature flags. We start laying out the go to market plan and documenting what the support team needs.
And then we continuously are launching and experimenting that leads to learnings and those learnings go back into the future definition of user stories.
So that's what a walkthrough would look like. In reality, there's probably even more depth that you could provide. You could use timestamp notes in the description to chapter that so that folks can come back later and look at specific items just to review their understanding without needing to watch the whole thing over again.
And it's just a fantastic way of level setting within a team and within a group of stakeholders so that you can take this diagram and really bring it to life with a Loom.
Transcript
Show Transcript
Hey, I'm Justin from the product team at Loom. And what if my favorite use cases for Loom is using it to record a voiceover over a diagram or a flow chart?
The thing about these kinds of visual assets, whether you're talking about an PRD or UML diagram on the end side or something workflow related, like I'm going to be talking about here.
There's only so much context you can provide in the diagram itself without hurting the value of the diagram. And so Loom is a fantastic tool for being able to walk through a workflow or diagram in a way that is shareable with other folks discussable by other folks.
So when I actually walked through this real life diagram, I think it probably was about 10 minutes of living. I'm going to do a sample of that in a real life walkthrough.
So here we go. Hey folks. So this is the execution flow that I'm thinking about for our delivery as we're moving forward this quarter.
So it's pretty similar to what we've been talking about, but really trying to get to the product team, the full product team involved as early as possible in clearly delineating how and product design and data are all going to be working together to identify solutions as a product team and not just going off into our own respective silos, I'm working on things independently.
So it all starts with a user story that can be defined by anyone. And that we're going to bring that to a cross functional solution workshop where we all work together on what the solution can look like.
And if we don't know enough to actually have a solution, we can gather more information here. This could be engineering led with the technical spike.
It could be design or product fled for user research. It could also be a data investigation. So get the information that we need in order to solution it and then break it down further.
And then when we're at a point where we actually have a really defined user problem in a really defined solution that we want to try out, we go through the actual design process.
So this is going to be not just UX design, but also data requirements, product design, technical breakdown. And we, from that, we'll have a very specific list of what do we need to do to ship this thing into just very specific atomic units that we can all work on.
And then we just iteratively work on that and we ship as soon as we can. We're going to be pulling stuff off the queue of items, as soon as it's available by priority.
And this way we're going to be spreading knowledge across the team and not just having single IC doing the work.
Everyone is picking up work as they become available. And that way, when we're maintaining this down the road, everybody will have knowledge as to what we've built.
As we ship, we ship continuously behind feature flags. We start laying out the go to market plan and documenting what the support team needs.
And then we continuously are launching and experimenting that leads to learnings and those learnings go back into the future definition of user stories.
So that's what a walkthrough would look like. In reality, there's probably even more depth that you could provide. You could use timestamp notes in the description to chapter that so that folks can come back later and look at specific items just to review their understanding without needing to watch the whole thing over again.
And it's just a fantastic way of level setting within a team and within a group of stakeholders so that you can take this diagram and really bring it to life with a Loom.