It should come as a surprise to no one that I’m a huge fan of pattern libraries. They are the ideal deliverable to define a design system on the web—both from visual and front-end perspectives. But while a pattern library is ideal for defining what something should look like, it can fall short of defining how something should work.
I’ve often felt that the most challenging part of being a designer is not the actual solving of design problems, but the communicating of those solutions to others. There isn’t one traditional deliverable for UX decisions, and so it’s up to the designer to decide how best to explain these decisions to their team (or client) so that they can be implemented properly. In the past, I’ve created complicated flow charts that explain every possible turn a user can take, and what should happen at each interaction. Or, I have used a tool like Invision to link mockups together into a clickable journey.
While these get the job done, they’re far from ideal. They require a lot of explanation and documentation, and since they are disparate from the rest of the design documentation in the pattern library, they run the risk of becoming out-of-date, lost, or forgotten. One of my favorite things about the pattern library is that it’s central point of reference, and always up-to-date. So why not include user journeys as part of this artifact?
If your pattern library adheres to Atomic Design principles, you should have all of the components needed to link things together and create a clickable proof-of-concept without much effort. It may not be fully functioning, but it will eliminate the need to have any other design reference points.
What I love about the idea of adding “flows” as a design pattern is that it fits right into the Atomic design methodology of starting with small, basic components and then adding them together to create more specific blocks. A flow is just two or more pages put together, just like a page is two or more organisms put together, and an organism is two or more molecules put together.
Flows still need some documentation to explain exactly what they are demonstrating, as is the case with most patterns in the library. You could simply add a text description, or annotate your pages directly with a tool such as Metaframe. The important thing here is that you are using up-to-date design patterns to demonstrate flows, and that every piece of your design is documented in one central place.