Category Archives: Project

Adstream – UI Pattern Library

About the project

This was an effort to lay a foundation for all of Adstream’s future products, facilitate the work of both design and development teams, reducing the time it takes to create and deploy new features or modify existing ones by creating a UI pattern library that is part of a solid design system that unifies all of Adstream's products under the same visual identity.

What I did

I worked closely with the senior interaction designer and a team of developers to create a comprehensive design system from the ground up that worked across all devices and platforms. Doing research, creating the structure of our design system, visual designs, running tests, creating interaction prototypes, all sorts of UI/UX explorations, specifications, documentation and overseeing the final implementation. As the design system is an ongoing effort, I am also responsible for considering potential updates to it, new additions in terms of components, and making sure we are using our components correctly and consistently as our platform evolves.

Key accomplishment 🏅

The implementation of a well-structured design system has freed up an estimated 220 hours man hours per employee per month across both design and development teams which can now be allocated to other tasks.
An overview of how I documented our components. You can view the complete specs here in Zeplin.

Objective

The current version of the Adstream suite of products (v5) was built circa 2011-2013 and its parts were designed and developed by many different teams — some internal, some outsourced. As a result of that, both the user interface and common interaction patterns differed greatly across Adstream’s range of digital products. When we first started discussing v6 of the platform, we knew that was the perfect time to devise a solution that made it possible for anyone, anywhere to create experiences that felt part of the same ecosystem, while making it easier for whoever is creating it to do the right thing, regardless of them being a designer or a developer.
Design for spread and scale.
Denise Gershbein, Creative Director at frog
It was clear that we needed to put a stronger focus on our UI Pattern Library and this should be more than just a cosmetic endeavour. It should be a comprehensive design system and flexible enough to adapt to the ever-changing needs of this industry and our business.

Research

Components

I started out by looking at each of Adstream’s products and discerning common patterns and components. From the most basic such as labels, icons, buttons, checkboxes, radio buttons, dropdowns, accordions; to more complex combinations such as panels, user tables, different types of modals, and so on.
Some of my early sketches.
Having this granular approach allowed me to see the pattern library as a modular set of blocks we could put together to form larger and more complex structures. I didn’t go full on Atomic Design on this project but I did keep some of these principles in mind when categorising elements which definitely helped speed up the process and tie everything together nicely.

Deciding on a framework

The next step was to work with the development team and see what was readily available on the framework they were using to build the new version of the platform. Luckily they were using Angular Material which comes pre-packed with lots of useful components we could work with without much hassle. Some components would require a small amount of customisation, but for the most part, Angular Material provided a very solid starting point for what we wanted to achieve.

Grid

We chose to use a 1280px max-width grid system with 12 columns and 32px gutters as that provided greater flexibility for the most common scenarios in our platform. It’s important to keep in mind that this should never hinder us from pursuing other layouts if we believe those would be more usable. Having a grid system shouldn’t be a constraint. It should serve as a foundation on top of which you can build your product, but concessions must be made here and there.
To say a grid is limiting is to say that language is limiting, or typography is limiting.
Ellen Lupton, Curator of contemporary design at Cooper-Hewitt National Design Museum • NYC
As an example, on the Adstream Library, we have a fixed side panel of 320px on the left and that’s always there regardless of what device you are on. However, the main view to the right of this panel contains thumbnails of your assets, within that view we apply our 1280px grid, but in this particular case, the 320px panel is excluded from the grid. This allows our users to use their full screen real estate to preview their assets in the Library, which we validated as a better solution than constraining them to 1280px at all times for this particular case.
Screengrab shamelessly taken directly from Zeplin.

Typography

Typography and semantics are very important aspects of what makes a web application accessible to users who rely on-screen readers. For this reason, our approach to typography was to not use elements such as h1, h2, h3 to determine style. These elements are used for content hierarchy, making it easier for screen readers to consume the content and their style is limited to a specific font-size set in rem for which the base size is 16px. Styles such as font-weight, color, are all applied as modifier classes such as .font-weight-light, .font-weight-medium, .font-weight-bold, etc.
Effra is the typeface we used.

Iconography

We used an icon set that is based on a 32px grid size and 2px lines. The idea is to refine and redesign them as our product and brand evolves.

Colours

Colour is a key aspect of any interface and our approach to colour is to use it just enough to hint the user in terms of statuses, intents and visual cues that will make for an easier journey through their daily workflows. We do have a large set of colours to pick from, but the aim is to stick to as few as possible while thinking of the journey as steps. Never having more than one accent colour per step.

Primary

These are used for important actions and are bright and bold.

Secondary

These are used to support primary colours when necessary. They are slightly less saturated and lighter versions of our Primary palette.

Shades of grey

We would in some parts of the platform, have a need for a dark version of our UI. I kept this in mind when defining this palette. This is why we’ve got plenty of shades of grey to pick from, but essentially every colour on the shades of grey palette has an equivalent counterpart that provides enough contrast against a dark background and this principle applies to every component.
You can literally drop a .dark-ui modifier class to an entire section and have all its children adjust accordingly.
Hang on, here comes the best part… there you go!

Visual design

After deciding on solid grid and type systems and defining the colour palette, I then started designing each component with their different states in a manner that brought the entire library together and gave a sense of unity to the user.
Instead of prescribing the appearance of individual items, we build systems to anticipate them.
Heydon Pickering, Author of ‘Apps For All: Coding Accessible Web Applications’
At this stage, I ran lots of tests in HTML, CSS to see what was reasonable and these tests combined eventually went on to become a framework of its own that I ended up using to develop future high-fidelity prototypes for other areas of the platform when required. During the development of these tests, I used a BEM approach in terms of naming conventions for states and modified versions of components. Having a background in front end development gave me great insight into how I could make it easier for developers to implement this pattern library as well as how we could make it extremely flexible, scalable and somewhat future-proof – at least for a while. 😉 Semantics have always been very important in the realm of web development, especially when dealing with large enterprise level software. I’ve kept this in mind when developing these components, what this means is that wherever possible, elements use their correct HTML tags when available. This applies to button, input, nav, detail, ul, ol, li, table, and so on.
Adstream Wayfinder Pattern Library – Framework Prototype Preview it here. Made with: HTML, CSS, JS & jQuery

Interactions & micro-interactions

Below are some examples of the way we envisioned the micro-interactions on some of our components.

Internal resources

Sketch symbols library

Considering we in the design team at Adstream spend a lot of our time in Sketch, I’ve created a symbol library with all of our components that has really helped speed up our process when creating comps or even final designs. I’ve also revised it since the introduction of responsive symbols in Sketch 4.0 and have now made most of these components easy to adjust to whatever screen size we are designing for. The file also contains all of our text styles and color pallettes so that our designs are always consistent and we don’t need to ‘reinvent the wheel’ at each new project.
My Sketch symbols library with all of the Adstream UI components.

The framework

I also like to exemplify things with code when necessary. This really helps ground my work and convey my ideas in a more direct kind of way to our devs since HTML and CSS is ultimately the media these components will be based on. While some great looking things can be accomplished in the prototyping tools available these days, some ideas simply don’t translate well to real life scenarios. Here are some of the components I exemplified with code: Adstream UI Library – Tabs Preview it here. Made with: Angular Material framework — HTML, CSS & JS Adstream UI Library – Tooltips Preview it here. Made with: Angular Material framework — HTML, CSS & JS Adstream UI Library – Toasts Preview it here. Made with: Angular Material framework — HTML, CSS & JS Adstream UI Library – Radio buttons Preview it here. Made with: Angular Material framework — HTML, CSS & JS Adstream UI Library – Comments Preview it here. Made with: Angular Material framework — HTML, CSS & JS Adstream UI Library – Menus Preview it here. Made with: Angular Material framework — HTML, CSS & JS Adstream UI Library – Modals Preview it here. Made with: HTML, CSS & JS Using HTML, CSS and JS allows me to run quick experiments and tweak the details that will bring delight to our users like transitions, animations, easing curves and how responsive each component feels. It started as a set of quick experiments but after a while I had gathered enough to compile our own framework of components. We currently use this framework in specific cases where we need high-fidelity prototypes.

Specs & production

A design system is only as good as its documentation, so we have been documenting all the components with Zeplin and working closely with the developers in bringing them to life one by one. The new modules of the Adstream Platform (Library, Costs, and soon Delivery and Tasks) have already been designed with those new components and we are now in the process of rolling them out to our first users.

Conclusion

Having a pattern library in place has drastically improved our productivity. We are now able to spend more time prototyping, implementing, testing and iterating on ideas, instead of thinking about mundane things like how buttons or inputs should look or work. It lets us think of the bigger picture and be more… agile — there, I said it. 😬 It’s also great in the sense that we no longer get attached to our design decisions since they’ve essentially already been made for us, this allows us to ruthlessly scrap ideas that aren’t working and come up with new ones.
We need to stop worrying about proving the value of design and just focus on outcomes that provide value.
Denis Weil, Innovation Executive • formerly at McDonald’s
That said, a pattern library is an ongoing process. It should never really be finished. Components can now safely be improved upon and tweaked since they are their own modular entities and this allows us to revisit them often and make adjustments that won’t require an entire restructure of our platform or a massive version release.

References

When developing the Wayfinder pattern library I’ve used several online resources with the best ideas I could find to make the best possible solution. I’ll link to them below and hope you may find them useful:

Resources

Inspiration from other pattern libraries

Adstream – Library

About this project

This project kicked off my role as I joined Adstream in April 2016, at a time when the company was experiencing significant growth and a chain of many important events such as the acquisition of Dubsat, massive growth in Brazil due to a partnership with Globo, their expansion in the US market, big businesses won from both P&G and Disney/ABC, amongst other stuff.

As part of a big push to modernise the entire Adstream Platform, some preliminary ideas had already been concepted for the Library which served as my starting point.


My role

I worked as part of the Product & Development team alongside the Senior Interaction Designer, a Product Manager, 4 Developers / Engineers and the Analytics team. I worked on all UX, UI, visual and interaction design pieces from the ideas/concepts to final implementation of all individual stories.


What is Adstream

The Adstream Platform is the world’s leading cloud-based advertising workflow and collaboration software (SaaS) tool used by brands, agencies, studios and broadcasters worldwide to manage and deliver global creative content in both traditional and new media formats, connecting content to over 40,000 global destinations in over 116 countries. Everything on the Adstream Platform is searchable and reportable.


What is the Adstream Library

The Adstream Library is one of the main modules of the Adstream platform and it allows users to keep all their finalised assets in a central repository. It is Adstream’s Digital Asset Management (DAM) solution, used by hundreds of clients around the world to store, manage, track, and deliver marketing and advertising content.

It allows users to tag each and every asset with fully customisable metadata regardless of media type, making their libraries fully searchable and accessible from anywhere, at any time. It offers full reporting capabilities and provides visibility on how many times each asset has been shared, viewed, downloaded, by whom amongst other data points.

It is also fully integrated with our advertising Delivery workflow, making it very easy to digitally deliver final assets to broadcasters anywhere.


The problem

The previous version of Library (v5), was developed in 2012 on CHT, a custom framework developed by an internal engineer. This framework was great at the time, as it was tailor made for the very specific needs of the business. However, as time went on, it became harder and harder to implement new features or even revisit existing ones because so much of our platform relied on legacy code that was no longer being maintained. On top of this, very few of our engineers had the necessary knowledge of this framework to make any signifcant contributions to the code base.

Our chief architect pushed the idea to modernise the entire code base as a way to make Adstream flexible and scalable and the Library was chosen as the first module to be redeveloped due to its relative simplicity in comparison to other core areas such as Delivery and Projects.


Objective

Besides simply modernising the Library and aligning its visual design to the Wayfinder design system we had been developing, this was also a great opportunity to reevaluate some of the core functionality and add support to more modern workflows that had been neglected due to platform limitations, ie. Video on demand (VoD) and digital publishing that became more common in recent years.

This is what v5 looked like.

Research

Analytics

We started out by working with our Analytics team and pulling reports on various areas of the Library v5 to learn more about how users had been working up until that point.

Your old site is the best prototype of your new site.
Hoa Lorangers,
Director at Nielsen Norman Group

We found one of the most helpful indicators of usability was to look at a breakdown of all possible actions a user could take in the Library — things like uploading an asset, sharing it, previewing it, downloading it, etc. — and made our initial assumptions on what’s working vs what’s not, which actions should have more prominence and set our priorities based on those figures.

Certain features were hardly ever used. 'Add to a work request' for example had approximately 3-4 uses each month. Alongside product managers, this was essentially how we decided which features would be a priority for an MVP and which ones would be pushed back or removed entirely.

One of our usage reports.

Competitive analysis

I looked at other similar tools to try and pick out interesting patterns and get a sense of how similar tasks could be completed with slightly different approaches. I also wanted to see whether there was a gap in feature set when comparing our Library to other tools.

My analysis comprised simple aspects such as:

  • Selecting a file and how that affects the actions that are exposed to the user.
  • How additional details such as activity / history logs are presented.
  • How files can grouped, tagged and therefore searched, sorted and filtered.
  • Opening vs previewing a file.
  • Hierarchical structure — folders and subfolders vs groups or collections.

To more complex interactions such as:

  • How the file browser aspect of each platform functions and behaves. There is a huge divide between it feeling like you are in an internet browser vs feeling like the platform is a native file browser like the Mac Finder or Windows Explorer. The latter approach is the current trend as it’s a lot more intuitive and usable overall, hence it was favoured for this project. It offers things like context menus, off-canvas elements, actions that are exposed based on your selection, drawing a shape to select files and using keyboard hotkeys to select multiple ones, single / double / right click functionality, to mention just a few.

Long story short, most of my inspiration for this project came from the products below. Even though the only direct competitor in this list is Bynder, the others provided me with ideas on how to approach certain features such as displaying assets in lists vs tiles, selecting, sorting, previewing different types of media, etc.

  • Dropbox
  • Dropbox Paper
  • Google Drive
  • OneDrive
  • Outlook
  • InVision
  • Bynder
  • Getty Images
Quite a lineup. Props to them for being such amazing digital products!

IA & sketching

It was paramount that the architecture, structure and language of the new Library matched the priorities of our users.

We started those explorations with simple sketches and wireframes as these were the quickest way to test new concepts and get them to a stage where layout, messaging and the flow could be assessed. This happened over many sessions with the team.

Here we were aiming at structuring content, reviewing navigation patterns, testing layouts and screenflows in a way that made sense while not straying too far from what made the Library such a powerful tool.

You can use an eraser on the drafting table or a sledge hammer on the construction site.
Frank Lloyd Wright
I love how sketches and wireframes abstract details away and force you to focus on what really matters.

Prototyping & user testing

Once we were happy with our results — and after a few internal usability and feedback sessions with members of other teams — it was time to do our homework so we could properly test things out and hear directly from our users — which is the most exciting part!

This being enterprise software we had to keep in mind most of our users don’t actively choose to use our systems, their organisation often chooses it for them.

Because of this, it can be difficult to get a hold of users for testing, but once you get access to them, they will often have a lot to say about your product and most the time are quite happy to provide feedback on things that could potentially make their lives easier.

For this particular case, we approached a few agencies and asked for a few contacts that would be willing to participate in our tests. We explained they would be sent a link with a script to try out the new Library.

All we had to do was prepare a script and a prototype they could play with. Long story short, we snuck some analytics scripts into our prototype and measured them on completion times, dwell times and total task completion. We tested things like uploading an asset, tagging, sharing, searching and sorting which cover 90% of what users typically do in the Library.

Adstream Library – Prototype
Preview it here.
Made with: Axure

This is what our prototype looked like.

Results

We found that most users were able to complete the tasks quite easily and were mostly happy with the new version of the Library.

The only pain point raised was creating and managing collections, which essentially work as ‘smart folders’ or ‘rules’ in Outlook. You set a few rules based on metadata and every time something is added to your Library that matches those rules, that new asset automatically becomes part of the Collection(s) it matches.

We learned that users needed a clear visual distinction between what is a ‘loose’ asset and a collection. This led us to effectively split both into their own areas, which is reflected on the visual designs you see below.


Visual design

We now had everything we needed to start refining the visual design and making sure this wasn't just a UI refresh but a chance to improve upon the overall experience for our users.

All asset (grid and table) views, collections view and asset preview (document, video, image, audio).

At this stage I also produced some prototypes to save us a few headaches and have a chance to test and refine things like layout and interactions before the developers started writing code. Here are some of them:

Adstream Library
Preview it here.
Made with: Angular Material framework — HTML, CSS & JS

Adstream Library – Collection view tree navigation
Preview it here.
Made with: Angular Material framework — HTML, CSS & JS

Adstream Library – Collection view masonry layout
Preview it here.
Made with: Angular Material framework — HTML, CSS & JS

Adstream Library – Collection tiles proof of concept
Preview it here.
Made with: HTML, CSS & JS

Adstream Library – Tile view
Preview it here.
Made with: Angular Material framework — HTML, CSS & JS

Adstream Library – List view
Preview it here.
Made with: Angular Material framework — HTML, CSS & JS

Adstream Library – Audio player
Preview it here.
Made with: Angular Material framework — HTML, CSS & JS


We also reviewed and documented some smaller stories such as the frame grabber (pretty self-explanatory, only avilable on video files) and devised systems for things like comments and activity feeds in a way that made them more contextual.

Screen flows done for the frame grabber tool that is avilable on video files.
The spec document for our activity feeds.

Specs & production

We then documented every story in this epic to allow the devs to start bringing the Library to life. We used Zeplin for specs which saved us a lot of time and did weekly catch ups to make sure we were all on the same page and could spot inconsistencies early enough to fix them.

All different views and layouts have been documented and described in Zeplin where we keep all our official design documentation.

Shipping

We are currently rolling out the new version of the Library to a few selected groups of users and are monitoring adoption and usage to iron things out as a beta test before a full roll out to all users.

The system we used to roll out the trials. Users are asked to try the new Library and later asked to provide feedback via a quick survey.

Conclusion

The new version of the Adstream Library highlights and surfaces its real strengths — a powerful industry-leading digital asset management tool, backed by an amazing new user interface that speaks to our users and responds to their most specific needs.

In our tests, we found that not only were users able to understand the new ways to complete tasks they were used to doing a certain way in the past, they were also able to take it up a notch and create their own new, modern workflows based on the Library’s new — and more solid — foundations.

Adstream – Costs Module

About the project

Adstream partnered up with P&G to develop an advertising production costs estimation module within the Adstream Platform's Projects area that – according to P&G's estimates – will save them approximately US$500 million a year by allowing them to track their production expenditures every step of the way.


What I did

I collaborated with our internal Strategy and Accounts teams, as well as with P&G, their partner agencies and real users from end to end, ranging from interpreting high level requirements, producing flows, scenarios, sketches, wireframes, user tests, visual designs, interactions and micro-interactions and all sorts of UI/UX explorations, as well as adapting the entire experience to mobile devices.

During the process, I worked closely with the senior interaction designer, the product manager and a team of developers.

The team

Key accomplishment 🏅

This new module saves P&G US$ 500 million a year allowing them to precisely track advertising production expenses and solidifies Adstream’s presence in P&G’s global workflows, which in turn leads to a stronger relationship and further revenue being secured for years to come.

Hero

What is Adstream

The Adstream Platform is the world’s leading cloud-based advertising workflow and collaboration software (SaaS) tool used by brands, agencies, studios and broadcasters worldwide to manage and deliver global creative content in both traditional and new media formats, connecting content to over 40,000 global destinations in over 116 countries. Everything on the Adstream Platform is searchable and reportable.


Adstream and P&G

The Adstream Platform has been a growing part of P&G’s marketing and advertising workflow in the recent years. P&G already uses the modules available on the Adstream Platform to manage their Projects, Asset Libraries, Reports and Deliveries between agencies and broadcasters worldwide and mandate all partner agencies and their third parties to run their workflows within our platform due to its transparency and reporting capabilities.

Considering P&G is the world’s top advertiser in the world having spent US$8.3 billion in advertising in 2015, a key part of their workflow is being able to set a budget for a given project and estimate production costs that stay within this set amount, while accurately tracking where money is being spent and the changes that happen along the process; From estimation, to an indefinite amount of revisions, first presentation, final approval through to delivery.

Prior to the existence of this new module, P&G was able to run their entire workflow within our platform, except for this estimations process for which they used an internal legacy tool.

The addition of this new module effectively turns Adstream into a complete end to end solution that handles the entire advertising workflow.

Once developed as a custom solution for P&G, we will monitor it, gather our learnings and roll out the new module to more Adstream customers as part of the Projects area.


The brief

Business objective

Our challenge was to design a replacement solution to P&G’s existing dated tool for content production cost management, aka ‘AdCosts’.

The purpose of the solution is to effectively gather and highlight changes in content production costs from the original estimations, in order for P&G to approve, contain and report on them within the Adstream Platform.

As part of the solution, Adstream are also required to build the mechanisms for triggering the creation of Purchase Orders (for the costs captured within the Cost Module), through integrating with P&G’s finance system, COUPA.

Problem to solve

The current system is fragmented, inflexible, lacks transparency and reporting capabilities, and isn’t as user friendly as users would like it to be. It also involves a good amount of manual work which ends up costing several man hours and decreases the efficiency of all parties involved in the cost estimation process.

Constraints

The system should have restrictions to allow users to only view and approve costs based on their user rights and access limits.

P&G provided us with exports of what their current tool outputs. This current implementation is a legacy tool that’s been used for several years throughout all of P&G’s offices worldwide and is a big part of their current workflow – not to mention their culture – so it’s important to maintain the same output while improving on the user experience and expanding on functionality.

The ideal scenario is to develop a tool that satisfies P&G’s needs but can also be spun off into a more generic tool that can appeal to other potential Adstream clients and partners.

Design goal

Optimise workflow, increase efficiency, reduce the amount of time it takes to create, review and approve a cost, all while offering more granular, transparent and complete reports.

Who is it for?

The Costs module will be used by all parties involved: agencies, 3rd party providers and P&G themselves on various levels of access determined by the scope of each production project.

Agreed scope

  • Ability to fill out the cost form in a non-linear fashion; Auto-saving feature so users can come back later to finalise creating a cost and submit only when they’ve gathered all the required metadata
  • Ability to add multiple production, post production, music, 3D, CGI / Animation vendors and having this reflected on the total costs overview broken down by types of expenses
  • Ability to add as many revisions as necessary to a cost in between the key stages (AIPE, Original Estimate, First Presentation, Final Actual)
  • Ability to see what changes were made to a cost from its previous stage
  • Ability to reopen a cost after its final approval. It’s not an ideal scenario, but a necessity nonetheless
  • On costs where the budget region isn’t North America, ability to upload a budget form (xls or csv file) to auto populate the costs table with individual line item values


Process

Although not a strict rule, the usual process I follow is:

Research › IA › Wireframe › User test › Visual design › Prototype › User test › Report › Review

I’ll then iterate, refine and retest assumptions as necessary. The process I followed for this particular project wasn’t too far off from this and a more detailed explanation is described below.


Pre-study

  • In testing the viability of taking this project, the Strategy team raised a list of competitors and carried out a competitive analysis from which the key finding was that by adding this new module to our platform we would become the only player capable of offering true end to end solutions to the advertising workflow. We as designers took this competitive analysis and used it to evaluate how our competitors managed a similar process. This list included Bynder, Widen, Workfront, Oracle Cloud, and many others.
  • Our Strategy and Accounts teams liaised with the client to structure and approve a document with the technical requirements for this project.
  • Since we did not have access to the current tool we were designing a replacement for, we started out by analysing reports exported from said tool and reverse engineered them in order to be able to – at the bare minimum – recreate the same output.
  • We also gathered a list of required metadata fields for each part of the process. This included logic-driven metadata collection which this Costs module heavily relies on.
Research

Discovery phase

IA

We looked at the required metadata fields and developed a simple flow that streamlined the cost creation process, determining at which point to collect the required metadata and breaking the process down into smaller chunks.

This was already a big shift from P&G’s legacy tool which was designed to gather all metadata in one single – and massive – form, regardless of budget amount, production type or region.

We wanted to simplify this by introducing the concept of progressive disclosure and making the cost creation process contextual to the production type selected by the user in an attempt to reduce the cognitive load and consequently decrease the time it took to complete the task.

Data
This is the data structure we created to collect a cost's metadata.

We devised several potential workflows/scenarios for the high level usage of the costs module. The workflow below illustrates an Approval from the primary perspective of an Agency, but also includes how P&G would interact with this agency during the process.

Approval Workflow Map

Since everything revolved around the creation of a cost and we now had a clearer idea of what that would be like, we then started thinking of what other parts of this system would need in order to function and created the following structure we named 'tracks':

Costs areas

Sketching

At this stage I started sketching things out as a way to prioritise content and exemplify the overall navigation patterns for creating a cost and a costs overview area the user would see when a cost was created.

We started experimenting with different navigation approaches such as steppers, accordions and wizards, which we would eventually come back to refine during the visual design phase that came after initial testing.

Sketches
I feel like I should thank Bunnyfoot for giving out these grid pads during some event I attended. They were extremely useful as you can see!

Wireframing

We then moved on to laying out basic rough ideas of the structure of these pages. Below is an example of the Costs Overview area. These were very crude-looking, but served the purpose of laying the foundation for the basic structure of the data collection process and how things would be placed around the screen.

Wireframe - Costs overview

Prototyping

Once we had a good grasp of the ideal structure of the platform, what the user journey would be and how we would approach collecting the user data, we presented our ideas back to P&G.

The overall feedback was positive and our solutions were making sense, but we noticed the abstract nature of the wireframes were a slight barrier in our communication with them at this stage.

For this reason we felt the best course of action was to use a higher fidelity prototype, using as close to our real UI elements as possible in an attempt to remove this barrier and create as few distractions to our test subjects as we possibly could in an attempt to get more reliable data to work with.

We started polishing up the wireframes and bringing them up to speed with Adstream’s new UI language before moving on to building them as prototypes for our initial user testing sessions.

As part of the creation of the Wayfinder design system we were developing in parallel, I created a set of Sketch symbols with our essential UI components that really helped speed up this process.

These prototypes were then built in Axure with some added logic-driven conditions for us to monitor.

Prototype

User testing

For the usability sessions, we built 3 prototypes along with scripts based on key use cases:

  • Scenario 1 – 1 agency + full video production with shooting
  • Scenario 2 – 1 agency + 2 costs within the same project
  • Scenario 3 – 2 agencies + video production cost

Methodology

P&G appointed a few key users that fit the use cases above and we sent them an email with a link to the prototype and the respective script. All they had to do was follow the script in order to complete a task (eg. create a new video production cost), while we had tracking running in the background.

These were our actual end users from P&G’s wider teams across the globe so their feedback was invaluable at this point and we knew we had to make really good use of it.

We tracked mouse path information, dwell and completion times, created a few tunnels to monitor drop-off vs completion rates and gathered heat maps to help us figure out whether users were getting stuck and where. This was achieved by using tools such as Hotjar and Mouseflow while the Axure prototypes were being hosted on Axure Share.

Upon reaching the end of the script and completing their assigned task, users were presented with a short survey asking about their general feeling towards the new solution being presented and an open text field for suggestions and/or questions.

Email sent out to users
Example script
The email we sent to test subjects as well as a preview of the script we asked them to follow.

Results

All of this feedback was collated in spreadsheet form to which we then added our own comments with action plans and considerations.

User feedback

As we didn’t want to make users go through any sort of sign up process, we couldn’t exactly tell which user corresponded to which lines in each report so we cross referenced all this data with their IP addresses to figure out where they were logging in from and make an informed decision on who they were.

These users were used to working a certain way in their previous platform so we knew there was going to be some resistance and possibly use cases we did not foresee, so all this data would help guide our design decisions from this point onwards.

We then redid some of our previous screens in order to accommodate their feedback and after the higher level stages of the process had been defined and validated, we moved on to building a higher-fidelity prototype outlining some of the micro-interactions and incorporating a few copywriting tweaks to clarify some of the actions.


Visual design

Some of the feedback we received during our usability sessions placed particular emphasis on the visual design aspect of what we presented. Users seemed happy with what they got to try out, even though it was still at a very early stage:

I like the simplicity and how clean it looks. The layout is similar to today which will help the user from a navigation perspective.
Head of Marketing, Drafted Inc. – Boston, MA – USA
The Cost module works perfectly and it is easy to fill out and follow the steps. I love the progress chart, that is a nice addition.
Producer, Saatchi & Saatchi – London – UK

That gave me a good idea of the things we were doing right and things we should probably change. Earlier in the process, when outlining the user journey maps for the new module, the general approach was that it should be broken down into the stages below. For that reason, I chose to think of the visual design by following this same structure.


Navigation

One of the ideas that popped up during our early explorations was to use a stepper system in order to unify the processes of creating a cost and reviewing a cost. We believed using a similar navigation pattern for both tasks would ellicit some familiarity from the user's perspective, making the new process easier to understand.

We did extensively explore other ideas as well such as wizards and accordions, which we created visuals for to test internally but nothing came close to being as user friendly as the stepper system in our tests.

Navs
Some iterations of our stepper ideas.

We refined those ideas taking into consideration we needed areas to display errors, indicate progress and completion status and, after several rounds of internal tests, locked it down into the following system:

Navs

Building a cost

When creating a cost, users should be able to do it in a non-linear fashion. Any changes they make to the form are automatically saved so that they can come back and continue from where they left off until they’ve gathered all the metadata required to submit the cost for approval. We identified early that this was a common use case.

The video below illustrates the overview area as well as the cost creation process.

Building a cost

Interaction Prototype – built in Principle

Navigation Prototype – HTML, CSS and JavaScript


Reviewing a cost

When reviewing a cost, users should be able to clearly see its current stage, status and the amount of revisions it’s had so far. They should also be able to track the changes made between each stage as well as see an activity log of that particular cost.

Interaction Prototype – built in Principle

Navigation Prototype – HTML, CSS and JavaScript


Mobile

On mobile, due to platform limitations and use cases we identified, the initial approach is to allow users to consume content (ie. review an existing cost) rather than create new costs.

Mobile screens
Interaction Prototype – built in Principle

Conclusion

The Costs module is currently under development and scheduled for release in late February.

Once shipped, we will then start monitoring usage and keep an eye on our customer satisfaction reports, platform analytics and go out to meet with users to follow up on what this new module feels like to them after they’ve had the chance to use it for a little while.

We’re not aiming at getting everything right the first time, so we will definitely be making adjustments as we gather their initial impressions to make this an even better tool that P&G and other clients can rely on to make their daily lives easier.

Adstream – InDesign Plugin

What I did

I worked closely with the senior interaction designer, the product manager for Library, members of the Print Support team and a team of developers, on everything ranging from interpreting high level requirements, producing flows, scenarios, sketches, wireframes, user tests, visual designs, prototypes, interactions and micro-interactions and all sorts of UI/UX explorations, through to creating development specifications.


Key accomplishment 🏅

Offering a solution that integrates the Adstream Library with Adobe InDesign is a strategic move that essentially solidifies Adstream’s presence as a strong player in print-based workflows by giving current users less of a reason to leave to a competitor, while increasing brand value and potentially attracting new print business, leading to larger market share.


Objective

One of the key aspects of the Adstream Platform are the capabilities it offers to print-specific workflows. Many studios, agencies, production and post-production studios use the platform to keep track of their projects, assets and collections as it allows for easy tagging, sorting, searching, annotating, sharing and version control.

A big part of the typical print workflow involves using Adobe InDesign to create a multitude of formats, and given this scenario, the Product team at Adstream were tasked with creating a solution that bridged the gap between InDesign’s powerful desktop publishing capabilities and the Adstream Platform, creating a seamless experience.


What is Adstream

The Adstream Platform is the world’s leading cloud-based advertising workflow and collaboration software (SaaS) tool used by brands, agencies, studios and broadcasters worldwide to manage and deliver global creative content in both traditional and new media formats, connecting content to over 40,000 global destinations in over 116 countries. Everything on the Adstream Platform is searchable and reportable.


What is the Adstream Library

The Adstream Library is one of the main modules of the Adstream platform and it allows users to keep all their finalised assets in a central repository. It is Adstream’s Digital Asset Management (DAM) solution, used by hundreds of clients around the world to store, manage, track, and deliver marketing and advertising content.

It allows users to tag each and every asset with fully customisable metadata regardless of media type, making their libraries fully searchable and accessible from anywhere, at any time. It offers full reporting capabilities and provides visibility on how many times each asset has been shared, viewed, downloaded, by whom amongst other data points.

It is also fully integrated with our advertising Delivery workflow, making it very easy to digitally deliver final assets to broadcasters anywhere.


Brief

Scope

Develop a Mac-only InDesign plugin that integrates with the Adstream Library and allows users to:

  • Place assets located in their Library into InDesign as linked assets.
  • Save local InDesign links to their Library, thus making them remote links.
  • Check links for missing or modified statuses and allow users to fix them accordingly.

Problem to solve

Users can currently keep track of their project, assets, libraries and collections within the Adstream Platform and take advantage of its version control feature to ensure they’re always working with their latest approved assets.

However, they currently have to download said assets and work with them locally. It would make their lives a lot easier if they could link directly to their own assets in the Platform, as well as being able to relink files that have been modified with a more recent version.

Constraints

The plugin should ideally be built as a native plugin that lives within Adobe InDesign. However, due to time constraints and technical limitations it will initially be developed as a standalone Mac application.

We have also suggested it be made as a MacOS menu bar plugin for future releases and provided specs for such.


Research

Competitive analysis

I looked at similar plugins being offered by other digital asset management (DAM) platforms such as Bynder, WebDAM, and Widen to see different possible approaches and take note of how they handled a similar process:

  • Whether they were standalone apps, web views within InDesign, drag and drops directly from the browser or true InDesign add-ons
  • What the process to save, place and update was like
  • How natural the integration looked and felt in terms of visual consistency

Although these plugins felt a little cumbersome to use and a little out place in terms of visuals, we knew we had some pretty strong competition in terms of functionality.

“Does it better” will always beat “did it first.”
Aaron Levie,
CEO at Box

Journey mapping

We developed a few scenarios / storyboards to cover the main use cases and determine what the ideal user journey would be like. We locked it all down into 3 main paths: 'placing from', 'saving to' and 'updating linked media'.



Some of the journey maps we created.

Sketching

I sketched out some of what I figured would be the most important steps before moving on to more refined versions of the UI and micro-interactions.


Visual design

The visual design was practically dictated by our UI Pattern Library and this being an InDesign plugin, it made sense to make use of our dark UI which is more in line with the Adobe suite of products and most likely what users would expect.

It also ties up nicely with our goal to make this experience feel as integrated with what Adobe InDesign users are accustomed to as possible.

This is how my Sketch symbols ended up being at the end of the project.
Design is not art. It is about crafting solutions to real issues.
Mark Boulton
Picture taken at one of our mapping sessions.

Essentially, after mapping out all the required screens and modules to allow users to complete their journeys, I was able to start putting together the visual designs and testing them out as prototypes with our internal Print Support team who have been in the industry for several years and have extensive knowledge of our users and their workflows, many of them coming from print studios themselves.


Prototype

I created a simple click-through prototype in Adobe XD to test out the user journey with a few internal stakeholders from the print support team and collect their feedback and thoughts.

Journey test — Placing workflow
http://adobe.ly/1WiEhCj
Made with: Adobe XD


Documentation

The development of this plugin was handled by a branch of our development team based in Australia, so we had to minimise time spent reworking and provided pretty detailed specs. We chose to use Zeplin to make this process easier.


Conclusion

The plugin was released in November 2016 and we have been monitoring usage, analysing tracking data and customer support reports to see whether our implementation satisfies the needs of our users.

The response has been positive so far and I attribute that to the fact we kept things as simple as possible, focusing only on the core functionality such plugin requires, without any added fluff.

We aim to keep an eye on those stats and continually iterate and improve on our solution as needed.

MOL – Ad Specs

About the project

MailOnline has a very large and diverse offering of digital display and native products. There are about 40 different ad formats ranging between desktop, tablet, mobile, across web and apps. Not to mention all the new formats currently in development. Part of the projects that are sold to clients are designed and built in-house by the MailOnline Creative team. However, a lot of the time, clients, media agencies and their creative agencies prefer to build things themselves. This web app was designed and built from the ground up to fill this necessity. It aggregates all of the digital offerings and fleshes out every little detail the external creative teams might possibly need in order to complete their work.
Hero

What I did

I worked with a Project Manager, the Head of Creative, the Ad Operations Manager, the Sales Director, one of our Account Managers and a few of his clients to run some basic research, competitive analysis, set design goals in response to this fundamental need of the business.
team
I also gathered the ad formats data from various sources, structured and normalised it into a concise and easy to digest spec sheet, common across all formats before solving the underlying problem through visual, UX and interaction principles by designing the Ad Specs web app from the ground up.

The problem

The email conversation below illustrates a common scenario we were trying to solve. In short, our clients would often want to get a sense of what formats they could place on the MailOnline website, how to build them and ideas of past executions so they could get their campaigns up and running and set basic metrics to track and figure out whether their campaigns were returning their investments.
Convo
This was a real problem in terms of productivity because as simple as it may seem, the MailOnline did not have a centralised source for such data. Account executives had to rely on their own backups and would often send out outdated specs to clients who would in turn become very frustrated once they realised they were sold (and paid a lot for) the wrong thing. In summary, our problems were:
  • Information in too many different formats (spreadsheets, presentations, PDFs)
  • Not easily accessible
  • No central repository
  • No one owns the data
  • Too many different versions scattered around the business
  • Not easily kept to up-to-date
  • Spec sheets are not standardised or comparable
  • Client does not fully know what they bought
  • Ads are built and delivered to Traffic based on wrong specs
  • Clients end up frustrated due to mismanaged expectations
  • Disappointed clients tend not to give us repeat business

The brief

The initial reaction was to approach the solution as a mere direct replacement to what the MailOnline had at the time, ie. spec sheets in digital form (PDFs, PPTs), except this time they would be aggregated and centralised. I thought this wasn't the best approach so I suggested approaching this a scalable tool, an online repository that someone within the business could truly own and maintain. It made sense to empower the Creative team within the MailOnline to be the gatekeepers to the MailOnline Specs.
Chat

Research

Proto-personas

I started this project by analysing what types of users we were trying to communicate with. The primary users being creative / agency types and therefore familiar with the technical ins and outs of ad serving platforms and rich media, it was safe to assume the information should be easily accessible and using technical terms wouldn't necessarily get in the way. Non tech savvy users also had to be catered for however, so clearly stating format names as recommended by the IAB was a great way to make sure they knew exactly where they were. The rest of the team and I created a few proto-personas that we would often come back to during the development of this tool. We found having these proto-personas was a great way to remove ourselves and our own biases and ideas from the process, allowing us to approach it more objectively and with the end users in mind.
Personas
The main users of the site would include MailOnline's own sales team, brands, media and creative agencies working for their digital clients, each having their own unique set of goals. The internal sales team would be after simple specifications: where formats sit on the MailOnline page, their dimensions and where these formats are available on the site. They’d also constantly have to show clients what formats they had sold in, this is why the site creates unique persistent URLs for each format – a feature we added on release 1.1. Clients and creative agencies would be after the techy side of things: Flash Player version, file size limitations, whether it can run on mobile devices or not, build templates, etc.

Competitive analysis

Looking at what other similar sites did to organise their data, I noticed most of them seemed to have trouble classifying information in a way that made it easy for the user to compare between different formats – ie. not all formats used the same fields, even naming conventions and some of those websites weren't even public, forcing you to request access and wait for a response.
Competitive Analysis
I judged each site based on a few simple pointers to serve as a benchmark for us.
I made the assumption, that was later validated by clients, that every ad format should follow a defined set of fields such as dimensions, accepted formats, initial file size, maximum FPS, loops, etc. while keeping a separate area for unique details. This way, every spec sheet would be similar and differences would be easy to spot at a glance and compare.

Scope

After all the initial research, we concluded our scope should be divided into the two parts below.

Users should be able to

  • See the placement area and how it relates to the content
  • See a preview of past campaigns that used that same placement
  • See on which pages / channels a format is available
  • See full technical spec sheet
  • Be able to easily compare between different formats
  • Include IAB standard formats as well as bespoke ones
  • Ability to download creative templates of each format
  • Scalable system to grow as our offering grew
  • Ability to be maintained by the design team without much effort

The site should strive to be

  • Performant and snappy
  • Easy to update
  • Simple to navigate
  • Cater to various levels of knowledge
  • Transparent and reliable

Data gathering

I then started collecting all the ad format data. Some of it came from our Ad Operations team and some had to be collected from other departments. There was a lot of back and forth at this stage since some of the data was missing and it was important to fill those gaps and provide full spec sheets for every format. Once collected, this data was then used to generate the downloadable packages that also included build guides, Photoshop / Flash templates and printable versions of the spec sheets.
Collect
What our spec sheet used to look like.

Data sort

I sorted all the data into categories and normalised them into the same spec sheet so they could be easily compared and clients could get a better understanding of what they were buying into.
Sorting
normalize

Sketches

Now I had a good grasp of what we were trying to accomplish, I then started sketching out ideas and coming up with ways to navigate and represent this data structure.
Sketches

Prototypes

The overall consensus was to narrow it down to two main ideas: a navigation that functioned around accordions and one where the content could be swiped in a carousel-like fashion. I quickly built these two options as HTML, CSS and JS prototypes so that we could get some early feedback from potential users. You can test them via the links below.
Prototype 1 – Accordions
Preview it here.
Made with: HTML, CSS & JS Prototype 2 – Carousel
Preview it here.
Made with: HTML, CSS & JS
On both versions, the large preview at the top is directed at brands and media agencies, and illustrates where a format sits on the page, how much space it occupies and how it relates to the content. On option 2, the switch toggles between the placement and a real life example, so clients can see what the possibilities are with said format which was a very common request.

Feedback

Option 2 received much more positive feedback, mostly due to the fact it requires fewer interactions in order to access the spec sheets, and the overall layout makes it a lot easier to compare them. The 3-column layout also makes it very easy to navigate through formats. Users can either use the nav menu on the left, the prev and next arrows on each side or simply use their left and right keys on their keyboard. This makes it easy for a potential buyer to compare between multiple formats they’re interested in.

Visual design

The visual style of the site should cater to all these different users while still maintaining MailOnline’s branding elements. There was no branding style guide defined at the time, apart from the coloured bar that symbolises the multiple channels across MailOnline. Hence the decision to use one main accent colour – orange in this case – and more neutral colours of similar shades for all the other elements. The typography works alongside the colour scheme to provide a clear sense of hierarchy and break things into smaller, easy to digest sections. The 3-column layout breaks the site down into navigation, main content and additional information for easy navigation and makes most of the information accessible while minimising the need to scroll.
UI elements
A few examples of the UI elements and overall design system used on the app.
I also devised a visual system that allowed us to show whether a placement supported expansions or had sibling elements. The idea was to show formats within their native environments and near realistic – although redacted – content.

Build and scalability

This being a very dynamic area of the business, it was clear from the start that the website would require constant updates and should be built on a framework that simplified the process of adding, removing or modifying existing entries. All of the data resides in a JSON feed, making this a very flexible setup, with next to no overhead and allowing the Creative team to own this data source and keep it up to date without being limited by technicalities.
Build
In order to keep things lightweight and performant, the data source is only queried from the server once during the initial load. It is then stored locally and only 3 spec sheets are generated at any given time, with 2 empty shells at either end. This improves performance by saving memory as opposed to rendering all spec sheets even when they're not being displayed and allows transitions to be really snappy and responsive.
Carousel

Future iterations

As mobile didn’t represent such a big market for MailOnline at the time the site was built (circa 2013), the website wasn't built with responsiveness in mind. After the initial release, we noticed more and more users were accessing it from mobile devices, possibly in between meetings or while out and about with clients. This prompted me to start working on a reimagining of the tool that took all that into account while improving on the existing functionalities, such as adding search capabilities.
Features
Feature wish list for v2.
This prototype is a result of my own personal ideas and explorations at the time. This was just before I left the MailOnline so I'm not entirely sure it has been picked up and whether it was ever developed. You can test the prototype by following this link.
Innovation

Reflections and conclusion

Looking back at this project now, I'm happy with the end result and very pleased that clients and internal teams have a tool that is not only reliable, but allows them to focus on more important aspects of their work. It's a win-win for me as a product designer. That said, there are quite a few things I would have liked to do differently if given the opportunity. This project came with some pretty big constraints I would like to touch on:
  • Small team

    This was both good and bad; Good because despite us having specialists of many fields in the team, no one truly knew how to conduct research, create hypotheses and validate ideas. So I was forced into wearing many hats and doing things slightly outside of my usual remit (research, planning analytics) which allowed me to learn a lot simply by doing.

    The downside is not having specialists to seek guidance from and make sure I was on the right path.

  • No development resources were allocated for this project

    I doubled down as a designer / developer for this project. While it was incredibly fun and I'm well versed in front-end development, dealing with a back-end to store all of the ad format data required a kind of knowledge I didn't possess at the time. I did my best to find a solution that met our needs but I would have much preferred being able to hand this part off to a back-end developer who could do it more elegantly.

  • No research resources apart from contact with clients and internal stakeholders

    This ties up with what I already mentioned above about us having many specialists from different areas in the team but no true research insight to help us validate our assumptions. While it is the role of a good product designer to create reasonable assumptions to get an idea off the floor, having input from a research specialist is invaluable and adds a lot to the value of a product.

  • Lack of a branding styleguide

    When this project started, the MailOnline did not yet have a branding style guide. One would only be introduced years down the line. This meant we didn't have a whole lot of direction to go off of when coming up with a visual style for this tool.

  • Heavy time constraints

    We had a very short turnaround for this project which meant we had to make a few compromises, particularly in the areas of research and visual explorations. I am confident in the navigation patterns we chose, but I feel the visual aspect could have been worked on a bit longer had we had more time.

MOL – Showcase

About the project

The MailOnline Showcase site serves as a portfolio of what the Creative Team has historically produced so that potential new advertisers can have a better understanding of what they'd be buying into in terms of execution.


What I did

I came up with the concept of laying things out in tiles containing appealing images of past campaigns, while giving the user complete control over what they see through a filtering system.


Wireframing

It was safe to assume the website would start with only a few projects but would eventually grow to hold several of those tiles. The challenge was to make it visually interesting regardless of how many tiles were on screen. The "empty" slots are marked with placeholders for that reason, so the page never feels empty.

Wireframing

UX

Since the user would be able to use several types of filters - channel, format, device, category - my main concern was in keeping navigation simple instead of overwhelming the user with options. Additionally, the OFF button provides a quick way to disable all active filters.

Filters

Design & UI

The concept here is that content itself is what makes the design instead of adding unnecessary elements. The tiles are comprised of the format name, client it was developed for, a short description and upon clicking, a live preview of said format is launched on a new tab.

The filters are basically a list of checkboxes, this way you can tick multiple ones in order to chain them together and expand your search.

Design & UI
This is the loader I created for when the page is loading. It is done with CSS keyframe animations and uses the colours of the different MailOnline channels.

Build

The back-end for this site is a simple JSON feed that can be easily updated by anyone on the design team. All they have to do is generate a thumbnail image and create new nodes in the JSON file.

Code

Mobile specific

Some of the formats we created are better experienced on real mobile devices instead of emulated through a desktop browser.

For this reason, I have also created a separate mobile-only Showcase site.

This is a neat little tool the sales team can use to show clients what the real experience would feel like before closing a sale. You can check it out here.

MOL – US Ad Sales

About the project

MailOnline is the world’s biggest English language newspaper website. In August 2014 it had over 180 million global unique monthly visitors with 60 million visitors from the United States.

This website serves as a platform through which the DailyMail US team can communicate announcements, their latest stats and present advertising solutions to potential clients.


What I did

I worked with the Trade Marketing team to come up with the best way of presenting their data and making information as accessible as possible while empowering them to maintain the website and keep it up to date.


Discovery phase

We knew this should be a one-pager from the get go, where data would be broken down into easily digestible chunks.

The trade marketing team had a pretty good idea of what kind of information they would like to showcase and even some creative ideas of how they would like to present them.

We had a few conference calls where we discussed those ideas and how we could bring them to life. We also sorted the data in order of importance so that we could make informed decisions and position things on the page. After nailing all of that down, we moved on to the wireframing phase.

Project image

Wireframing

We knew what sections the website would have and a rough idea of how they would be stacked. This was the stage where we had to decide what type of content each section would hold. Amounts of images, length of copy, and essentially the entire structure of the site onto which we could build all the functionality that would make it usable.

We went back and forth with a few wireframes until we were all happy with the main structure before moving on to hi-fidelity sketches, mock ups and UI elements.

Project image

Visual design

The visual design takes follows MailOnline’s branding guidelines and sticks to a certain colour pallette. The idea is taht the content should make the design, so the UI tries to get out of the way and simply present the content.

That’s not to say it doesn’t introduce delight by means of smooth transitions and animations throughout the journey. I particularly like how we resolved the navigation elements into a burger icon on smaller devices, transitioning the options in a staggered manner when the user clicks to open it.

This is one of my favourite pieces in the UI work I did for this site. You will only see it on mobile breakpoints.

The contact form is quite cool as well: when you try to submit without filling in a required field it indicates that by shaking the fields. Submitting is pretty delightful as well with a nice reassuring confirmation that your message was successfully sent – without nasty page reloads, too.


The header

The header is a chapter in itself. The original concept came from the US team themselves. They wanted a header that would really catch your eye and showcase what DailyMail.com is all about: celebrities, strong headlines and incredible numbers.

I suggested we created a composition with lots of celebrity images, a few stats and headlines from our site and kept shuffling through them every few seconds.

Performance was a big concern to me, so I made sure to optimise images as much as possible while ensuring no unnecessary elements are rendered. I also leveraged CSS transitions rather than JavaScript for the animation effects due to their improved performance in this case.

I used the isotope plugin to order the tiles, CSS to create the background animations and JavaScript for the subtle parallax effect you see when scrolling down the header.

All animations stop once you hit the header threshold, this ensures the site runs as smoothly as possible and performance doesn’t take an unnecessary hit.

Project image


Development

I knew the site should be built on a CMS that allowed it to be maintained by the marketing team themselves without them having to deal with any code or go through any technical hurdles.

I decided WordPress would be the way to go due to its user friendliness and wide array of plugins that would make the site a breeze to update to people without previous experience in managing a website.

I built a custom theme while using a few plugins to facilitate content management that allowed for a truly visual interface for each of the custom fields the team would have to update in the future.

In practical terms this means, for example, that image galleries behave as real image galleries where images can be added or removed through a visual interface, unlike most themes that require the user to input a URL to the image they want to display.

Project image

Post launch

The site has been a success and is proving to be a valuable tool for the American team. So much so that the Australian team have recently shown interest in having their own version of the site with a few minor tweaks to make it more in line with their market.