Following the lecture feedback session, the prototype was presented in a class critique where peers were invited to respond using a structured format, what is working well, what to continue, what to stop, and what to consider starting. The session also included guest feedback from professional designers, which added an industry perspective to the conversation.
The idea was received well. The core concept landed clearly without needing significant explanation, which felt like meaningful validation given that this is a speculative project set twenty years in the future. The glass aesthetic was consistently praised across both peer and professional feedback, described as visually pleasing and well executed. That consistency across two different audiences, students and working designers, gave me confidence that the visual language of Pane OS is communicating the right things.
The majority of feedback fell into this category, which is a healthy sign. It means the concept is strong and the work needed is refinement rather than rethinking.
Accessibility and contrast, several peers flagged legibility issues with certain text across certain backgrounds, citing contrast as the primary concern. This was echoed strongly by the guest designers from Little Thunder. It is a straightforward fix and one I am keen to address. Good contrast is not just a polish concern at this stage, it is fundamental to whether a tester or marker can actually engage with the content being shown.
Sizing, the guest designers suggested that the overall prototype device frame is currently too small relative to the screen, making the finer type difficult to read. Their recommendation was to have the room environment fill the full screen and bring the pane itself closer and larger. This would immediately improve legibility without changing the design language and would make the prototype feel more immersive to someone experiencing it for the first time.
Real background photography, rather than the current CSS-rendered approximations of each room environment, using real photographs for the living room, kitchen, desk and child's bedroom was suggested as a way to make the prototype feel significantly more grounded and believable. This is something I considered early in the process but set aside due to the perceived complexity. Having now experimented more with the prototype I am confident it is achievable and I think it would be one of the single most impactful improvements remaining. A real photograph of a wall or a desk surface would give the glass container something genuine to sit against and would communicate the concept far more powerfully than a gradient can.
Child lock on home controls, a peer noted that the Home Control panel being accessible from the child's bedroom setting does not make sense contextually. This is a great observation. Rather than simply removing it, implementing a child lock, where the controls are visible but require authentication to access, would be a far more considered response. It demonstrates that Pane OS is a family-aware system that adapts its permissions based on who is using it and where. That kind of contextual intelligence is central to the concept and this would be a meaningful way to show it in the prototype.
Gaming content for the child, Kyle raised the idea of expanding what the child's bedroom setting offers beyond the drawing tool. A gaming screen was suggested, with Minecraft cited as a recognisable reference point. This feels like an easy win. The draw screen already demonstrates that Pane OS can be a creative surface for children. Adding a gaming context would round out the child persona and show that the product genuinely serves every member of the Martin family rather than treating the child as an afterthought.
The glassmorphic visual language was the standout positive across both sessions. Peers and professionals alike responded well to the frosted glass aesthetic and the restraint with which it has been applied. The recommendation was simply to continue in this direction and ensure any new additions maintain the same standard of visual consistency.
A navigation cheat sheet was suggested as a consideration, a brief reference guide that helps someone unfamiliar with the prototype understand the key interactions before engaging with it. Given that Pane OS is a speculative concept where a lot of the behaviour is implied rather than demonstrated, having something like this available during a critique or testing session could reduce the time spent on explanation and allow the experience to speak more for itself. This is something I will consider producing alongside the prototype as a supporting document.