Thinking about the design, I’m finding it harder and harder to focus on the screens. My notebook is filling up with model objects. I picked a deliberately simple problem from a coding perspective, and yet I’m drawn to it. What are the special cases? How am I going to store the images and other data?
That’s because, in my mind, the UI is ready enough to get started. Is doing the formal visual design worth the trouble before coding starts?
At this stage, I’d say it’s actively harmful to settle on a visual design. No one can possibly know the right design for this app yet. Because no one has used the app before.
You know those analogies used for software development? Bridges and rockets and buildings and such? Bullshit, to a first approximation.
No. Think movies, TV shows, songs, novels; mathematical theorems and physics experiments. Software development is experimental, creative, iterative.
I’d argue a trained app developer can think abstractly enough to read a description in words about a screen, visualize it in their brain and reason about it then and there. I can do this; go back and read yesterday’s post—I specified the home screen (and decided on hierarchical navigation, no tabs). This is a rare skill, though; I know from experience.
I’m trying mightily to hew to this theoretical process of software development, but my experience is fighting back. Every project I’ve been on, every project had to re-jig the UI as we sunk deeper into the problem, usually significantly.
Going through a large design phase up front is expensive and wasteful.
I have enough of an idea for the app that I can code a crappy version of it right now. By crappy, I mean I’ll hardcode things that should not be hardcoded. I’ll do all those “bad” things developers tell you not to do. I will work quickly, though and get something working before you know it. It will crash; it won’t handle every case.
The true problems will rush in on me, though, as I think through a particular method implementation. The flaws in my original design will become apparent. Whatever the FUX should be will hit me right in the face with its obviousness when I hit ⌘+R over and over again (I hate UX has a term, but FUX, for first user experience, delights me).
I reckon, based on experience, that taking photos is going to turn a giant time sink, because people mostly suck at taking photos. No one going in would assume that that would be a problem to discuss, or who to solve it, until one took their first photo. Oh, huh. We’ll have to do something about that.
Just enough should be your motto on a version 1. Answer questions just enough to get to the next step; design just enough to get to development; code just enough to cover each user scenario.
Then you can start reasoning more thoroughly about all aspects of the app. And then you iterate again and again until eventually, the suck is minimized. This is when more formal methods, style guides, etc. should take over. The core problem is solved. The app has a feel to it.
Iteration is the key. Continually solving the problem with further and further refinements.
This always brings to my mind this delightful article by Andy Bobrow: How Writing for the TV Show “Community” Cured Me.
I’ll just leave you with that.