Freelance project · SaaS
A clickable, demo-ready prototype designed under hackathon time pressure
For Smart India Hackathon 2024 I designed the prototype for our team’s solution: a web product built around one problem statement and judged on a live demo. I owned the flows and the UI, working beside the developers so design and build came together in time for judging.
01The problem
A hackathon gives a team very little time to understand a problem, settle on a solution and show it working. Design can easily become the bottleneck, or be skipped and leave developers guessing. I had to produce something clear enough to build from and good enough to explain the idea to judges in a short demo.
Who it’s for
Hackathon judges
Need to understand the problem, the idea and why it works within a short demo.
Our developers
Need screens and flows early enough to build against, without waiting for polish.
Intended end users
Need the core task to make sense the first time they see it.
02The main flow
01
State the problem
02
Show the starting point
03
Run the core task
04
Show the result
05
Share what comes next
03Structure
Entry
Core task
Dashboard
Demo support
04Key decisions
Decision 01
With little time, it is tempting to sketch every feature at a low level of detail.
Considered
Covering many features with rough, partly working screens.
Chosen
I designed one core flow end to end with real content and every state it needs, and showed the other features only as a short roadmap screen.
Why it works
Judges remember one thing that works over several that half work, and the developers could build one flow properly.
Decision 02
New interaction patterns need explaining and testing, and there was no time for either.
Considered
A custom, distinctive interface to stand out visually.
Chosen
I used familiar web patterns for navigation, forms and tables, and put the visual effort into typography, spacing and a single accent colour.
Why it works
Familiar patterns let judges focus on the idea rather than learning the interface, and they were faster for the developers to build.
Decision 03
With design and development running at the same time, small visual differences creep in fast.
Considered
Handing over finished screens and letting developers pick values from them.
Chosen
I set a small set of colours, type sizes and spacing values first and shared them with the developers before any full screen was ready.
Why it works
It let the build start in parallel and kept screens consistent even when they were coded before I had drawn them.
05What’s inside
Every screen of the main task, with loading, empty and error states.
Colours, type and spacing agreed early so the build stayed consistent.
A clear view of the outcome of the core task, made to be read at a glance during the demo.
A step-by-step walk-through of the product with realistic sample data.
Features left out of the build, shown as next steps rather than half-built screens.
06Outcome
Delivered
What I learned
Under time pressure, deciding what not to design is the most useful design work.
Sharing style values before screens let design and development run side by side instead of taking turns.
Next step
Pick a time that suits you. You'll leave the call with a clear next step, whether we work together or not.
