Why a process helps
A digital exhibit can look like a single object: a screen on a wall with something interesting on it. In practice it is a small project with content, software, hardware, building work and visitors all depending on one another. A clear design process does not guarantee a good result, but it makes the common failures less likely: a screen that nobody understands, content that arrives too late, or hardware chosen before anyone knew what it had to do.
The stages below are a general pattern. Real projects overlap them, loop back, and skip some when the exhibit is small. The order is still a useful checklist.
1. Idea and purpose
Most projects begin with a story, an object, or a gap in the gallery. The first job is to say, in a sentence or two, what a visitor should take away. Is the exhibit meant to explain how something works, let people explore a collection, or give a quiet moment of reflection? A vague purpose produces a vague exhibit.
Who the exhibit is for matters at this point too. A display meant for school groups is designed differently from one for specialist users or for people dropping in for a minute.
2. Goals and early research
Once the purpose is clear, turn it into goals you could later check. Writing evaluation goals at this stage is easier than trying to invent them after the exhibit opens. Front end evaluation is the usual way to learn what visitors already know and want before anything is built. It can be as light as a few short conversations in the gallery.
3. Brief, team and plan
A written exhibit brief pulls the decisions so far into one document: purpose, audience, content scope, location, constraints and who signs off. Alongside it, decide on team roles. Even a small museum needs someone who owns the content, someone who owns the build, and someone who can say yes or no. A realistic project schedule and an exhibit budget come from the brief, not the other way around. Both usually need slack, because content and approvals tend to take longer than expected.
4. Concept design
Here the team explores how the exhibit might work: what the visitor does first, what happens next, and how it ends. Sketches, flow diagrams and short written scenarios are enough. This is the stage to ask whether a screen is even the right answer. Sometimes a printed label, a touchable object or an audio piece serves the idea better.
5. Content development
Content is often the longest part of the job. Objects need to be photographed or scanned, text needs writing and checking, and permissions need to be cleared. Short, plain writing suits a standing visitor far better than long paragraphs, and anything with audio or video needs captions. Starting content work early, in parallel with design, is one of the most useful habits a project can have.
6. Prototyping and testing
Before building the final version, make something cheap and let people use it. Paper sketches can test the order of screens. Simple clickable mockups can test labels and button placement. Prototype testing with real visitors usually reveals problems the team could not see, because the team already knows how the exhibit is supposed to work.
Expect to revise. Findings from testing often change the flow, the wording, or the size of what is on screen.
7. Build and integration
Development, content loading and hardware selection come together here. The software should be tested on the actual screen, with the actual input method, in conditions close to the gallery. Display choices, mounting, cabling, networks and lighting all affect the result, and problems such as glare or an unreliable touch layer are far cheaper to find before the exhibit goes in the gallery.
8. Installation and opening
Installation is more than placing a screen. Check the physical height and reach for different visitors, confirm the exhibit restarts cleanly after a power cut, and make sure staff know what to do when something goes wrong. Many teams run a soft opening, watching a few days of real use before announcing the exhibit widely.
9. Handover, care and review
Good documentation lets someone who was not on the project fix or update the exhibit later. Project handover usually covers logins, file locations, supplier contacts and a restart routine. A maintenance plan names who checks the exhibit and how often. After opening, summative evaluation looks at whether the goals were met, and the findings go into the next project.
Common ways projects go wrong
A few patterns recur across projects of every size. Content arrives late, so the build is rushed. Hardware is bought before the design is settled, and then limits what the design can do. Testing is left until the end, when only small changes are affordable. Or nobody is named to look after the exhibit once it opens, so small faults go unreported for weeks. Each of these is easier to prevent than to repair: agree a content deadline early, choose hardware after the concept is clear, test while things are still easy to change, and give the exhibit an owner.
A note on flexibility
None of this requires a large team or a large budget. A small museum can run most of these stages informally, with a notebook, a few volunteers and a printed prototype. What matters is that each stage produces a decision that the next one can rely on, and that testing with real people happens while changes are still cheap.