In a recent post, I hinted at how much I’ve learned while building a web application over the past year. A huge lesson came when I decided to do the third version of the design myself, which is what I should have done from the very beginning.
Over the last year, I’ve learned enough HTML and CSS in order to build a functional mock up of the application, and working with great people that can check my work ensures that it’s up to snuff.
$14 later
I started by buying an HTML template for $14. There are tons of templates available on the internet. I highly recommend buying an interface template of ready-made styles, buttons, forms, error messages, info messages, etc rather than spending scarce dollars on a custom design.
Custom designs are important, but only after a product has gained enough momentum to ensure its own survival. There’s not much point in devoting thousands of dollars to an early version of a software product’s design unless you need help visualizing it.
I know, because I wasted those thousands of dollars myself. The designers I hired for the first two versions were competent, but my thinking wasn’t clear enough to give them the information they needed. Only by going through the design process myself was I able to clarify my thoughts, get exactly what I wanted, and to fully understand how complex and variable building a web app can be.
So after 14 dollars and a lot of staring at my screen, I had a functional mock up of what I wanted the first release to look and act like. Thankfully, the developers gave it the thumbs up and said, “It’s bloody fantastic”.
Simplicity isn’t easy
A basic version still requires a surprising amount of design. I’m glad I did the third design myself so that I now fully understand how complex a web app can be. (Hint: Ryan Singer’s “What they see, what they do” idea and his “Using Patterns in Web Design” are great places to start.)
I started out by thinking that if I kept the first release really basic, then there wouldn’t be that many screens for me to build. 96 hours later I realized the truth. Even with limited functionality, I still needed 28 screens. All the more reason to start a web app by building almost nothing as a first release.
Although the first version of Sales on Rails is very simple, here’s the screen list:
- Account sign up, paid
- Account sign up, free
- Sign up thank you
- Login
- Forgot password
- No known account error
- Account settings
- Cancel account confirmation
- Generic error
- 404 not-found error
- Blank state welcome
- Blank state dashboard
- Blank state orders
- Blank state customers
- Blank state products
- Dashboard
- Orders summary
- Import orders
- Import orders field mapping
- Single order
- Customers summary
- Import customers
- Import customers field mapping
- Single customer
- Products summary
- Import products
- Import products field mapping
- Single product
Twenty-eight screens is a lot. I never would have guessed that there’d be that many when I started out. After going through the design process myself, I would say that trying to anticipate each click-path and error state without putting anything on paper is pretty much impossible. Even now with all these screens done, there are still others to do when new features, bug fixes or unanticipated uses come up.
Even if you don’t know — or don’t want to learn — HTML and CSS, if you’re building any type of software, you need to sketch every screen that you think you may need. Only by asking, “What do they see? What can they do?” will you be able to flesh out most of your use cases. Even if it’s just a Sharpie, drawing it out can tell you if you’re on the right track and if you’ve thought of everything that you need to.
