Frustrated by web development?
Many of our friends have been in the same position, so here’s our best advice, below.
Dream that big dream. But then think of the bare minimum that would make you happy, and people would find useful. What are the three most essential features? What is the most essential feature?
Call this Version 1.0. Save the rest for later. No need to even tell people about the rest unless they’re really really interested.
Your goal here is just to get Version 1.0 built. That, alone, will be a huge accomplishment. Everything below is describing only Version 1.0.
Again, remember: only describe Version 1.0. The big version is written down somewhere else.
Leave off all details that the programmer doesn’t need to know.
For example: If you want to sell videos, you don’t need to say what’s in the videos. Just “sell downloadable and streamable video files.” If you want the site to translate ancient Arabic poetry to Spanish to increase global tolerance, just say, “Translate paragraphs from Arabic to Spanish.”
Be succinct. Programmers love that. Include people in a story, using the terms you use. For example:
“A company creates an account, then creates a new project with a title and description. In the project, they upload multiple documents to be translated. Each document has a from-language, to-language, and a name. The system counts how many words are in each document. When the company marks the project as ready, it is announced to the translators. The announcement shows how many documents, how many words, and a price. The translator rejects or approves. They log in to translate the documents, one at a time, marking each finished when done, which sends the file back to the company for review.”
From this, the programmer will look for nouns and verbs, so start to think in those terms to help you communicate better. (A programmer would see: Company, Project, Document, Translation, Translator, etc.)
We want to isolate the most important path through your website. We will call this the main set of features. Here at CaliCodeFactory we follow a mix of what is called an Agile method and traditional forms of project management – like the waterfall approach with a strict set of milestones and well defined features. With changing or unclear specifications we always want to plan for change – hence the word Agile.
Once we have defined our main features we want to tell a story about it.
What happens when you click it? Exactly what did the system do? What happens next?
Start to think in IF-THEN branches. Example: “If it’s a new user, it takes them to this welcome page. If they’ve been here before, it takes them to their account page. If it asks for a number, but they type a word, send them back to the same page but with a message.”
In a text file, write down every thing you know this Version 1.0 needs to do. Every click. Every action. A long list of small simple things.
Start to think of the exact wording of what you want it to say, but save that somewhere else. Don’t clutter this list with wording.
The goal is to keep this long list of actions very clear and simple, so that a programmer can see it, and see that each step is easy. For them it should be like eating chips, not an elephant.
We tend to think of other people’s work as easier than it is.
So break Version 1.0 up into many “milestone” steps. Think of it as a day’s work. (It might take more or less than a day.) The point where they upload their work for you to test. Where you test it and are happy that little piece works.
Don’t expect it to look pretty at this stage. Expect it incredibly ugly but functionally working. Like building a house, the paint and decor goes last.
For example: in my translation site story, above, the first milestone might be just a plain ugly web page where a company can create an account, create a new project, then upload named documents into that project. That’s it! If that works, that’s a good start.
Thinking of your project in milestones makes all the difference. You’ll stop and communicate at each, making sure you’re happy before continuing. Misunderstandings can’t run on too long. You’ll estimate time and cost better. And you’ll both feel a good sense of momentum.