•

Developer tooling for template creation.

A user centered product designed to assist creative developers when they are building visual HTML templates for advertisements.

Company

•

•

The problem

The original task was to assist Creative Developers when creating HTML templates.

The biggest problems user faced was the long checklist of technical things to do to be able to get a template compatible with the platform: steps which were often prone to error or entirely missed. These resulted in too many time consuming tickets landing on our support teams desk.

I spoke with several creative developers from our different agencies and concluded that I'd focus on solving these key problems:

This early discovery locked in the idea that instead of trying to build our own code editor, it would be better to let the users to continue using their preferred tooling and Visual Studio code happened to be one of the best in class IDEs.

The original plugin was built around the command line, where users could type in shortcuts to perform certain functions, which is a feature I kept in, but as additional functionality - it was too hidden to be the main way users should interact with the tooling.

Impact.

150+

Regular users of the plugin.

~65%

Reduction in display template related support tickets.

22 minutes

Average time saving per template created.

The Wizard.

The first ideation was to exploring the wizard vs the checklist approach. Despite the necessary steps being non-linear, the wizard approach made the most sense as they were all required in order for a user to complete their task (creating and uploading a template).

The final result was somewhere between the two; a wizard when building a new template and a checklist pattern when working on an existing template.

The output of the wizard would include the following:

The output of the wizard would include the following:

Despite the steps being non-linear, a wizard pattern ensured users complete all mandatory tasks in order to be able to start a new template - avoiding missing steps.

Step 1: Allow users to start a new template or convert an existing template to work with the platform. This gives backwards compatibility so users don't have to rebuild entire templates from scratch.;

Step 2: Visual studio code works with the workspace concept, this is just the folder that the template files will live in.

Step 3: Adds a title and description that appears on the platform.

Step 4: Enables users to select the size of their template. I future proofed this step as currently only a single size is possible, however responsive templates are a topic the teams will pick up this year.

The list of sizes follow IAB standard sizes, but we also needed to allow bespoke sizes for edge cases.

Step 5: Advertiser selection requires the user to log into the platform and select which advertiser this template is for.

Step 6: This is the most complex step where users link "Placeholders" from the template to the platform. The placeholders are HTML elements that hold content which can be easily changed without having to edit the template. The example content is an additional feature, which enables users to see a visual preview of the template on the platform - something which is not currently possible as without this, users can only see a blank canvas.

Step 7: We allow the use of Google fonts as default.

Users can select fonts which have already been uploaded to the Advertiser.

The output of these 7 steps is a boilerplate that contains HTML, CSS and JavaScript files, ready to be customised and uploaded to the platform.

The sidebar.

When working on a a template, the user can always access the plugin through the native sidebar.

The sidebar gives users quick access to editing their template, where each option will take users directly to that step of the wizard.

As well as easy editing, two essential features were brought up multiple times in user interviews, which were live previewing of templates and an easy way to export their template; both directly to the platform as well as a local .zip file, which is essential for them to be able to use templates on different platforms.

Columns with each reviewers status appears on the overview table once approval requests have been created.

The CLI.

During the beginning of my research, I discovered that a creative developer from one of our main agencies had already started building a plugin for Visual Studio Code to streamline his workflow and output a template boilerplate.

His approach was to enable the use of functions users could access via the built in Command Palette in Visual Studio Code.

This approach only solved the error prone half of the problem, users were still able to easily miss steps. To alleviate this, the solution pointed towards an interface with either a checklist or a wizard.

Despite this, keeping the commands in the new design was a nice feature to keep for power users, it just couldn't be the primary way a user interacts with the plugin due to it being hidden away.

As well as easy editing, two essential features were brought up multiple times in user interviews, which were live previewing of templates and an easy way to export their template; both directly to the platform as well as a local .zip file, which is essential for them to be able to use templates on different platforms.

Plugin functions are quickly accessible via the Command Palette.

Process.

Interviewing users.

The first step for me on this project was to identify the users who are creating these templates. We already had a list of proto-personas where only one applied to this topic - the Creative Developer, where I interviewed a couple from each of the main agencies that work with our tool.

The output of these interviews was the documentation of the steps necessary to build templates as user flows and a list the main issues that cost them the most time.

Interviewing the plugin developer.

One discussion with a user revealed that he had already been working on a plugin to assist him and his team in creating templates for our platform.

He took me through his work and shared his thoughts and ideas - this user ended up being a key collaborator and the key to the project's success.

Interviewing the support team.

One of the project KPIs was to reduce the number of support tickets coming in related to the usage and creation of templates. These tickets tended to take the most time for the team to solve as every problem was unique due to the nature of custom templates.

I had a session to walk through all related tickets from the previous six months. The bulk of the support tickets tended to be small human errors, for example forgetting to include the required JavaScript libraries, or having mismatching placeholders.

Key takeaways.

Checking technology stacks with stakeholders.

One important thing to validate after interviewing the plugin developer was to check that his approach to the problem space would be viable for our business.

Creating and supporting a single plugin would be fine, however if the tooling was split between several developer IDEs, the concept would become unsustainable.

Fortunately I discovered that the vast majority of creative developers across all the agencies are using Visual Studio Code and if they were not, the users were not opinionated on their tooling and were willing to make the switch.

Competitor analysis.

Choreograph has several competitors in which I looked at their current workflows (Flash talking, Celtra & Hogarth) and documented / annotated on a Miro board.

Tooling outside of the typical ecosystem that involved the management and commenting of bulk assets was also looked at, one example being frame.io.

Prototyping & testing.

I created a prototype for the wizard part of the flow, seeing if the users could complete the wizard, whilst understanding what each step did.

Testing the entire end to end workflow was done via a prototype built by a developer, where I held sessions with the Product owner to test both the user and the output.

Developer tooling for template creation.

Developer tooling for template creation.

Company

The problem

I spoke with several creative developers from our different agencies and concluded that I'd focus on solving these key problems:

Prevent users from missing a step.

Impact.

150+

Regular users of the plugin.

~65%

Reduction in display template related support tickets.

22 minutes

Average time saving per template created.

The output of the wizard would include the following:

Output the boilerplate with all required libraries, metadata and validation.

Directly map the template variables with the platform content placeholders.

Template upload directly to the platform

Quick template version updates.

The output of the wizard would include the following:

Output the boilerplate with all required libraries, metadata and validation.

Directly map the template variables with the platform content placeholders.

Template upload directly to the platform

Quick template version updates.

Despite the steps being non-linear, a wizard pattern ensured users complete all mandatory tasks in order to be able to start a new template - avoiding missing steps.

Step 1: Allow users to start a new template or convert an existing template to work with the platform. This gives backwards compatibility so users don't have to rebuild entire templates from scratch.;

Step 2: Visual studio code works with the workspace concept, this is just the folder that the template files will live in.

Step 3: Adds a title and description that appears on the platform.

Step 5: Advertiser selection requires the user to log into the platform and select which advertiser this template is for.

Step 7: We allow the use of Google fonts as default.

Users can select fonts which have already been uploaded to the Advertiser.

The output of these 7 steps is a boilerplate that contains HTML, CSS and JavaScript files, ready to be customised and uploaded to the platform.

The sidebar.When working on a a template, the user can always access the plugin through the native sidebar. The sidebar gives users quick access to editing their template, where each option will take users directly to that step of the wizard.

Columns with each reviewers status appears on the overview table once approval requests have been created.

Plugin functions are quickly accessible via the Command Palette.

Process.

The output of these interviews was the documentation of the steps necessary to build templates as user flows and a list the main issues that cost them the most time.

The output of these interviews was the documentation of the steps necessary to build templates as user flows and a list the main issues that cost them the most time.

Interviewing the plugin developer.One discussion with a user revealed that he had already been working on a plugin to assist him and his team in creating templates for our platform.

He took me through his work and shared his thoughts and ideas - this user ended up being a key collaborator and the key to the project's success.

He took me through his work and shared his thoughts and ideas - this user ended up being a key collaborator and the key to the project's success.

Interviewing the support team.One of the project KPIs was to reduce the number of support tickets coming in related to the usage and creation of templates. These tickets tended to take the most time for the team to solve as every problem was unique due to the nature of custom templates.

I had a session to walk through all related tickets from the previous six months. The bulk of the support tickets tended to be small human errors, for example forgetting to include the required JavaScript libraries, or having mismatching placeholders.

I had a session to walk through all related tickets from the previous six months. The bulk of the support tickets tended to be small human errors, for example forgetting to include the required JavaScript libraries, or having mismatching placeholders.

Key takeaways.

Allowing developers to continue use their preferred tooling was a great direction for both them and the business, as it is cheaper than building an entire development environment within the platform.

Checking technology stacks with stakeholders.

Fortunately I discovered that the vast majority of creative developers across all the agencies are using Visual Studio Code and if they were not, the users were not opinionated on their tooling and were willing to make the switch.

Fortunately I discovered that the vast majority of creative developers across all the agencies are using Visual Studio Code and if they were not, the users were not opinionated on their tooling and were willing to make the switch.

Competitor analysis.Choreograph has several competitors in which I looked at their current workflows (Flash talking, Celtra & Hogarth) and documented / annotated on a Miro board.

Tooling outside of the typical ecosystem that involved the management and commenting of bulk assets was also looked at, one example being frame.io.

Tooling outside of the typical ecosystem that involved the management and commenting of bulk assets was also looked at, one example being frame.io.

Prototyping & testing.I created a prototype for the wizard part of the flow, seeing if the users could complete the wizard, whilst understanding what each step did.

Testing the entire end to end workflow was done via a prototype built by a developer, where I held sessions with the Product owner to test both the user and the output.

Testing the entire end to end workflow was done via a prototype built by a developer, where I held sessions with the Product owner to test both the user and the output.

The sidebar.

When working on a a template, the user can always access the plugin through the native sidebar.

The sidebar gives users quick access to editing their template, where each option will take users directly to that step of the wizard.

Interviewing the plugin developer.

One discussion with a user revealed that he had already been working on a plugin to assist him and his team in creating templates for our platform.

Interviewing the support team.

One of the project KPIs was to reduce the number of support tickets coming in related to the usage and creation of templates. These tickets tended to take the most time for the team to solve as every problem was unique due to the nature of custom templates.

Competitor analysis.

Choreograph has several competitors in which I looked at their current workflows (Flash talking, Celtra & Hogarth) and documented / annotated on a Miro board.

Prototyping & testing.

I created a prototype for the wizard part of the flow, seeing if the users could complete the wizard, whilst understanding what each step did.