What to expect during the web development process

Here we’re going to have a look at what our approach to web development looks like and how what we’re building impacts that, so you know what you can expect when working with us.

The biggest driver to defining our approach to a project will be the customer brief.  We generally find that briefs fall into one of three categories:

• There is a full understanding of the final product

• There is uncertainty in the full scope of the work, but customer knows what is to be delivered

• There is a problem, which needs solving

Depending on the type of brief we tailor our approach in order maximise the chances of a successful outcome. Applying the same ‘cookie-cutter’ approach to all types of projects risks missing valuable opportunities that the customer could benefit from or ultimately failing to deliver the right end-product at all.

Immersion

As a full-service agency, we’re lucky enough to have experts on hand in all facets of digital marketing and we work collaboratively to deliver the best possible product at the end of each project. Where we excel is collectively working with the customer to explore ideas and approaches to bring together a fully scoped piece of work where previously there was uncertainty around the brief or a problem without a solution.

In many agencies it’s not the case, but we believe it’s important to include the project’s development team in the early stages of a project. This allows them to understand the objectives of the project and build relationships with key stakeholders just as much as creatives or marketers, so they’re well positioned to make and justify technological decisions that are made throughout the development phase.

Discovery

Of course, as developers, our interest is primarily in the technical aspects of the project and regardless of the complexities of the build we will always invest time in understanding customer requirements, business logic and any third party integrations which make up the project. This activity forms part of our ‘discovery discussions’ and underpins our understanding of the project.

At this stage, a customer will need to provide information such as:

• Existing functionality and business logic

• Details about integrations with third party services

• Having a clear understanding of project objectives

This information might already exist in documentation or the original brief, but we also run workshops to map out data flows, processes, and decision trees in order to better our understanding of the nuances of each unique build.

The primary output her will the functional specification document that completely defines the scope of work. Where the project is following an Agile methodology, we’ll have a Minimum Viable Product (MVP) in mind and a backlog of tasks to action when the development kicks off.

Strategy

When we have a concrete understanding of what needs to be built, the internal delivery teams will devise a plan for delivering the end-product for approval by the customer. By this point, depending on the methodology being applied, we will have finalised the technological approach to the build in terms of application design, programming language, and software.

Our project management and delivery teams will bring together the delivery road map by breaking down each functional requirement into smaller deliverables which will form the bulk of the project timelines.

The road map will cover not only the actions that we undertake but also deliverables for the customer, project milestones, feedback stages and finally approval.

Development

In many cases the bulk of the project plan will be during the development phase and depending on the scale, a project could be actively worked on by one or more developers.

The size of the team is driven by the type of work being undertaken, how it is split between different specialties as well as the budget and timelines. Though it might seem it, it’s not always efficient to have more developers working on the same codebase and we’ll use our experience to select the optimal number of technical team members to work on the build. As the project progresses, should requirements change, the resource can scale up or down.

As the project is being coded, there will still be regular communication between customer and the delivery team. We tend to favour fortnightly progress updates where we can demonstrate our progress against the project plan, however there will be contact between these where required for feedback, clarification or working with third parties.

We actively avoid developers working in isolation in their role and will continually work with UX and UI designers and SEO experts to make sure what we’re delivering is visually and technically excellent.

User acceptance testing (UAT)

As the project nears completion our team will have measured the web application against the functional and non-functional requirements and performed rigorous testing covering accessibility, cross browser rendering, and device compatibility, we will then handover the product to the customer for UAT.

The UAT phase is designed for the customer to validate that business logic has been correctly applied and data is flowing through the correct channels.

Once it’s accepted that the code delivered is functioning correctly, we move towards getting the application launched.

Deployment

There are several processes which need to be followed to ensure a successful ‘go-live’ and each change depending on whether we’ve been developing a new greenfield project or re-platforming an existing application. The approach to ‘go-live’ will already have been detailed and documented during the strategy phase of the project, at this point we’re focused on completing the project and ensuring a smooth and most importantly stress-free launch.

Often the big considerations are new content and managing DNS (Domain Name System) changes however, re-platforming a website is a little more complex in terms of launch. There will be considerations to be made around data migrations to make sure orders, subscriptions and other important data is taken from the current site and made available on the new.

This may mean accepting some downtime to prevent new data being added to the old database which is especially important when working with legacy self-hosted eCommerce systems. It’s important to remember, once DNS propagation has been completed, unless provision has been made otherwise the old website and its data won’t be accessible post-launch.

Some customers manage their own DNS whilst others are happy for us to support them with making changes. Whichever is the preference, we’ll provide detailed instructions for the change process and what can be done ahead of time to ensure a quick propagation.

And that’s it. A process which can last from just a few days to months has ended and a new idea or iteration on an existing product has been launched.

Ongoing support

It’s cliché but following a go-live the hard work really starts. We’ve specifically designed packages of ongoing support for new and existing projects that allow customers to benefit from not only our expertise in web site and web application development but also other services that Logic+Magic offer.

As we already have an in-depth understanding of how the project fits in to overall business objectives and workflows we can work with customers to document road maps, secure regular feature development resources and manage ongoing security and performance optimisation tasks.  Everything to ensure the success of the build over a long-term strategy.

Our aim is to become a valuable technology partner to all our customers and continue to work collaboratively, long after the initial project has launched.