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?
I think the terminology of “Micro-ISV” is dead but the concept has generally shifted into more of a “small software company” or “solopreneur” and that concept is alive and well.
I’m not a fan of this technique unless you’re using it with other developers or product designers. End-users tend to not be developers and thus are positively awful at designing apps. There are tons of UI and UX items that they simply don’t even consider because they think in terms of what they want to accomplish, not how the screen should be laid out.
Many times, they’re not aware of what the options are and it’s difficult for them to consider the subtle nuances of something like a null date field. How is that stored and what does it really mean to the screen, to the user, to the app itself, etc. I think in general, you’re better off designing it yourself and then showing the end user what it does and then asking if it solves their problem.
There are apps with positively awful UI/UX which have done quite well because they solved a solid pain point and a sales process can overcome those challenges. But if your app doesn’t solve a problem, it’s impossible to sell it to people.
There’s a time and place for concentrating on a well designed UI/UX, but initial prototyping for a new app probably isn’t that time and place.
Paper prototyping does work, nice reminder.
Would also recommend About Face: The Essentials of Interaction Design by Alan Cooper