This is us:
At Tickbox, we specialise in enhancing your existing WordPress website or building robust websites from the ground up. Based in Bristol, we proudly serve clients across the UK with dedicated web development support and hosting solutions using WordPress or our proprietary Hummingbird technology.
We don’t simply create new websites; we focus on making your current website exceptional. Our experienced team of web designers, developers, and strategists employs deep insights and data-driven improvements to elevate your online presence.
What we do:
- Outsourced web support
- Design and front-end coding (HTML/CSS)
- Search Engine Optimisation (SEO)
- Google analytics / tools set-up
- Back-end web development for complex systems
- Quality control and testing
- Web and marketing strategy
- Web planning and project management
1 No room for assumptions
It’s never the case that we want you to leave us to decide everything: we check every step of the way that what we think you need is what you really need. This is why we work through different stages using a waterfall model. One stage has to be signed off before we start the next:
- Client brief
- Proposal of services – Tickbox requirements understanding
- Design brief, design ideas as mock-ups
- Development specification
4.1 [content plan/client provides data/content] - Pre go-live checklist for testing
- Go-live, post-live testing
- One to three months warranty for correctives
If stages are missed, assumptions happen and risks could set-in that could lead to delays, re-working and ultimately a project over budget, which is not in anyone’s interests.
2 It’s better to work together
Partnership working opens up creativity, inspiring great ideas!
We work at our best when clients ask us to extend their ideas with our creative technological thinking, or when we are presented with problems to solve using web tech.
This is what makes us tick and why so many clients have been with us for many years.
3 Planning is fundamental
Good planning will set your website on the correct path, it’s the project foundation and will result in fewer issues, fewer delays and avoid budget over-spend.
A good plan needs a good planner or Project Manager at the helm, and this is a service we provide.
Planning includes brief, requirements and specification. These functions are not rolled out in one process and left in the hands of the client alone. The next 3 commandments explain why this is the case.
4 A brief is simply a brief – nothing more, nothing less
A brief is an outline of the project requirements from the client perspective. A good brief gives us an outline of your web project, your objectives, web audience(s), what needs visitors to your website have – once they get there. A brief helps us glimpse how success is measured for your website. The brief is not a spec, it’s not a technical solution yet!
The technical solution requires specialist skills, and that’s what we bring to the table. That’s not to say that you can’t steer our spec thinking, but don’t think your brief is our spec. That would open you and us up to assumptions and feature/scope creep.
5 Requirements understanding – you say tomato, I say tomato
We need to confirm back to you that we know what you want, in a way we all understand.
We do this with a technical proposal, which includes our understanding of your requirements.
This is usually in the form of a proposal or the first stage towards creating a more detailed spec.
Put it another way: Two-way communication is when one person is the sender and they transmit a message to another person, who is the receiver. When the receiver gets the message, they send back a response, acknowledging the message was received.
Effective two-way communication is essential when things get technical. You say tomato, I say tomato – it may sound like we are speaking the same language, but we could in fact be talking about bananas!
If we skip this step, then yes, you guessed it, assumptions leading to project risks creep in.
6 Spec is an internal doc that keeps us all singing from the same hymn sheet
Specs are multi-purpose. They are the framework and detail to the web development and they build upon the requirements understanding, built-up originally from the client brief.
If we were talking about music, the spec is the musical notation, the key and all the musical terms that give further instructions and context to the piece.
Specs are a language in themselves: they aren’t meant to be entirely client-friendly; they are meant for the team of web specialists to understand and follow during the web development build. It’s a technical language, because that is what a technical team understands.
The job of the Project Manager is to translate the spec, working both sides of the fence between a client and the web team. Everyone needs to agree that the spec is right, and it needs to be approved by all parties.
7 Corrective v Adaptives – the significant difference
Your website is built, something doesn’t work, but what does this mean? It could be that something doesn’t work, full stop. That needs us to fix it. We call this a Corrective Update.
For example a tiny syntax error in the coding can cause a system to fall over, so Correctives need to be sorted as soon as they are spotted in our testing phase, or as soon as the client test drives their shiny new website.
Or perhaps it all works as the spec said, but not in the way a client thought it was going to work. If this happens, it’s time to check the spec, as this was our requirements understanding and came from the client brief.
If it’s not outlined in our spec, we need to go back a step and adapt what we thought. Lots of Adaptives could mean that we are changing the project as we are working through it. This can mean that the project can change. If it does change, then so will the timeline and budget.
Sometimes Adaptives can be a good thing for a project providing there aren’t too many. Too many could mean feature creep has set in. See our next commandment to understand why this is big no-no!
8 Don’t allow Feature Creep!
Wiki says: “Scope creep [feature creep] can be a result of poor change control. Lack of proper initial identification of what is required to bring about the project objectives. Weak project manager or executive sponsor.”
Do we need to say anymore? Feature creep happens if we let clients beat us around the head with lots and lots of adaptive requests.
9 Change Requests can be good, right?
For us a Change Request is something not yet outlined in the spec, it’s something new. The client needs more tech stuff and we are happy to oblige. A Change Request will require:
- Brief
- Requirements understanding/proposal
- Optional design stage
- Spec
10 It doesn’t stop when the website is built. This is the start!
Yay! All that hard work has paid off, your new website is now live on the internet, following our go-live checklist – which includes a whole host of double checks.
So now we can all sit back, right? No, no, no! Your website is a communication platform and it needs to engage an audience.
To engage effectively you will require a digital strategy: The strategy you outlined at the very start in your brief. To deliver those strategic needs, you need to work on an ongoing basis.
Will you need our help with this? The answer in most cases is yes. Technology is rapidly changing, it gets faster, stronger, better, smarter and more secure.
Your website – our tech – needs to interconnect with other tech outside of our systems, and any changes or updates may need maintenance to your website. You may also have design or functionality changes you want to add to your website.
Having a web maintenance/support budget is important going forward. Building on what you have, rather than tearing down every 2 or 3 years, in the long run, is much more cost effective and less risky.
We know this because our team have been involved in websites for over 15 years!
