Prototyping for Automotive - The Mercedes Use Case
Discover how the design team at MBition harnesses the power of ProtoPie to prototype connected experiences.
MBition is a Mercedes-Benz subsidiary with a dedicated UX design team shaping the future of car UX. The team is led by an ambition (pun intended) to develop innovative and seamless user experiences for the Mercedes-Benz infotainment systems, one prototype at a time.
In our latest webinar, we met Szymon Kościelniak and Feri Irsanto Pujianto, two talented UI/UX designers from MBition who played key roles in prototyping for the Mercedes Me app. Of course, ProtoPie is another hero in this tale, as the go-to high-fidelity, rapid prototyping tool in MBition’s tech stack.
Check out the webinar recording below—or keep reading to learn about insights, best practices, and workflow examples from MBition's design process.
TL;DR - Prototyping for Automotive: The Mercedes Use Case
- Designing for the car UX of the future at MBition
- MBition's approach to prototyping connected experiences for the Mercedes me App
- Best practices for component libraries
- Structure of component libraries
- Benefits of component libraries in ProtoPie
- App prototyping workflow example: The Mercedes me App
- Why ProtoPie Connect is ideal for prototyping connected experiences
Designing for the car UX of the future at MBition
MBition, founded and based in Berlin, is a wholly-owned subsidiary of Mercedes-Benz. As part of the famous car manufacturer's software hub, it actively engages in research and development in the automotive field. Combined with its secondary base in Sofia, Bulgaria, the subsidiary has a total of 900+ workers of diverse nationalities across both sites.
You may be wondering what MBition is all about. One line sums it up: "Designing the Future of Mercedes-Benz Infotainment Systems."
In this context, infotainment (a mix of "information" and "entertainment") refers to the content provided to the users of a car through one or multiple displays.
To see some examples of this in practice, check out the video below.
A good eye would have caught a few of the infotainment elements in the car presented in the video, including the
- Instrument cluster;
- HUD (Head-up-display);
- HU (Head Unit);
- PD (Passenger Display).
But there is one more product that can be spotted in the video—the Mercedes me App, which we will learn more about in the next few sections.
MBition's approach to prototyping connected experiences for the Mercedes me App
Released in October 2020, Mercedes me is a companion app that allows Mercedes-Benz owners and users to interact with the car in various ways. For example, by controlling the vehicle via the app or reading the vehicle status.
"Mercedes me was the first product that I started to prototype with ProtoPie at MBition," says Szymon. "We tried some different tools, but we ended up with ProtoPie, which I'm quite happy to work with."
He explains that when they started prototyping, they wanted to get it right from the start because they knew their limitations, such as
- A relatively small team;
- Time pressure;
- The need for high-fidelity prototypes to convince stakeholders.
The MBition team did have solid foundations to build on, including a design system in place with a component library in Sketch.
However, with new features released regularly, the designers needed to constantly validate test cases. In other words, they needed a high-fidelity prototyping tool that could help them develop functional and interactive prototypes quickly and easily—leading them to ProtoPie.
But from experience with other tools, the team knew that app and car prototyping from scratch is not always the best idea.
Let's find out what they did to solve it.
Best practices for component libraries
The MBition team decided to design a prototyping approach using component libraries (also known as interaction libraries) in ProtoPie.
During the app prototyping process, they established a few best practices that helped make the team's design workflow more productive and transparent, reducing the time and effort needed to develop a functional prototype.
1. Name your variables
By adding a prefix to your variable (e.g. “int_” , “str_”, “bool_”), you can quickly identify variable types much faster than having to click and check the inspector every time.
2. Name your conditions
In a similar fashion, naming your conditionals improves transparency for other users on your team.
3. Name your triggers and responses
For a quicker logic overview, be sure to also name your triggers and responses.
4. Use multiple libraries
The MBition team had a lot of components, which meant they found it handy to split their libraries into smaller, logical chunks. This enables a collaborative approach and makes library upload faster, allowing different team members to work on different areas simultaneously.
5. Use a naming/background coloring scheme
Within their libraries, MBition used specific naming and color coding to emphasize the difference between libraries/components.
6. Group your triggers
Grouping your triggers into logical chunks is especially valid for cases where you have a lot of logic and would need a better overview. It also allows consistency across components for a more productive workflow.
7. Avoid hard-coded values, if possible
Using dynamic values instead of hard code is especially important if you want to keep flexibility.
"I've seen many users prefer hard code and whenever they come back to a prototype, they need to rebuild the prototype because the element was just moved a little bit," says Szymon.
8. Use non-case-sensitive conditionals
You can make overridable variables a bit more bulletproof by removing case sensitivity.
"We try to bring string values in conditionals to the same formats," says Szymon. "For example, always to the uppercase. So if someone is writing in lowercase or beginning in camel case, it doesn't matter at the end."
9. Document your component
The component guide feature in ProtoPie is useful as a tool to document your components for team members to refer to.
At MBition, they use styling to enhance the transparency of the documentation, which is very important if you work with users or multiple colleagues that contribute to the library.
Structure of component libraries
As mentioned earlier, the MBition team divided its component library into smaller chunks. Here's an illustration of the different categories that make up their component library, followed by how they can appear in relation to each other.
For example, a dynamic component could include elements from helper and asset libraries, such as text style, as seen in the bottom right corner.
At first glance, it may seem a little complicated. But, as long as the pro users take care of maintaining all component libraries, the end user doesn't need to think much other than using the components with minimal logic.
Let's have a look at the individual libraries.
1. Helper library
Helpers are strictly functional, designed to receive and throw back data. They do not include any design elements and lack any assets or other components. Typically, helpers are used as child elements within different components.
A classic example would be a timer helper that sends a signal whenever a timer is finished counting.
A more complex example would be a layer style helper that mimics the layer styling functionalities found in design tools like Sketch or Figma. It receives a color code as input and generates a corresponding hex code as output. Additionally, it considers the styling for both Light Mode and Dark Mode. The true advantage of the style helper lies in its ability to enable you to control all components at once, eliminating the need to individually change the color of each one.
The introduction of the parseJson function in the ProtoPie 7.6 update has brought forth a more efficient approach to managing and retrieving essential information, such as color codes and values.
2. Assets libraries
Assets libraries are a collection of various components, including:
- Icons: Icons use minimal logic, allowing for easy replacement via the override function in ProtoPie. They are responsible for tasks such as initializing the color, receiving color-setters from the parent component, and applying coloring with the help of helpers.
- Text style components: These follow a similar logic as icons but with additional features. They mimic the design system and can receive setters from the parent component to modify the text. These components also automatically rescale or adjust their layout based on the length of the text and send back their height to the parent.
- Static components: Require minimal logic and primarily focus on initializing color and styling. They use helpers for applying color and can have specific styling for Light Mode and Dark Mode. These components consist of vectors, PNGs, or video materials, allowing for easy application of visual design changes without disrupting the component logic.
3. Logic-based libraries (including dynamic and map components)
Dynamic components store logic for functionality and can nest components from other libraries or within the same library. They distribute signals between parent and child components and may have overridable variables such as states.
Here are some examples:
- The Control Slider component stores variables for states and positions. It can be overridden by parent components using setters, and values are sent back to parents. Successful interactions trigger signals to parents.
- Similarly, the Slider and Status Line components store variables for state, position, status, title, and subtitle. They can be overridden by parents. The Status Line component also auto-scales based on text height.
- By combining components, different components will communicate through the send/receive concept to enable interaction. For example, the toggle slider is responsible for setting the door state of opening and closing. Depending on the state, the signals are then distributed to individual components such as the status line, the car illustration component, and the slider itself.
On the other hand, map components are logic-based components specific to maps. They use the same concepts from the dynamic components library but on a bigger scale.
In the example shown above, all of the elements come from the component libraries. It uses a gyroscope sensor to detect device rotation, leveraging coordinates of user and vehicle positions for the "focus into" interaction.
Benefits of component libraries in ProtoPie
Feri tells us that, from the beginning stages, the design team knew they needed to "minimize the disadvantages of high-fidelity prototyping, such as the high effort of creating a prototype and low maintainability."
He says that their approach to prototyping with component libraries in ProtoPie gave them several benefits.
- It saves time. Having an approach allows the team to save a lot of time that they normally would’ve spent on creating prototypes from scratch.
- It is easy to maintain. Thanks to guidelines and common rules/routines, the MBition team is able to maintain bigger prototypes.
- It is user-oriented. Should other colleagues plan to work on the prototype, they can jump on board with less friction.
- It is scalable. More features can be added to the prototype, as the concept matures.
- It's collaborative. Different people can work on different libraries without generating merge conflicts.
- There's no code required. High-fidelity interactions do not require coding—just logical thinking.
App prototyping workflow example: The Mercedes me App
In this section, we'll have a look at the workflow behind creating mobile app prototypes at MBition.
Below is a prototype showcasing the home tab. In the current state, the user can operate the vehicle lock feature.
1. Using a Sketch concept
"Let's say we want to expand our prototype and add the remote engine feature," says Feri. "We start off by looking at the concept of the feature from our concept team. In this example, the concept is simplified."
The concept below includes a start press, sending the page to pending, followed by starting the engine with a user interface that includes a stop button.
2. Using a template
"We start off building in ProtoPie using the templates we have created, showcasing different patterns of the pages," says Feri. "So the template not only consists of design layouts but also a logic of basic interactions."
The next steps consist of:
- Finding the right template.
- Copying the scene to their profile.
- Renaming everything (e.g. variables, values, warnings).
- Checking if the variables work based on the same logic.
- Renaming the scene based on the feature they want to create, replacing placeholder titles.
- Replacing the icons, button labels, and other generic text.
- Adding a Tap trigger and Jump response.
- Duplicating the Tap trigger in the home tab.
- Creating a Jump response to the remote engine page.
As you can see, using previously saved templates and components, the process of creating a new scene is much more simple.
3. Using the Sketch export feature
Sometimes, it might not be necessary to use components if the element is not planned to be interactive in the prototype.
"In that case, we can just use the export function or directly export the element from Sketch using the [ProtoPie] plugin," says Feri.
In the illustration, the info line element should be shown whenever the engine is active, along with the cell items element.
These are the steps involved in the process:
- Use a positive response based on the state of the engine.
- Set up everything regarding constraints, ensuring it stays at the bottom.
- Rename the containers and elements for clear signals.
- Set everything to zero capacity.
- Determine how to scale the bottom action bar when it's active, saving the value (206 in this case).
- Based on the engine state, scale the bottom action bar to a height of 206 and apply the opposite response for the info line and cell items. In this case, both are set to 100.
- Rename the response to ensure clarity.
- After that, do the opposite for the off and engine state, change it to zero, and scale back the bottom action bar to 150.
The end result? In motion, behaving as expected.
Why ProtoPie Connect is ideal for prototyping connected experiences
So then, what are connected experiences, especially in the context of MBition?
The video at the beginning of this article showed several devices that can either be found in a car or used in connection to a car. Thanks to ProtoPie Connect, it's possible to prototype targeting all of those devices, and even have them communicate with each other.
Not only that, but it's also possible to use bridge apps to feed prototypes with car data or different interaction points.
"The nice thing is that you can test the same prototype on mobile devices, tablets, laptops, and also in the real car with a proper setup," says Szymon.
Szymon adds that "I can only recommend to explore this huge world of possibilities whenever you have ProtoPie Connect. Find time to use it, play around, build your own bridge apps."
Finally, let's go back to the video for another second. Remember the phone in the hand of Lewis Hamilton?
You guessed it—the prototype was made with ProtoPie.
Revolutionizing automotive prototyping: Unlocking innovation with ProtoPie
Automotive prototyping plays a crucial role in the development and advancement of the automotive industry. It enables companies to bring innovative ideas to life, refine designs, and enhance user experiences.
By harnessing ProtoPie's capabilities, companies can significantly reduce development time, improve collaboration between design and engineering teams, and ultimately deliver cutting-edge vehicles that resonate with customers.
Book a demo today to figure out how we can help you succeed.
