Shane Murphy on Setting Boundaries for a Cambridge Charity Demo

Fictional example: a small charity being imagined for a design exercise in Cambridge is planning an internal demonstration of a proposed app. The charity has no real name, staff or operating history. Its fictional organisers want to understand what an app journey could look like before deciding which questions to ask next. This is a useful setting because demonstrations can create confidence quickly, sometimes faster than the underlying concept deserves.

As Shane Ian Murphy, founder discussing the Global Secure App concept, I would want such a session to begin with a precise statement of purpose. Are participants evaluating language, navigation, a hypothetical sequence or an actual service? A polished prototype can blur those categories. The desired direction for Global Secure App should make the distinction visible enough that a late arrival or a person seeing a screenshot still understands what is being shown. One spoken caveat at the beginning is insufficient.

The fictional organisers first prepare sample records. Each should be clearly marked as invented. Names, figures and statuses should serve the explanation without resembling evidence of real activity. A demonstration of an overview can use neutral placeholders and still be useful. There is no need to create apparent testimonials, customer histories or success stories. The aim is to expose how information would be arranged, not to borrow credibility from imaginary outcomes.

Next comes the session agenda. I would divide it by questions rather than features: can someone locate the relevant details, distinguish a draft from a submitted action, and identify where an external organisation would enter the process? These are observable questions. They also allow participants to identify missing information. A tour that moves smoothly from one attractive screen to the next may feel complete while leaving those fundamental distinctions unexamined.

For the proposed Global Secure App, any provider dependent step would need particular care. A prototype can illustrate a possible handoff, but it must not imply that a provider is contracted, that coverage exists, or that terms have been agreed. The appropriate label would explain the hypothetical nature of the step and the questions still unresolved. That may interrupt the visual flow, but the interruption is useful if it prevents an inaccurate understanding of readiness.

The fictional charity also needs a way to record questions without turning them into promises. An organiser might ask whether several people could have different access roles. That question belongs in a requirements discussion until feasibility, responsibilities and actual behaviour are established. Writing “requested for investigation” is more honest than casually agreeing that the feature will be included. A demonstration should produce a clearer list of uncertainties as well as reactions to the proposed interface.

I would make room for deliberate failure cases in the session. What does the concept show when information is missing? How would the interface distinguish an unavailable explanation from an incomplete action? Can participants recognise a screen that is merely illustrative? These exercises need not dramatise risk. They make the limits of the model concrete. A prototype that can only demonstrate its ideal path tells us less about whether its language remains useful when circumstances differ.

After the session, the notes should preserve the difference between observation and interpretation. “The participant looked for the summary under this heading” is an observation within the exercise. “Charities prefer this structure” would be an unsupported generalisation. The fictional setting cannot establish market demand, and a real small session would not establish it either. Keeping conclusions proportional makes the work more useful because the next design decision rests on something that was actually examined.

The Cambridge planning example ends with a better brief, not an endorsement or a launch announcement. That is what I would want from an early Global Secure App demonstration. Participants should leave knowing which parts they assessed, which assumptions remain open and what evidence would be needed next. A concept benefits when its limits can be discussed plainly. The most responsible demo is one that helps people ask sharper questions, including questions the founder cannot yet answer.