Development Phase

The production phase is where the magic happens, where designs and plans start coming to life. Your developers code and integrate the design assets, create user interfaces, and implement functionality.

For WebGL projects, this phase includes translating 3D models into a format suitable for WebGL and ensuring that the design intent is preserved in the 3D environments - which entails a tremendous amount of testing.

This phase requires close collaboration between the 3D artists, designers, and developers and can be a lot of fun.

First things first, the paper trail. Confirming the technical specifications with the client is not always mandatory, but on large projects with heavy stakes it definitely is. These specifications outline the detailed technical requirements of the project and serve as the roadmap for the development team, they also clarify all potential areas of ambiguity so that the client is on the same page as your technical team.

You can use the questions outlined in the template to start working on the technical specifications with your technical director or lead developer. Using the template document provided in the course to set up the contractual agreement.

Next, schedule a meeting with the client to go through the technical specifications in detail. This meeting can serve to clarify any questions or uncertainties, and provide an opportunity to discuss potential changes or enhancements. Make sure they’re inviting their technical stakeholders to avoid wasting anyone’s time!

Once you’ve sent the recording, production bible and assets to your development team you’ll need to schedule a design-to-development call to give them a forum for questions, 99% of the time there will be small areas of oversight that the creative team will need to fix - plan a few days of work for these tasks at the very least.

Finally you’ll want to make sure those design guidelines are ready for developers, your art director should have listed font-sizes, font-weights, paddings, margins etc…

3D to development for WebGL projects is a unique process which is difficult to teach, at least for me. I’ve seen it go many different ways, but it’s never an exact science. As a rule of thumb the 3D artists and developers will need to work hand-in-hand to ensure that the 3D models are correctly exported, optimized, and implemented into the WebGL framework.

Once they’re visible in the scene your creative team will look at the models and animations in the greater context to give feedback, as will the client, and the process starts again.

The designs need to be properly aligned with the technical constraints of WebGL, and any animations or interactions should be tested thoroughly to check they function as intended. I don’t recommend working with artists who are unfamiliar with these constraints as their models will likely be unusable, either as a result of file size or poor file structure.

Once the majority of development is complete, it's time for playtesting. This sprint is about user experience - ensuring the game or digital experience feels right, is fun to play, and meets the original design intentions from that proposal that was made months earlier!

Playtesting often involves a mixture of internal testing (with the production team) and external testing (with a select group of end-users). The feedback from this phase is important and can lead to design adjustments or development tweaks to improve the product.

At this point your product is unlikely to be properly functional on anything other than desktop.

Once the development phase has reached a milestone where a functional version of the project exists, it's time to deliver the staging environment to the client for their first review. A staging environment is also called a dummy environment, it’s a clone of the current version of product that allows for testing and review which will be continuously updated until the final deployment.

You’ll need to test the staging environment and determine whether it’s ready for the client or not, generally this is your responsibility. If you decide against it you will need to explain the delay to the client if they are expecting the delivery.

Nine times out of ten I recommend delaying if you aren’t comfortable with the state of the project, their first impression will only happen once and you want to make it count to avoid causing confusion, anxiety and unpleasant consequences. The frustration that comes from a minor delay is much easier to handle. This first review is an opportunity to demonstrate the progress made on the project and set the tone for the remainder of the development process. Use it as a chance to reinforce the client's confidence in your team's abilities and the project's direction.

Before presenting the staging environment to the client, create a guide that walks them through the project and points out the key functionalities and features. This will give them a better understanding of the project and prepare them for the review. For this, as with many other use cases during the course, I recommend using Loom.

Leave the client with access to the staging environment and encourage them to spend time interacting with it. Ask them to provide feedback on your tool of choice, noting any potential improvements or adjustments they'd like to see.

Now you can schedule a call to go through the feedback and discuss their impressions of the staging environment.

Each development phase comes with its unique set of challenges. Issues can arise in communication, technical constraints, asset delivery, or unforeseen user feedback during playtesting… It’s endless.

The more experience you have the more you’ll see these challenges before they unravel, but in the meantime rely on your technical director to give you red flags and act on them quickly and transparently.

While your team is busy developing the project, an equally important task is ensuring that the client is comfortable using the content management system (CMS) upon launch. The pool of available CMS tools is vast, your client or team will dictate that one.

It’ll be useful for you to understand the two main types of CMS: headless and traditional.

Your job here will be to coordinate client onboarding, which is the process of introducing them to the CMS's features and functionalities that will be key in integrating content during the end of your development phase, and subsequently to manage and update the project post-deployment.

Start by recording a few videos to give them general introduction to the CMS, explaining what it is, its purpose, and how it functions as the backbone of the project. Provide an overview of the user interface, demonstrating the various sections and controls. Walk them through the process of adding, editing, and deleting content, managing user roles and permissions, and other essential operations.

They can refer back to this guide in the future and look at your video instructions rather than come to you and ask questions every single time.

This phase will need to be included in your timeline, it is often the cause of delays on my projects. The client will want their website ready as quickly as possible but they often won’t have anyone with the bandwidth to handle the content integration (if they have the responsibility to do so). Since this content integration needs to happen to properly test the site it creates a delay in your production timeline.

You can warn them as these deadlines so that they plan someone in advance to support them, or you can provide this assistance as a part of your original scope.

Familiarise yourself with a few major CMS tools.