EngineeringUK’s noble aim is to grow the next generation of engineers – in both number and diversity – by creating inspiring, exciting and informative programmes that represent future career opportunities. To help achieve this mission, teachers give children a taste of what it’s like to be an engineer through first-hand experiences. EngineeringUK had the idea of creating a new platform to help teachers choose the best experiences offered by a range of partners and contributors.
It was a complex challenge to create one destination that could deliver on this grand plan. EngineeringUK had already invested in a research study to ensure the project would be successful, and to navigate some cynicism. This initiative required a groundswell. They brought us on board to make sure that the strategy landed and to design and build an intuitive platform.
The Full Story
How do you get under the skin of an idea?
The initial invitation to tender outlined the EngineeringUK team’s idea, with a detailed description of the desired feature set. This was accompanied by some top-level branding work and a prototype interface to demonstrate the product. The initial challenge was not only to build on the team’s previous thinking, but also to pick it apart to really understand the rationale behind some of the key decisions. Thanks to the team’s prior work, we were able to quickly get to the heart of the product, and define exactly what the service should and shouldn’t be.
We identified that the product is primarily a discovery tool for teachers to compare experiences from a range of different providers in one place. We also wanted to showcase the breadth of experiences available from providers, from speakers to trips to competitions. These insights led us to challenge the original prototype and to rethink the overall navigation approach. We then added the concept of curated collections, which would bring together related experiences with the aim of getting teachers to plan around multiple experiences during the course of the year.
Understanding your audience defines your minimal viable product
This platform has two distinct audience groups: teachers (who are looking for experiences) and providers (who are facilitating those experiences). After some initial research we discovered that while there are thousands of potential teachers who would benefit from this product, there is a smaller group of providers available, each of which offered only a handful of relevant experiences.
This led us to prioritise the teacher audience for the minimum viable product (MVP) release, and deprioritise a self-service portal where providers could manage their offerings.
We recommended the creation of a new role: a content manager. The content manager is responsible for liaising with potential providers to ensure the quality of their experiences, and to input that content into the content management system (CMS). The new role brings an added benefit, giving the content manager the opportunity to network with providers to better understand the kind of content they want to include on the platform. This experience and knowledge would provide a unique learning opportunity for the platform’s first incarnation, and provide real insights to steer further iterations.
How do you give stakeholders confidence in making decisions quickly?
With tight time constraints, we needed to work smartly. We had to give a traditional organisation the confidence to make decisions quickly. The brand identity, including the always-contentious product name, needed to be agreed in a matter of weeks.
Fortunately, with the ear of a strong CEO and a clearly communicated rationale driving all of our decisions, we were able to generate the momentum we needed. Our iterative and highly collaborative approach also helped to generate agreement across a swathe of stakeholders.
How do you use the platform to drive inclusivity?
The initial platform concept was focused on real-world experiences like organising a trip around a factory or arranging a performance to take place in your school. So the service was centred around location-based searching, with teachers asked to identify their school in order to find nearby experiences available to them. To simplify this, teachers selected their school from a drop-down list, driven by a GOV.UK database of schools.
This approach let EngineeringUK see the schools that had yet to engage with the platform. The marketing team could use this data to reach out to teachers at unengaged schools and make them aware of the opportunities available to them. In a later development to the platform we built on this idea, using the GOV.UK database’s information about certain diversity and inclusion criteria to target schools in disadvantaged areas.
How do you build and name a brand in three weeks?
EngineeringUK wanted to introduce the new platform as a separate entity to stand apart from the existing Tomorrow’s Engineers brand. Starting with a blank slate, and with only three weeks available, we needed to move quickly.
To absorb as much of the team’s knowledge as possible, we packed the first week with collaborative workshops. These helped us determine how the new platform should look and feel, and what it should be called. We ran some brand positioning exercises to clearly articulate the platform’s purpose and differentiators. We ran a design review exercise to get the team expressing their reactions to different visual styles. Through these exercises we started to develop a common language, in both linguistic and visual terms. This helped us to align our collective vision for the new platform.
Once we’d agreed on some vocabulary that felt relevant to the project, we started building an element collage to visualise the design direction and make sure it felt appropriate.
We ran a separate workshop to focus on naming the new platform. We discussed particular characteristics we wanted the brand to embody, as well as those we wanted to avoid. Working against the clock, we each generated as many name ideas as possible, based on four separate categories: descriptive, experimental, metaphorical, and abstract. We dot-voted to reveal the most popular ideas and discussed their merits as a group.
We wanted to make sure the name would be accepted within EngineeringUK. To include the wider team in the process we posted the top five proposed names in the office kitchen, inviting staff to vote and comment. “Neon” was the clear winner: short, distinctive, aligned to the brand values, easy to spell, and likeable.
As soon as the name was decided, we started logo development. Although we wanted the logo to have some visual connection to the chemical element, we didn’t want it to look like a generic neon sign. Inspired by curved glass tubing, we considered how we might construct elements and patterns from a handful of simple geometric shapes. The logo was constructed in this way, resulting in a wordmark that felt aligned to the values we’d agreed with the team: crisp, playful, fresh, and confident. We produced a selection of patterns to suggest materials and structures that could work across the many subtypes of engineering. We also suggested a potential “career path” visual device built using the same elements.
Based on feedback on the element collage, we defined design foundations, including typography, colours, and icon and graphic styles. These became the starting point for the website design.
How do you create a collaborative three-way engineering partnership?
Due to the compressed timelines we needed an efficient and fluid partnership between the team at EngineeringUK, the designers and developers at Clearleft, and our friends at Umbrella. Clearleft designed the experience and developed the front end, Umbrella built the back end, and the team at EngineeringUK were responsible for injecting their excellent content before getting the whole thing live.
Umbrella acted as the bridge between Clearleft and EngineeringUK, receiving front-end code from Clearleft and website content from the EngineeringUK content manager. They worked their magic to create the back end that would power the entire platform using Umbraco.
As an agile project rather than a waterfall one, there were course corrections throughout. The cross-functional, multidisciplinary team that included product, design and development allowed for quick, well-informed changes based on the knowledge of all parties. Umbrella helped us to understand what kinds of data structures were available, based on a desired user experience. Conversely, Umbrella could feed back on any platform constraints, allowing us to modify our front-end components accordingly.
Often we’ll hand over a library of these components to the client as a project deliverable. In this case though, they were a means to an end. Working in a component-based way ensured that the front-end code was robust. Each component was like a miniature test case. Best of all, Umbrella provided API endpoints we could use to populate the components with real data. That took much of the guesswork out of the process.
Visit the Neon website.