Problem statement

BMW's applications were divided by verticals, each representing a different piece or flow of the application, each owned by a different team and different designer. We had a lot of inconsistencies around the application and no easy way to share files across our international teams. We needed a way to have a centralized repository that would serve as a pattern library for all the applications.

BMW and Mini

At the beginning of my tenure, there was a gap of time Android apps were frozen from front end enhancements, I had a 2 month window to try to create a pattern library for BMW and Mini that could be used across teams and platforms.

My audience

At the time the Chicago office had 12 designers, there was another dozen at BMW headquarters Munich, Germany. Because of strict company restrictions, BMW was behind in the adoption of newer tools like 💎 Sketch and InVision, the company had just begun the transition of fully utilizing the tool in all product lanes. At the time I was all about Atomic Design, and teaching the methodology and how that could be applied to our application for the greater good our brand. Atomic design is a methodology used to create systems of interfaces, where everything is built from a base, allowing for greater flexibility and agility. To start the process I started by holding meetings with all the designers in the Chicago office to find out our current processes and to get them involved with the interface inventory.

At time we had a style guide built in sketch, but nothing was dynamic, there was missing elements and components from production that were not represented.

The new pattern library needed to meet multiple needs of different teams.

Pattern Library Users
Chicago Team
Munich Team
China Team
Agency Partners

Pattern Library Uses
Styleguide
Pattern Library
Documentation
Spec Sheet

Opportunity

In order to start the redesign I needed a good entry point to prove my case, and exhibit the functionality of new components. The prefect opportunity came when a teammate had to redesign BMW scheduling service. It was a flow that utilized lots of text-fields and form elements, and one of the many verticals built out in html. It was a unique chance to redesign a core component, with the appropriate amount of dev support available.

Material Design

I started to rebuild our forms, following specs from a framework I knew I could sell to my devs, fellow designers and upper management. I redesigned our form-fields into three variations supported by material design.

I started with forms, there was an obvious case to redesign them cross platform. With the release of Material 2.0 there were more options for us to build on components that were already put through extensive testing and are continually improved upon by Google.

I presented my redesign options, and was given permission to take the component further. In order to get it ready for production, the team wanted to see every state of the form field we needed to create. So I took our variant and made sure the new pattern would work for every instance and occurrence where we had form-fields.

Development

Coordinating with development became a huge hurdle pushing the standards forward. Not only did we have multiple code bases per platform but we had third part apps where we had no control over styling. Together with developers we decided to slowly roll out changes to components to meet the new standards. Once there was an opportunity to rebuild a component, I would help coordinate with iOS and Android teams about the release of new patterns. Pretty soon our style guide would match reality.

📐 Guides + 🛠 Layout + 😎 Style +🚦State + ✏️ Title + 🐼 Icon

Library use

I got a lot of support from other designers once I started to share the full capabilities of components and smart object. I was able to build a hierarchy that could accommodate three crucial state of our components -
📐 Guides - For devs to find specs
🛠 Layout - For UX an ability to have wireframes with the lates pattern
😎 Style - For UI to represent multiple steps from one component.

Cross-Platform Design

For the first time were all sharing an identical file across the Chicago office and we were able to bring all of our features up to standard with the new library. The new challenge became sharing with our team internationally, amongst a team that heavily regulated any cloud services.

In order to adhere to regulations and still share our new files with our entire team I opted to post everything on Confluence. It wasn't the most ideal but it allowed me a way to share and get feedback from our international teams. One of our new goals for the file would be to serve as on-boarding for new designers and agencies we might be working with. I was able to deliver a file that not only contained our style guide and pattern library, but also every root page in our app, to give anyone a full high view of our app.

In addition to replicating all this work for the Mini brand there was also a new need to serve our UX designers as well as our UI. I was able to combine libraries so that each element could be switched to UI or UX fidelity, giving the style guide even further use.

This was a really fun project to work on, filled with challenges and unique obstacles. And although my work proved to be of value to our team it was quickly becoming deprecated, and at the end of the journey we realized it needed to be a specialized role. I was able to give them the guidance and awareness of the need for a library and cross platform consistency. Something they began to think of for a complete redesign.

Concept work

There was a lot of the BMW app that we had no control of, the style, color, icons of certain things are set in stone, that I disagreed with. but at the end of the day the most fun was getting to work on concept work, and really pushing the application.

BMW