Plox
Plox gives pixel artists a canvas to draw on and a place to share their work. Galleries, challenges and moderation connect creation with the community.
My scope: full-stack product design and development across the public discovery surface, the React studio workspace, shared product architecture, and the interaction model connecting both.
30-SECOND PROJECT READ
The project at a glance.
- Challenge
- Combine a public creative community with a capable pixel-art studio while keeping the controls understandable for first-time users.
- My role
- Product design and full-stack development across discovery, creation, sharing, moderation and the studio interaction model.
- Team
- Independent product design and build.
- Timeline
- Web application · 2025
- What shipped
- Plox includes galleries, challenges, profiles, guides, moderation and a browser-based pixel editor.
- Outcome
- The gallery, challenges, profiles, moderation tools and browser-based editor are working. The case study labels the measurements that still need to be collected.
Design system
The gallery, profiles and challenges lead into the pixel editor. Recurring tools, layer controls and a timeline structure the work on an image.
Working with stakeholders
I handle product design and development, considering first-time users, active pixel-art creators and community moderation tasks.
The workspace, then the controls
The overview shows how the canvas and panels fit together. The detail view makes the drawing tools and transform controls readable.
How do you make a serious creative tool feel approachable?
Plox had to serve two very different moments: discovering other artists and working inside a dense pixel-art studio. The product needed gallery discovery, social motivation, and a capable canvas without making the first interaction feel like opening a cockpit.
“The first question was not “what framework?” It was “how do pixel artists discover each other?””
Plox process notesOne product, two surfaces, one interaction model
Plox separates the public, SEO-first surface from the no-index creative studio. That separation protects the focused workspace while keeping artworks discoverable, shareable, and connected to a community layer.
Discover and share
A server-rendered gallery, animated previews, artist profiles, challenges, leaderboards, and short-code sharing make the work visible beyond the editor.
Create without distraction
The React canvas keeps drawing, colour, references, layers, frames, onion skinning, and project state close to the work itself.
Connect through one API
A shared type system and Express API keep identity, artwork lineage, challenges, permissions, and moderation consistent across both surfaces.
Complexity organised, not erased
A creative tool cannot hide every advanced capability. The goal was to give beginners a visible route into the product while preserving accelerators for people who already know how they work. Dedicated panels support recognition; shortcuts and a command palette support speed.
The interface was only one part of the work
Plox runs as a full-stack monorepo: Next.js for the public surface, React for the studio, Node and Express for the shared API, Supabase (Postgres) for product data, and Docker Compose for the local stack. Caddy routes the public site, studio, and API as separate services without splitting the product model apart.
“One command spins up the full stack. Each surface can evolve independently without breaking the other.”
Plox process notes · local deployment architectureWhere product, interface, and infrastructure meet
The implementation crosses product, interface, and infrastructure decisions: workspace state, frame operations, save flow, reference controls, and the boundaries between the public surface and the studio.
What I would measure before calling it easy
The engineering baseline is useful context, not a usability result. The next layer is a task audit: can a new user create, correct, animate, and share work without needing a tour?
Immediate feedback
Benchmark brush stroke, tool change, frame change, and undo latency. The research target is feedback beginning within roughly 100 ms — not a claim that Plox already achieves it.
Recovery by default
Check delete frame, delete layer, clear canvas, overwrite, unsaved work, undo, and redo for reversibility, confirmation, and visible state feedback.
Novice → expert path
Test first artwork, colour change, layer creation, undo, second animation frame, onion skin, and export with task time, errors, assistance, and confidence recorded.
One product across connected surfaces
These counts describe the implementation. They are not conversion rates or evidence of usability.
Shared product model
A common interaction model connects discovery, creation and sharing.
User-facing surfaces
The public website and studio connect through one API.
Generated routes
Routes reported by the website build. A count of pages, not a percentage.
Power needs a clear way in
Design the path, not just the panel
The key question was how discovery, creation, feedback, and sharing reinforce one another — not how to decorate a canvas.
Separate surfaces by user intent
A public gallery and a focused studio can share an API and product language without sharing the same density or navigation.
Treat shortcuts as a second layer
Expert efficiency should be available without making the first-use experience depend on memory or documentation.
I have documented the working interactions and architecture. I have not yet measured task success with participants or established a latency baseline.
Benchmark the four critical interactions, run a small task-based usability study, and turn the results into the page’s strongest proof instead of relying on feature count.
