Write a spec. No, seriously: write a spec.
This blog is about skipping the whole step of hiring someone to do our coding for us and learning to do it ourselves. However: sometimes ya gotta hire somebody. Here’s what you need to do to avoid a trip to #FAILVILLE.
If you’re going to hire someone to do programming for you, and you don’t think it through and write it down, you’re not going to get the website you want. You’re going to get the website they feel like giving you.
Coders have every right to feel jerked around when they turn in their best work and you say “That’s not what I meant!”
Say it with me: MINDREADING SHOULD NOT BE PART OF A CODER’S JOB.
If you’ve never done it before, breaking down the idea of a site into component parts can be difficult. But writing a site plan is easy if you know the basic elements:
- Overview: Here is where you sing your project’s praises. Remember: anyone who’s any good can work with whoever they want — they do NOT have to work with you. Contrary to contemporary stereotypes, coders are just as motivated as you and I are by cool projects. Doing a civic media project is about 80 times cooler than working on insurance software.
- Inspirations: Include seven sites, with screenshots, of sites you like and use on a daily basis. Say why you like them. You’ll be tempted to include other sites that are like your site, but that’s not the point of this. The point is to give the developer a sense of your taste, your likes and dislikes, your habits on the web, not to show her six sites of your competitors and say, “Gimme that.”
- User stories. Make up three fictional users. How do they find out about your site? What do they want when they get there? What reason would they have to come back? Be specific and creative — give them names and a life. I want to know if they have kids and a dog.
- Wireframes. Wireframes are simple diagrams of what goes where on a web page. Draw sketches of the 5 or 6 major landing pages on your site. Be sure to include the page a user sees immediately after they register.
- Feature list. Go back and look at your wireframes and make a list of everything that a user can click on or fill in, and say in one line what it does. [EG: Register Button: Takes user to the registration/login page). There’s no such thing as too detailed. Remember: NO MINDREADING. If you can’t tell the developer what every clickable element on that page does your job is not done. If you think what a clickable element does is obvious, get prepared for cost overruns when your developer does something logical that’s completely not what you wanted.
Writing a spec is a sign of respect for a developer and communicates to them that you will not be the Bad Client Who Drives Them Crazy.
As you do this, you will gain new insights into your project. Writing a spec is a way to focus on the fundamentals of your project and really think them through. If you skip the step of planning, thinking, and reflection, you’ll probably never be able to run this project with the verve and crispness that will make it a pleasure for you and others. Remember: Ya gotta grok it before you can rock it.