Product
AstroObservatory — sky exploration and remote telescope control, mobile
ASTROOBSERVATORY · REMOTE TELESCOPE CONTROL · ZERO-TO-ONE MOBILE PRODUCT
AstroObservatory: Shared Access to a Telescope Fleet
A mobile product design connecting sky exploration with shared telescope control, using clear availability states, bounded sessions and role-based access
- Zero-to-one mobile product design
- An access model chosen over the category convention
- Four-state availability that scales with the fleet
- Sessions bounded, visible and self-releasing
The 30-Second Version
One unlimited half · one shared half
I designed AstroObservatory to connect sky exploration on a phone with live control of a real telescope. The sky browser supports simultaneous exploration; access to each physical instrument is exclusive.
The design separates browsing from control: a user claims an available telescope, enters a time-limited session, then releases it back to the fleet. The case study documents this design specification; a production launch has not been independently verified.
The design problem is not that the product is scarce. It is that half of it is unlimited and half of it is shared, and the user has to know which half they are in.
Context & Role
A zero-to-one mobile product: no existing app, no inherited patterns, and a hardware reality that could not be negotiated with. The sky browser is a rendering the product controls completely and can serve every user simultaneously. The telescopes are physical instruments in fixed locations, subject to connection loss and mechanical limits, and shared across a user base that will always outnumber them.
Project Overview
Project type
Zero-to-one product design
Role
Senior UI/UX Designer — design owner
Users
Members of the public and enthusiasts observing remotely; administrators managing access
Roles in the product
Normal User · Admin · Super Admin
Core surfaces
Sky browser · object detail and search · telescope fleet listing and detail · live control session · account and profile · admin panel
Physical constraint
A fleet of telescopes in fixed locations; each drivable by a single user at a time
Implementation status
Zero-to-one design specification covering access, four availability states, session controls and role-based administration. Production implementation has not been independently verified. Items marked Proposed are recommendations outside confirmed design scope.
Ownership
OwnershipDetail
What I owned
The access and session model, the availability state design, all screens and components, the feedback system, role-based governance screens, and the visual system
What the client owned
The telescope fleet and its control capability, the session duration policy, the astronomical data source, and release scope
What I proposed but did not decide
That a session hold release automatically on connection loss rather than being held open, and that session length be tunable per telescope rather than fixed product-wide. Both sit inside the platform’s operating rules and are marked Proposed.
The Problem
Two economies live in one app, and they behave nothing alike.
The sky browser is unlimited
Every user can pan, zoom, tap any object, read its coordinates, and toggle constellations, grids, atmosphere and labels at the same moment as every other user. Nothing anyone does costs anyone else anything, and mistakes are free and reversible.
Telescope control is shared
Every action moves a real motor, the feed is a live camera rather than a rendering, and while one user drives a given telescope, that telescope is unavailable to everyone else. Mistakes there cost time that belongs to someone.
Three problems a pure sky app never faces
Joining them creates three problems a pure sky app never faces: a user has to know which instruments are free before committing; sessions have to be bounded so instruments turn over without anyone administering them; and the crossing between the two halves has to be unmistakable, because the same gesture means something different on each side of it.
The Product as a System
The full path runs from an unlimited browsing state, through a claim on a physical instrument, to a release that returns it to the fleet. Three terms carry this throughout: a user claims an instrument, holds an active session on it, and releases it — either deliberately or when the cap is reached. Claim and release are the only two moments that affect other users, and the design treats them as the load-bearing points of the product.
Discovery & Constraints
Three inputs informed the design: client input on the telescope fleet, its control capability and the operating rules around session length; a review of how established remote-observatory services structure access; and a review of how consumer products let a user drive a remote device through a live feed — specifically consumer drone piloting apps, pan-tilt-zoom security camera apps, and robot-vacuum live-control interfaces, each of which pairs a video feed with discrete directional input under latency.
The services I reviewed used scheduled access, but their access arrangements varied. Some tied an observing token to a booked slot; others described scheduled runs and approved remote access. The references below distinguish those models rather than treating them as one universal token workflow.
Constraints
- Each telescope can be driven by one user at a time — a hard physical constraint, not a policy that could be designed around — while the sky browser has no such limit
- The fleet is small relative to the user base, so the interface has to help a user move between instruments rather than fixate on one
- Sessions are time-capped and terminate automatically, so the interface must make the limit understood before the session starts rather than discovered when it ends
- Availability changes without warning: a telescope free when a screen loads may be taken a second later, so the interface cannot treat availability as settled
- The product is used at night, in darkness, often outdoors — so the interface had to be dark-first rather than a dark theme applied afterwards
- Control input happens one-handed on a phone while the user looks at a live feed, not at the controls
The Access Model: A Product Decision, Not a UI Decision
The largest decision in this project was not how a screen looks. It was how the platform allocates a physical asset among competing users — an operating-model choice that determines staffing, utilisation and the shape of every screen downstream. Three models were viable.
Reservation
How access is grantedBook a future slot; receive access at the booked time — the convention across the services reviewed
Why it was rejected or selectedRejected. Defers access to a moment the user did not choose, and observing conditions are unpredictable enough that a booked slot may be worthless when it arrives. It also introduces no-shows, which lock an instrument against a user who never appears.
Queue and notify
How access is grantedJoin a waiting line for a specific telescope, get notified when it frees
Why it was rejected or selectedRejected. A queue introduces coordination the product would otherwise not need — notification delivery, a window in which the claim must be taken up, abandonment when it is not, and a fairness rule when positions are contested. It also directs a user at one instrument when another in the fleet may already be free.
Opportunistic with a hard cap
How access is grantedWhoever asks first gets that telescope, for a fixed short session, after which it releases automatically
Why it was rejected or selectedSelected. Preserves immediacy, guarantees turnover without anyone administering it, and pushes demand across the fleet. The cost is that availability is never certain — which the interface then has to carry.
Choosing immediacy means accepting contention rather than eliminating it, and that produced the principle the product is built on:
Where an interface stops being unlimited and starts being shared, it has to say so — before the user commits, while they hold it, and at the moment they lose it.
Operational Value
The access model was chosen for what it costs to run, not only for how it feels. Each property below is inspectable in the design; the effect is the intended outcome and has not been measured.
Design propertyIntended operational effectStatus
Auto-releasing session cap
Designed so an instrument cannot remain locked indefinitely by an inactive user and no staff member has to reclaim one manually — turnover becomes a property of the system rather than an administrative task
Design inspectable · effect unmeasured
No booking layer
Removes no-shows, cancellations, reminders and reschedules — an entire class of operational work and support contact that a reservation model would create
Architectural hypothesis
Quantified countdown on In Use
Intended to help users choose a free instrument instead of waiting or contacting support. Its effect on utilisation across the fleet has not been measured
Design inspectable · effect unmeasured
In Session state on the object
Makes an active session visible on its instrument, with the aim of reducing accidental occupation while other users are waiting
Design inspectable · effect unmeasured
Limit stated before control is granted
Intended to reduce confusion and related support requests by stating the time limit before a user accepts the session
Architectural hypothesis
Role-based access control
Lets the operator revoke a user’s access to physical hardware without touching the hardware or the codebase
Design inspectable
Taken together, the model is designed to let the platform add users without adding operational staff, since nothing in the allocation of instruments requires a human in the loop. Whether it does so is a question for measurement, not for the design.
Reading the Object Before Reaching for an Instrument
Before availability matters, a user has to want something specific. Tapping an object in the sky browser opens a sheet carrying a real astronomical record, designed to be pulled open in stages rather than presented at once.
At rest it shows the object’s name and type, with a Center action that aims the view at it. Drawn up one stage, the action area becomes stepped zoom. Further, the sheet adds the identifying figures — constellation, magnitude, distance, right ascension and declination, azimuth and altitude. Fully open, it adds descriptive text, alternative designations and an external reference.
The sequence follows what each stage is for. Identifying an object needs a name; deciding whether to observe it needs position and brightness; understanding it needs prose. Placing those figures before the prose matters because they answer the observing question: altitude indicates how high the object currently sits above the horizon, azimuth gives its bearing, magnitude indicates brightness, and right ascension and declination fix its position on the celestial sphere so it can be located and tracked. Together they tell an observer whether an instrument is worth claiming for it. Prev and next controls move between objects at whatever stage the sheet is open, so comparing candidates does not mean collapsing back to the sky.
Availability Across the Fleet
Because immediacy was chosen over certainty, the listing screen carries the weight a reservation system would otherwise have carried. It presents the fleet as parallel options rather than a single instrument to wait for, and each telescope resolves into one of four states. Each state determines one thing: the available action on that instrument.
StateWhat it meansAvailable action
Available
The instrument is free to claim
Claim it — the only state where the primary action is enabled
In Use
Another user holds an active session
None. A countdown to release replaces the action, so the wait is quantified rather than open-ended
Unavailable
The instrument cannot be claimed — offline, weather, maintenance or fault
None. The action is present but disabled, so the instrument reads as temporarily out of service rather than missing
In Session
You hold the active session
Return to it — so a user who navigated away is never unsure whether they still hold the instrument
Two states carry most of the weight. The countdown matters because a user who finds an instrument held has two useful options — wait, or claim another — and both need the wait quantified. In Session matters for a different reason: holding one of a small number of shared instruments is a state a user can lose track of, and showing it on the instrument itself means the product does not leave someone unknowingly holding a telescope others are waiting to claim.
How the model scales
Scalability here is a design property rather than a tested result — the model has not run at scale. The property is that the four states describe a single instrument and none of them refers to how many instruments exist, so additional telescopes render through the same card, status badge, action substitution and detail badge. On that basis, growth is intended to add rows to a list rather than interaction patterns, and a user who has learned one card should have learned the fleet.
The four states are exhaustive within the user-facing model: an instrument is free, held by someone else, held by you, or unavailable. Technical conditions underneath — connecting, calibrating, faulting, maintenance in progress, control lost — are deliberately collapsed into those four, because a user deciding whether to observe needs to know what they can do, not what the hardware is doing. That collapsing is itself the scalability decision: adding instruments, or adding technical states, does not add user-facing states. What a larger fleet would require is filtering and sorting by location, aperture or availability — an addition to the listing rather than a change to the state model.
The Session as a Bounded Object
A time-limited session fails in a predictable way: the user forgets it is limited, gets absorbed, and is cut off mid-observation. The design treats the limit as something the user is told, reminded of, and allowed to end on their own terms.
Stated before it starts. A confirmation step names the duration and the automatic disconnect in plain language before control is granted — the one moment where the user can absorb the rule without cost.
Visible throughout. A running session timer sits in the control header, so the user never has to hold the remaining time in memory.
Endable early, with a check. End Session is always available, and confirming it warns that time remains and that ending disconnects immediately — because releasing the instrument is irreversible and the next user may take it within seconds.
Two Interaction Models, One Experience
Browsing and control had to feel like one product without feeling like the same thing, because confusing them is the most costly mistake available in this app.
Browsing is spatial and free
The sky fills the screen, chrome floats, objects are tapped to open the sheet, and a layers control toggles constellations, grids, atmosphere, labels and landscape. One persistent action — Telescope View — offers the crossing.
Control is deliberate and discrete
Slewing a mount is not a pan gesture: it is a motor command with latency, mechanical limits and a cost to the next user. So control uses a directional pad with a centring action and stepped zoom rather than free gestural manipulation — discrete presses map to discrete commands, work one-handed while the eye stays on the feed, with the aim of reducing accidental instructions compared with free swiping. The live feed replaces the rendered sky entirely, and the header changes to carry the session timer and the release action.
Losing the Instrument, and Other Failures
Contention produces a failure the user did not cause: the instrument they were about to claim is taken by someone else between the tap and the response. This specific case is less central in a reservation model, where the contest happens at booking time rather than at the moment of use; in an opportunistic model it is routine, so it needed designed feedback rather than a generic error.
A toast system carries these outcomes in three severities — confirmation when a session is granted, warning for degraded conditions, and failure when the instrument was lost — each naming the cause rather than reporting a status. Being told another user started a session is very different from being told a request failed: the first is an understandable outcome of a shared resource, the second sounds like the product is broken. Clear, cause-specific feedback is also intended to reduce avoidable support requests. That effect has not been measured.
Governing Access to Physical Hardware
Administration in this product is not a generic account-management feature. Every account in the system is a key to a motorised instrument, so the admin panel is the control surface for who may operate the platform’s physical assets — and that reframing changed how it was designed.
I designed provisioned access: an administrator creates the account and issues credentials, with no public sign-up in the documented flows. This gives the operator a clear point for granting and revoking access to physical hardware. It is a design choice reflected in the screens; the client’s operating policy and production implementation have not been independently verified.
Role changes are therefore treated as destructive. Promoting a user to Admin is confirmed with the explicit consequence that only a Super Admin can reverse it, because that promotion hands someone the ability to grant hardware access to others. Deletion states what is removed and that it cannot be undone. Privilege over physical equipment carries the same friction as deletion, through the same consequence-specific confirmation pattern used when releasing an instrument.
Accessibility requirements
Accessibility requirements in the design specification. Production accessibility and WCAG conformance have not been verified.
- Availability state never signalled by colour alone — the status dot always pairs with a text label, reinforced by the action state
- Contrast to be verified against WCAG 2.2 AA for text and controls over the sky rendering and the live feed, tested against the brightest and darkest frames rather than a typical one
- Directional and zoom controls sized and spaced for one-handed use without looking at them
- The session timer legible at a glance in darkness, and not dependent on colour alone to signal that time is running low
- Support large system font sizes without clipping the telescope specification lists
Outcome
What the design establishes
Every decision below is the same principle applied at a different moment — marking where the product stops being unlimited and starts being shared.
MomentDesign decision
Choosing a target
A staged object sheet that surfaces coordinates and brightness before prose, because those figures belong to the decision
Before commitment
Four-state availability across the fleet with a quantified wait, so a user knows what they can do before they ask
At the crossing
An explicit confirmation naming the duration and automatic disconnect
During control
A persistent session timer, discrete motor commands, and an always-available confirmed exit
At the point of loss
Feedback that names contention as the cause rather than reporting a failure
Across the platform
Provisioned access and consequence-specific confirmation for every irreversible action, including role changes
What was designed
A complete zero-to-one product design — splash and authentication with error and recovery states, the sky browser with its staged object sheet, search and viewing layers, the fleet listing and telescope detail, the live control session, profile and account management, and a role-based admin panel — together with the modal, toast, status-badge and control components that make the availability and session model reusable rather than drawn per screen. This is a completed design specification; production implementation has not been independently verified.
What remains unvalidated
The product rests on hypotheses throughout, including the access model itself. These are the three primary ones, none tested:
- That an opportunistic access model suits this audience better than reservation — the foundational bet of the product
- That a quantified countdown moves a user to another telescope where an unavailable state would lose them
- That stating the session limit before it begins reduces the experience of being cut off unexpectedly
What would be measured next
These are proposed validation methods. They are not evidence that the design works — they are how I would find out.
PriorityMethodHypothesis it tests
Access model
Fleet utilisation, and whether users who hit an In Use state move to another telescope or leave, against a reservation variant
Was opportunistic access the right foundational choice? This is the central claim.
Operational load
Support contacts per hundred sessions, and instrument idle time attributable to lock-up
Does the model remove operational work as intended?
Session comprehension
Ask users at the end of a session how long they had and whether it ended as expected
Did the limit land before it was enforced?
Control confidence
Error rate and hesitation on first slew commands, and whether users centre before adjusting
Is discrete control legible without instruction?
References
Services and documentation reviewed for how remote observing structures access. All reviewed September 2026.
SourceAccess model observedReference
The Schools’ Observatory — Live Observing guidance (Liverpool John Moores University)
Book a slot; an observing token is issued by email and activates shortly before the booked start time
Las Cumbres Observatory — Real-Time Interface
Session begins by entering an observing token tied to a booked slot
SALSA, Onsala Space Observatory (Chalmers)
Scheduled telescope access; the reviewed model tied control to a booked session
Palomar Observatory — remote observing guidelines
Scheduled runs, approved remote sites, and observer proficiency requirements
Las Campanas Observatory — remote observing guide
Scheduled runs with credentials issued per night; shared nights coordinated between programmes
These sources informed the category review. Their access models provided comparison points for the design decisions documented here.
Reflection
What I took from this project is that the hardest constraint is often the most generative one, provided it is treated as the subject of the design rather than an obstacle in front of it.
I spent early effort trying to soften the exclusivity of a telescope session — queueing, waiting rooms, ways to make a shared instrument feel unlimited. All of it added machinery without adding access, because none of it changed how many telescopes exist. The work only became coherent once I stopped treating the fleet as a shortage to disguise and started treating it as a set of options to move between.
The part I would do differently is validating the foundational bet earlier. Choosing opportunistic access over reservation is an operating-model decision that determines utilisation, support load and every screen downstream — and I made it on reasoning about an audience I never observed. It is defensible, and it is also exactly the kind of decision that deserves evidence before a product is built on top of it.
A constraint you try to hide shapes the product anyway. It just shapes it badly.
