Life of Your Code
Year: 2019
Client: Google Cloud
Users created their own trains which functioned as apps. They got to put the train together by selecting different types of services. Once the train was built, users deployed and tested them as well.
The large LED screen showed all the users launched apps (trains)
OverviewLife of Your Code is an interactive demo showcasing Cloud Run, a serverless technology from Google to build, test, and deploy applications. We created an ELI5 (explain like im five) version using trains and railroads to allow the audience to understand the product easily.
Role
Design lead
Art direction
UX design
Design lead
Art direction
UX design
Impact
- 20,000 Attendees
- 40+ custom installations in various scales
- 400+ Googlers interacting with customers and partners
- 8,000+ total engagement
- 2,500+ daily experience engagements
- 2,000+ leads captured
- Experience extended on Google Cloud Showcase site
Context & ChallengeThe experience was featured at Google Cloud Next, a three day conference bringing people in the cloud computing industry together. In order to grab people’s attention and educate them about Cloud Run, we were tasked with translating its serverless application technology in a simple and entertaining interactive experience. The problem of the demo is that it’s a tool that can be used for any and every industry. We didn’t want to stay focused on one industry so we leaned on using analogies and metaphors to explain how the technology functions.
Key Target UsersWe were able to discern attendee profiles from event registration data. Once we recognized the types of users that will be coming to the event, we were able to set the right level of interactivity for the installations.
30%
Developers 30%
IT + Business Decision Makers
20%
CEO/CTO20%
OthersWe have identified the developers and the IT/Business decision makers as the main users of the interactives. They are the ones that will be hands on the job so we had to make sure there was enough substance for them to see under the hood and poke around all the buttons and dials.
However, that doesn’t mean we should count out the C Suite audience. For the CEO/CTOs that are less likely hands on, we had to make the experience easily followable from a distance.
The ProcessAfter doing our inital homework, the Creative Technologist and I facilitated a brainstorm+sprint session where we briefly explained the technology while looking for metaphors and analogies that alined with the product. We created concept sketches of the analogies which allowed us to have an open conversation with the stakeholders.
Once the right analogy was figured out, it was off to the races with wireframes and figuring out the details of the analogy. We collaborated with the stakeholders closely to make sure key components of the technology and their benefits aligned with the visual metaphors.
Discovery
Concept 1
Concept 2
Concept 3
The goal of coming out of the sprint with three strong concepts was achieved. These initial concepts were then shared with the stakeholders to be used as talking points in the stakeholder kick off.
After the kick off with the stakeholders, I was able to identify the main touch points and the typology of interaction. The diagram above was used to clearly indicate the four steps and the relationship between the user, main touch point, and secondary large screen.
Building and launching a rocket.
Using a rocket to represent the application that is being built, attendees take on the role “launch team” to modify payload parts in preparation for launch.
After modifying components, attendees step through a standard pipeline, compiling their code into a container, running tests, and deploying to production.
Using a rocket to represent the application that is being built, attendees take on the role “launch team” to modify payload parts in preparation for launch.
After modifying components, attendees step through a standard pipeline, compiling their code into a container, running tests, and deploying to production.
Building and launching a train.
Focusing on representing applications as a train, made up of containers that attendees have built and deployed. Many containers can be worked on independently, contributing to a larger whole at the same time.
Focusing on representing applications as a train, made up of containers that attendees have built and deployed. Many containers can be worked on independently, contributing to a larger whole at the same time.
Building and launching a car.
Using cars to symbolize the application that is being built, attendees become part of a “pit crew” where they are able to modify individual parts of a car before deploying the built and tested application. Attendees can focus on the engine, drive train, wheels, or body of the car.
Using cars to symbolize the application that is being built, attendees become part of a “pit crew” where they are able to modify individual parts of a car before deploying the built and tested application. Attendees can focus on the engine, drive train, wheels, or body of the car.
It was also time to select a metaphor that worked the best with the product. Because Cloud Run treats one application with multiple services, the stakeholders and our team both agreed that the train analogy worked the best. The cohesiveness of the train and its ability to keep adding services (cars) was the winning metaphor.
User Flow
Wireframes
1. Start screen
2. Add your car screen
3. User selects attributes and sub attributes to customize the appearance and functionality of their train car. Code snippets are shown for each selection
4. Edits are complete! A user can add another train car or continue on to test
5. After they’re done adding cars, they move into the test phase. User taps a button to run tests
6. One error is found in the build.
7. User sees the specific car where the error is found
8. User is taken back to build mode and shown the error. They are asked to make another selection to resolve it.
9. User corrects the error and the demo re-tests.
10. All tests are successful. It’s time to deploy.
11. User is prompted to deploy their train using a physical level
12. Train is successfully deployed and user is prompted to view the train gate closing down as their train is sent off
13. When the attendee’s cars have been created, the cars get added to the existing train. The big screen shows the cars linking up together as the cars are deployed. Attendees can work together to “complete” a full train and launch it.
14. Once the train is completed, an animation of the train leaving the train yard is shown. The barricade in front of the screen goes down while the red lights blink on and off.Iterations First round of wireframes were iterated and defined with more specific content. The trains also got a visual make over as the stakeholders made decisions over train types.
Conclusion We decided that the entire train can be symbolic of an app, like a blog, and each cars can be different services. The entire train would have it’s own purpose while the individual cars can be configured.
GIF animation substituted for Pushing Code, and Building stages that’s automatically handled by Cloud Run.
The Final Send off
Once the train leaves the front kiosk, it appears on the large LED screenThe trains go through a central load testing station. This station is a stand in to alert the users that their apps are accepting queries and that they’re processing the queries correctly.
Experience documentation on YouTube from Google Cloud
Press and Extension
Tech Crunch
Google Cloud Showcase version iterated by Hook
Reflection It’s always difficult fully understanding stakeholders’ industry-jargon filled product especially when they’re back-end-cloud products. Being able to collaborate with the clients directly without barriers was a top contributor to the success. For projects that need explanation without too specific of an example, metaphors found in real life always works great. It helps to expand the narrative beyond just the product.
Full Team
Visual Design: Bryan Park
UI Design: Ryan Greenhalgh
Technologist: Marcus Guttenplan