I uses coded prototypes. Deckware and clickables are sub-optimal. If you can code it and put it in someones hands, it allows them to see and experience the actual value. The former explain to people what you think the value is. It's a nuanced by distinct difference.
The former encourages group think and confirmation bias; I think the problem is important and the solution brings value, therefore it does. The latter allows you to identify who your customer is.
sketch out stuff on paper very crudely, then start coding in the browser and iterate, iterate, iterate. The finished product usually looks way different than the sketch.
I've never been good at making formal mockups and transforming it into a working site.
6 comments
[ 3.1 ms ] story [ 25.2 ms ] threadThe former encourages group think and confirmation bias; I think the problem is important and the solution brings value, therefore it does. The latter allows you to identify who your customer is.
I've never been good at making formal mockups and transforming it into a working site.
- Paper sketches
- simple google doc with pages set to A5 so it fits very little on each “screen”
- either of the two can be imported into invision and made clickable for user testing
- at least some user testing to validate nomenclature / mind model.
- then rails :)
Balsamiq Mockups - simple views
No functional prototype
- wireframe on Sketch (some people are faster on paper, I'm faster on Sketch/XD/whatever)
- create what I call a medium-fidelity mockup (basic styling, all components, etc, but not much actual content)
- create a small PWA/webpage to demonstrate behavior and flow
- go back and complete my high-fidelity design
- send it, and any styleguides, to the devs
Throughout these steps there are multiple rounds of iteration, review, and branching, but eventually you have a product design ready to go.