Website work cycle
15 December 2016
I had a very busy spring and summer this year. Since then, I, along with my clients and collaborators have being doing post-mortems on some of these projects and trying to figure out how we can improve our processes.
A big challenge with web work is in understanding client expectations. Clients may have beliefs and assumptions about what the final product will look like that go unexpressed. The the documents of the professional process don't always translate well to clients that aren't web professionals themselves. Sitemaps, wireframes and mockups get signed off on but the client may still not have a clear idea of the product that is being produced. Often, to the dismay of those who have been working on the project, clients have the most to say about the project once they have a real prototype running in the browser in front of them. If, at this point, the budget is 90% spent and major revisions or additional features are now required, the project can be in real trouble.
What follows is an outline I drafted for an improved process. It may share some strategies with more formalized project management methodologies (i.e. Agile), none of which I'm particularly well versed in, but it's specifically tailored for the small team, small projects that make up much of my work.
Website Process
This process assumes that the project will be broken into several cycles, each with it's own estimate and budget, and each done sequentially with time taken to re-evaluate the larger plan between each cycle.
The first cycle is the MVP cycle. This is for the building of the core product as defined by the purpose of the site. It will likely be very minimal and not the product the client wants to see in place long term. It must be emphasized however that this is a necessary step that will improve the later part of the process. Putting the MVP live, even though it will be bare, can help us get analytics data and user feedback that helps us make the rest of the features better.
Additional cycles are done per feature, or per small feature group. Each cycle is priced and scheduled separately so as to protect all parties from scope creep and budget explosions. Communication as always is important throughout, but the short cycles shorten the time between planning, design, production, deployment and feedback, ensuring that we never go too far off path without reviewing our progress.
- Define purpose of website
- Where possible establish quantifyable metrics for success
- Prioritize goals
- Examine previous website (if existing)
- Failings of old site according to client
- Examine metrics (Analytics) if any are available
- If not, instally Analytics immediately.
- Define feature set based on purpose
- Group feautures into following sets
- Primary Features (MVP features)
- Secondary Features
- Non-critical features (nice-to-haves)
- Group feautures into following sets
- Determine Technical details
- Tech Stack
- Theme/Plugins?
- Hosting
- Maintenance strategy
- Make a plan
- Clearly define and estimate MVP
- Establish timeline for MVP (conditional on recieving appropriate info from client.)
- Roughly define secondary and non-critical cycles
- Estabish rough timeline for secondary and non-critical cycles (subject to change and re-evaluation at a later date.)
- MVP cycle
- Define content
- Build wireframes / mockups
- Write code
- Populate content
- Test
- Launch
- Between cycle tasks
- Mesure traffic and usage
- Guage client satisfaction
- Re-examine outstanding features
- Re-examine budget, timeline, etc.
- Clearly define and estimate next cycle
- Establish timeline for next cycle (conditional on recieving appropriate info from client.)
- Roughly define other outstanding cycles
- Estabish rough timeline for other outstanding cycles (subject to change and re-evaluation at a later date.)
- Additional feature cycles (one per feature, or small group of features)
- Define content
- Build wireframes / mockups
- Write code
- Populate content
- Test
- Launch
- Back to Step 6.