From idea to working product
UX comes first. Visual design and playful motion support the traveller's goal. Work on one feature or page at a time, with enough surrounding steps to test the journey.
Capture without committing
Save shareable product thoughts in Idea inbox. Keep the long-term vision separate. Search both, existing feature cards, and ticket reports before adding an idea. Link repeated discussions to the same entry. Anyone may report ideas; only the founder selects priorities and assigns work. Saving an idea is not approval, an assignment, or a change to MVP scope. Private business thoughts and research stay outside this shared workspace.
Discuss the outcome
Pick an inbox idea or discuss a new one. Read current decisions and requirements. Clarify the user, situation, desired outcome, placement, simplest useful scope, excluded work and observable success. Discuss one feature or page, not an entire future product. Capture unresolved questions rather than silently deciding them.
Inspect relevant competitor journeys before fixing the solution. Record source links, date, what was actually observed, and what to borrow, change or avoid. Use existing research where current; browse when fresh evidence is needed. An inaccessible flow is unknown. Competitor popularity is not proof of usability. Separate observations, hypotheses, proposed changes and founder-approved choices.
Placement, impact and words
Before drawing, the AI proposes where the feature lives in the journey and why, and what it changes for the traveller: the feeling, the friction removed, the decision made easier. Psychology and UX reasoning are hypotheses, labelled as such. The AI asks questions and refines the proposal from the answers.
Then the words. Text decides whether people notice, trust and act. For each key text (headline, main button, empty, error and success messages) the AI offers two or three options with a one-line reason each, written in the vision's voice: warm, clear, specific, never hype. The founder picks. The chosen words go in the feature card and are used as written in the HTML design.
Save the brief in the existing feature-card folder; link its originating ideas, research, discussion conclusions and deferred scope. Update the existing card when the same idea returns. Agreement on the brief permits the scoped prototype, not unrelated implementation or assignment.
Design through HTML and review
Use Impeccable for design planning, critique, clear copy and visual refinement. Use UX Researcher & Designer for journey mapping, usability test plans and research synthesis. The skill setup explains project overrides. Build clickable HTML following the existing team-plan prototype constraints. Open the HTML design in the browser once, right after the first build; a design for a new page opens in a new tab. For the root or index page, show its link instead. Later changes do not reopen anything; say what changed and the founder reloads. Expect a few rounds of feedback.
Check the user's main journey before decorating it: obvious next steps, useful defaults, understandable labels, back/cancel, retained input and mistake recovery. Include relevant empty, loading, error, success, permission and long-content states. Use normal product language inside the design. Put simulation boundaries, missing integrations and review status in a separate reviewer page or the feature card. Do not put demo/prototype disclaimers into product headings, buttons or messages. Never present the design as a live service outside that review context.
Niwesh reviews realistic tasks with neutral prompts and records confusion and
failures. Internal checks are not customer validation. Use target-user feedback
when available; do not invent interviews, personas, quotes or completion rates.
The founder confirms the prototype on a phone. Record the reviewed revision and
unresolved issues; revise before handing off if the journey does not work.
The design is done when the feature card says "Design: approved
Add joy with purpose
Use restrained transitions, responsive feedback and appropriate celebrations.
Motion should explain change or add warmth without blocking navigation, distracting
from reading or suggesting an operation succeeded before it did. Respect
prefers-reduced-motion; avoid essential information conveyed only through motion,
autoplay distractions and unnecessary animation dependencies. Keep the existing
NepWalk tokens and components. No 3D requirement for ordinary product flows.
Assign and deliver
After phone approval, follow team-plan to record the feature and approval, then create founder-assigned tasks with outcomes, acceptance checks, owners, independent reviewers and dependencies. Link the exact approved prototype revision. Prefer complete, testable outcomes. Non-UI tasks use contracts and examples instead. Each engineer builds one active task, runs relevant checks, then a real person manually tests it. Follow existing review, acceptance and release permissions. Niwesh also verifies the combined journey across completed tasks.
Keep links from idea to brief, prototype, team task, test evidence and release. Observed problems feed the inbox or a bug report. Anything the AI finds for later during design (a bug, a missing feature, a needed enhancement) becomes a ticket with a suggested priority; the founder confirms it at triage. Do not start the next feature's prototype before reviewing the current one unless the founder requests it. The manager may prepare research, briefs, prototypes and reviews when delegated; priority, task assignment and product approval remain the founder's.
Required context before drawing
For each feature or page, inspect the existing app route and relevant components, current feature cards, earlier HTML designs and founder-provided screenshots. Read the system's real permissions, data contracts and saved/draft behavior. Record each reference, its date/revision and what stays, changes or conflicts. Screenshots are evidence of the old experience, not authorization to preserve bugs. If a reference is unavailable, record the gap; do not claim it was inspected.
Review relevant competitor journeys using the same evidence discipline. Reuse existing profiles and screenshots where appropriate, and verify current flows when needed. Link observations and explain borrow/change/avoid. Neither competitor UI nor an isolated attractive screen overrides NepWalk's accepted journey.
Before building, include a journey map in the feature card: entry route and prior screen; user role and initial state; primary action; edits and transitions; save and request outcomes; back/cancel; failure and recovery; next screen or return. Mark neighboring screens as existing, changed, or outside the current scope. Connect designed states and screens with working navigation where in scope. For unavailable neighboring screens, explain the boundary in reviewer notes rather than adding fake product dialogs. Never silently replace an existing approved flow.
Responsive design handoff
Deliver one responsive HTML design with a reviewer view offering mobile, tablet and web widths. Use 390, 768 and 1440 CSS pixels as reference widths, plus checks near layout breakpoints and at 320 pixels. These are review sizes, not device claims.
In the feature card, state what changes at each layout: navigation, columns, sidebar/sheet placement, sticky actions, overflow, editing and keyboard behavior. Do not treat tablet as an accidental stretched phone. Preserve the same state and journey across layouts. Reviewer viewport controls live outside the product UI. Responsive controls are review aids, not proof of browser or physical-device tests. Record checks actually performed and outstanding checks honestly.
Link designs to delivery
Each feature card links its HTML design, reviewer view, source evidence, journey and exact approved revision (commit/path). List screens and state anchors so an engineer can find the relevant part. A draft is not an approved implementation spec.
When creating a related ticket, add the feature card, design/review links and relevant screen/state to the ticket description or a ticket comment. A new bug report can be filed without a design; add links when a matching design exists. When the founder turns it into a task, set the existing featureId and ticketId where applicable, and include the design revision, responsive behavior, acceptance checks and testing instructions in the task brief. Do not invent new record fields. Feature records retain the attached approved HTML through the existing team tool. Assignment stays with the founder; creating or refining designs assigns nobody.