• How we work

Our philosophy

Our philosophy at Tickbox is to create web technology and tech products that impact positively on the world around us. Our vision is: Tech for good!

To this end we often work with charities, community groups, heritage organisations and councils.

We also create smart digital tools for businesses which have a positive impact on their business model.

Since 2007, we have striven to improve how we work, to always achieve the best results for and with our clients. Websites are virtual constructions and like any physical construction (or building) they need several specialisations to achieve a successful web development:

  • Web and Marketing strategy / digital engagement
  • Web Planner/Project Management
  • Front-end coding (html/CSS programmer)
  • Web design
  • Web copy and Search Engine Optimisation (SEO)
  • Back-end developer/app developer (building complex systems)
  • Quality control and testing
  • Ongoing maintenance

Think you can get the above in one person? Think again! It takes years to get a technical web specialism and you learn by doing, working with other professionals, following processes and protocols that are always evolving.

Here are our 10 Tickbox – Tech for Good commandments that best reflect how we work.

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:

  1. Client brief
  2. Proposal of services – Tickbox requirements understanding
  3. Design brief, design ideas as mock-ups
  4. Development specification
    4.1 [content plan/client provides data/content]
  5. Pre go-live checklist for testing
  6. Go-live, post-live testing
  7. 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.

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.

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.

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.

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.

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.

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!

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.

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

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!

VAT No. 901 2662 60 | Company Reg. 05887989 | Registered Office: Tickbox Marketing, Desklodge House, Redcliffe Way, Bristol BS1 6NL