A reception desk checks in visitors and prints badges. A design team moves large files all day. A meeting room hosts video calls with clients. A warehouse scans orders on handheld devices. All four may run on the same network, yet each depends on it in a different way.
A network brief that lists switches, access points and a firewall says little about any of this. A brief that describes the work gives the designer something to design for, and gives the business something to test against.
Ask each team what it actually depends on
Short conversations with each department usually reveal more than a technical survey. For every team, record:
- The applications and services it uses most, and where they run: in the office, in the cloud or at another site.
- The devices involved: laptops, desk phones, scanners, label printers, large-format plotters.
- Where the work happens, and whether people move around while working.
- Which activities happen at the same time, such as Monday-morning video meetings across every room.
Include the systems that share the infrastructure without belonging to any team: cameras, access control, building controls, meeting-room equipment.
Not every interruption costs the same
| Activity | What matters most | Effect of a short interruption |
|---|---|---|
| Reception and visitor check-in | Reliable access to the visitor system and printer | Queue at the desk; workaround possible |
| Finance month-end | Access to accounting systems and files | Delay at a critical time |
| Client video calls | Stable connection in the meeting room | Visible to the client immediately |
| Warehouse scanning | Coverage across aisles and loading area | Orders stop moving |
A table like this is not a technical design. It is the business telling the designer where continuity matters and where a brief delay is acceptable. Those distinctions shape the design, and the questions the business should ask its internet and cloud providers.
Turn the brief into tests you can watch
A requirement that cannot be demonstrated is hard to accept. Translate each important activity into a scenario: a video call from the main meeting room, a large file transfer from the design area, scanning at the far end of the warehouse. Test them from the intended locations with the devices people really use, and record the conditions and any limitations.
Illustrative scenario. Imagine a design studio that signs off its new network after a speed test at the IT desk. The first week of real work shows slow file transfers in the studio corner, where nobody tested. A scenario written into the brief would have found it before handover.
Decide who owns the network after installation
Agree who holds the configuration, the administrative access and the documentation, and how ordinary changes are made: a new starter’s equipment, a department that moves floor, an extra camera. When additions happen outside the record, a well-designed network gradually becomes one nobody fully understands.
Plan for foreseeable change, not for everything
Discuss what is genuinely likely: another floor, a second site, more meeting rooms. Allow for those where justified, and write the assumptions down. Planned capacity for known growth is useful; an open promise to accommodate any future requirement is not a design.
Next step: Bring your main business workflows and site plans to BootNet before the infrastructure specification is finalised, so the design is measured against the work it has to support.