Use Case: After a discovery session, you've understood there are custom solutions necessary to meet the requirements of a desired workflow or process.
Approach: staring blankly at dev docs hoping for a lightbulb moment
Problem: You literally don't know where to start. Even if you did magically find the right path forward, how do you start to illustrate the idea to get others on board with your thinking?
The above board is a full export of a single file I have set up in Figjam that I've built for the singular purpose of explaining Shopify's Checkout Extensibility suite both internally to my team, and externally to merchants and partners.
Note: There's nothing proprietary in here - it's almost literally a re-imagining of the public dev docs.
But it didn't start it's life as the library of assets it's turned into - at first, it was a personal board where I visually mapped out the new tools and APIs that I had to learn. The practice of building visuals for the concepts helped sear them into my brain, and it was the first step towards truly being able to teach them to others effectively.
Something I know intrinsically about myself is that I only respond well to information when it's presented beautifully. I resent when I have to stare at some convoluted and ugly chart while also trying to parse the information within it. Anecdotally, I've also found that to be true among wider swaths of people, especially those in large and distributed teams.
The most detailed documentation asset is rarely the one that gets shared the most. The resource that gets the most attention will be the one people feel good about sharing with others - and they're more likely to feel that way when the presentation is clean and enjoyable to interact with.
To that end, over the past couple of years I've developed a personal 'design language' that I adhere to. It's multi-purpose:
-
Gives me a starting point that's already about %25 of the way done. The framework is already there for me, I just have to fit my ideas into place.
-
Allows me to put my own 'stamp' on assets I create, so colleagues know who to contact for more information.
-
Keeps my presentations consistent between conversations that might be ongoing for months.
As an example, let's look at a workflow template I have set up for custom checkout process solutions:
I use simple black for primary processes, a black outline for secondary, a big bold colour for tertiary processes, and the same bold colour outline for quaternary. I have options available for fifth, sixth, seventh... if I ever get to eight, I guess I'll just panic.
I've got a little asset I can pull in to illustrate decision trees. Icons are used to illustrate common pieces of the puzzle that I might need to represent. There are even brand logos ready for the most common software and services that may need to be integrated into the workflow, depending on the current tech stack that I need to consider.
(As an aside, this is one reason why I love Figjam for this work. Not only is it flexible as a brainstorming board with a large team, but it has plugins for icons and company logos that I can just pull into my diagrams at any time without needing to leave my space.)
Once more, this is set up so that I can jump immediately to brainstorming a solution, without spending any time or effort on defining it's structure.
A very simple final example may look like this, a workflow diagram for pre-selecting a preferred payment method based on customer tags [a method worth it's own little post later on]:
This works really well for 'swim lane' style workflows like those above, but what about architecture diagrams that have a lot more complexity?
I have an alternate design template for those assets, to be more in line with what's expected in a professional sense from technical diagramming. However, I still like to introduce quality-of-life elements into design to help those less familiar with the concepts grasp what's being presented.
A tech stack diagram I'll design typically follows the conventions I've set out in the example above.
Flat, clearly legible in colour or converted to monochrome, with technologies grouped within boxes, while their relationships are contextualised along the process arrows that connect them. Whenever possible, I try to keep it close to a 3:2 aspect ratio, making sure it'll fit neatly within a slide deck or in a document (horizontally).
It's also highly modular, so I can reuse pieces across designs whenever the situation calls for it, which is maybe best illustrated by this highly abstract tech stack that I use to introduce total newcomers to the mere concept of what Shopify offers out-of-the-box.
This diagram could become vastly more complex just by adding more detail into the downstream and peripheral integrations that would feed the various services in place. It could also become much simpler by removing pieces that I know the solution doesn't require and culling detail from what Shopify offers (eg. just listing products, orders, and customers in the 'Backend' section if that's all the business cares about storing in Shopify).
I like including icons representing each box to clearly identify the category of each piece, and to help fill blank space where necessary. I can also subtly convey suggestions through logos, such as the common hosting platforms I've listed alongside the 'Self Hosted' box in the top-left corner.
If I'm tailoring it specifically to a business' existing tech stack, I'll often re-create the diagram they provide me and incorporate my re-build of their stack into my own additions. (If they haven't provided me a diagram to reference, I'll use what I learned from discovery to approximate a best guess of data flow.)
Over time, similar to the workflow templates, I've developed a generic file to begin with for tech stack illustrations, so that I very rarely have to go looking for logos and icons to represent various services and technologies specific to the solution.
Summary:
-
People connect with ideas they can see and easily understand. Supplement your writing with clear visuals that everyone can share.
-
Eliminate your 'writers block' by developing templates that structure your brainstorming sessions.
-
Prioritise re-usability into every asset you create, not just for you, but to provide your team with good resources when you inevitably move onto new challenges.
âď¸