The first thing I draw is not a dock. It is the computer that must receive the work. Starting there stops me from treating every socket on the desk as an independent entrance. I want a picture of how devices reach the host, with honest gaps where the documentation does not explain the route.
I am Tessa Ward, an entirely fictional editorial voice, not a technician reporting a tested setup. My map is a planning aid. It cannot certify a port, reveal a hidden controller or prove a performance result. In the main connection allocation article, I use it to decide which tasks deserve a shared connection at the same time. Here I explain how to make the map useful without disturbing a working system.
Begin with a desk you can describe safely
I make the map between jobs, not while someone is relying on a live edit or a transfer. I do not unplug devices to discover what breaks. I can usually start from a visual inspection, the system's ordinary device information and the documentation already available. If a cable disappears behind a heavy display, I mark its destination uncertain rather than tugging it out during production.
On paper I put the host at the top. I record the full model and any configuration detail relevant to its external connections. A broad product family can include different generations or options. I also note the operating-system version privately, because support statements may depend on it. I do not publish serial numbers, network details, client filenames or screenshots containing personal information.
Next I add the dock's exact model and revision if these are available without opening anything. A retailer's shortened name is not always enough. If I only know the family, I write that limitation beside it. A useful map should reveal weak evidence, not hide it behind a clean diagram. Unknown does not mean faulty; it means I have a question to resolve.
Draw one line for every physical hop
I connect host to dock with a line labelled upstream. Then I add the devices connected to the dock. If a display includes a hub, or a drive is reached through another hub, that intermediate device gets its own box. The diagram should show the actual chain, not the way I wish the equipment were organised.
A line is not a rate. At this stage it only says that a physical path exists. Beside it I can record a documented cable type or port label, but I do not infer support from the shape alone. A USB-C-shaped connector can appear in arrangements with different capabilities. The port and bandwidth guide explains why those labels need careful handling before they become capacity claims.
I use plain words for uncertain details: “dock downstream port, exact mode unconfirmed” or “display hub, documentation pending.” This is more useful than drawing every line in the same confident colour. When someone later finds the manual, they can replace an uncertainty with a source-specific statement without reinterpreting the entire desk.
Keep logical volumes separate from boxes
The file browser shows volumes and folders, while the desk contains physical devices. Those views do not always correspond one to one. An enclosure might present more than one volume, and an application may use a cache on a different volume from its project file. I do not assume that two visible names mean two separate external routes.
For planning, I add a small note under each physical storage box: the role it currently serves. “Current project media,” “approved handoff destination” and “archive access” are clearer than vague names such as fast drive. I avoid recording sensitive directory names. If a role is not known, I ask the person responsible rather than inspecting private work to fill the blank.
This step can reveal a false separation. An editor might think the application cache and original media are on different devices because their folder names differ. The map asks a narrower question: where are those files actually stored, and which physical route reaches that storage? It does not recommend moving them. Application changes belong to the relevant workflow owner and should follow its documented procedure.
Mark the places where routes join
I circle the dock's upstream connection because downstream devices can share it on their way to the host. Depending on the design, there may be other shared points inside the dock or computer. A consumer-facing port diagram may not disclose these. I write “internal arrangement unknown” instead of filling the gap with a guessed controller layout.
A separate host port deserves a separate line, but not an automatic independence badge. Two sockets may share internal resources, and host support can vary. I look for an explicit architecture description or ask a precise support question. “Are these particular host ports independent for this intended use?” is better than “Does the computer have enough ports?” The answer may still be qualified.
A chain also makes dependencies visible. A device reached through a display hub depends on that part of the path remaining available under the documented operating conditions. I do not deliberately switch off the display to test it during work. Instead, I note the dependency and consult the supported behaviour. A map is valuable before it becomes an experiment.
Add a second layer for time
Once the physical map is legible, I use a different pen to mark active tasks. A mounted drive is not necessarily busy, and a device that looks idle may be serving files in the background. I ask what the application and people are doing rather than trusting indicator lights as a complete workload record.
For a morning ingest, I might mark the reader, the intended destination and the current edit volume as potentially active together. For a review, I mark media access, display and audio requirements. These are examples of planning categories, not observations from a tested desk. They help me spot the point at which separate-looking tasks meet on the drawing.
The multiple-drive workload guide turns those marks into a schedule. I keep it separate because topology and timing answer different questions. The map says where work can travel; the schedule says when people need it. Changing one may help without changing the other, but neither guarantees a result on equipment that has not been checked.
Do not leave the display outside the picture
A storage map with no display is often a map of an imaginary creative desk. I add the actual display connection and its intended mode, not just the word monitor. Display support can depend on host, operating system, dock design and transport method. I do not translate a resolution label into a made-up data deduction from the upstream link.
Card readers, audio devices, network connections and ordinary peripherals also belong where they are physically attached. Not every device is a major data user at every moment. Still, omitting them can conceal connection dependencies or a reason that a different port cannot simply be reassigned to storage. The display and reader guide gives these everyday constraints their own place.
I record future arrivals in pencil. A borrowed reader on shoot days, for example, is part of the busy-day plan even when it is absent today. That helps avoid a diagram which looks adequate only because an important device is currently in a bag. Planned use is clearly labelled planned, not presented as verified compatibility.
Annotate power without pretending to design it
I put a small power note beside the dock and each device whose supply matters. The note names the documented source or says that it needs checking. It does not contain improvised electrical instructions. A host charging through the dock and a peripheral receiving suitable power are separate matters, even when both use the same physical connector family.
Cable identity belongs on the map too. I might record the maker's supported cable supplied with a device, or mark an unidentifiable lead as unconfirmed. I do not infer its data rating from its thickness, colour or how quickly the computer appears to charge. A cable can be a relevant variable without being the automatic culprit for every delay.
The power, cable and enclosure guide develops a safe checklist for these questions. It stops short of opening cases, swapping power supplies experimentally or writing data to provoke a failure. If equipment becomes hot in a concerning way or behaves unreliably, the map helps describe the issue to support; it does not authorise continued use.
Turn gaps into answerable questions
I finish the map with a short unknowns list. Each entry names the component, the uncertain claim and the consequence for the plan. “Need supported display mode with this host before reserving the upstream path” is a better note than “check performance.” It tells the next person what decision is waiting and why the answer matters.
I also distinguish the type of evidence I need. A manual may establish a supported mode. A manufacturer may clarify a revision detail. A relevant, authorised observation can describe a particular workload. None of those automatically establishes all the others. I do not use a forum anecdote about a similarly named device as a substitute for exact compatibility information.
When an answer arrives, I record where it came from and the conditions it covered. If it only addresses one operating system or one cable arrangement, that condition stays attached. This prevents a precise answer from becoming an overbroad team rule. Documentation can also change, so I retain the date of the note rather than implying that it remains current indefinitely.
Hand over a map, not an assurance
A good handover has three parts: the drawing, the assumptions and the unresolved questions. I can explain which jobs are likely to meet on a shared path, but I cannot promise a transfer rate from that fact alone. A clear map is a starting point for a supported arrangement and sensible scheduling, not a certificate that the desk will tolerate every simultaneous demand.
I explicitly keep data protection out of the diagram's implied promises. Two drive boxes on separate lines do not prove two usable copies, retention or recovery. The backup and purchase guide separates that decision from choosing a connection. Real backup and IT policies still apply regardless of how tidy the map looks.
I review the map after a significant host, dock, display or workload change. I do not redraw it daily for its own sake. Its job is to make the next practical discussion shorter: which path carries the work, what else joins it, and what remains unknown? If those questions are easy to answer, the drawing has earned its place beside the desk.