I’m beginning to think about how to think about the UI/UX for a couple of projects.

First of all, I’m pretty rusty at this sort of thing, since I haven’t designed an interface for anything in maybe 5 years, and that was an API.  A “real” interface which non-techie humans are supposed to interact with: I haven’t done one of those in… 25 years??  (Can it be?)

So I’m browsing about for techniques to make my maunderings a little more systematic.  And I ran across “Paper Prototyping”.

The ref came from an older book, “Micro ISV”, an instruction manual for building a small one- or single-digit-person software shop (apparently the Micro-ISV movement is already dead, so maybe this reading is moot in any case.)

But the book recommended a technique called “paper prototyping” as a scheme for gen-ing up a UI.  Needless to say, I bought the book.

…And found out it’s an interesting low-cost way to specify a UI, but it’s not a one-person tool.  It’s a tool for interacting with users.

You sit down with the users and use hand-drawn screens instead of a simulation.  You can “operate” the UI by having multiple screens, “highlighting” things when a user pushes a button, etc.

I’m not sure if it’s interesting for a techie who could wireframe the UI with almost less work (and maybe, given some of our paltry drawing powers, with more of a sense of how it would look), but it’s something I would like to try at some point.

But it’s not an answer for how to guide one’s own thinking about the UI.

I hate use cases, because they’re usually too low-level.  You get sucked into the details of the case before you even get started on the coverage of the case.

So maybe my “tool” is to scribble ideas and show them to people whose opinion on the app at hand I trust.  In other words, a very low-fidelity form of paper prototyping.

Your thoughts?