How might we test a business idea for a mature brand?
Mercedes-Benz Research and Development had an idea they wanted to test in market. Speed was key. Yet it was also a polished brand and it had to look and feel like a Mercedes-Benz product. The team would have to streamline development without compromising the brand.
How did we define ‘MVP’?
My project leads and I had an honest conversation about what was possible in their timeline.
I worked with my lead developer, Robin Clowers, to sketch an alternative end-to-end flow. We worked on the whiteboard, assessed each story, and each functionality together.
I chose to communicate our flow with pencil sketches instead of wires. It helped focus the conversation on the goal of the core flow. It had enough fidelity to communicate the purpose of the app but not enough to hyper-focus on a UI element or copy. We needed to agree on the
big “medium” picture first.
That morning we had all felt anxious. After the call, our team and our clients left the day with confidence and clarity.
Iterative Design in the Build
At Substantial, designers and developers start working on a project at the same time. There isn’t a design phase where developers are waiting for product decisions to settle. The development team needed to know what to work on immediately.
How would I balance the decision making style of a large organization, a beloved brand, and speed?
I have always wanted to try iterative design in working software and this was the perfect moment for it.
How it worked at a glance:
- Core flow walkthrough with team
- Functioning software styled as wired components, establish the navigation model early, do a first blush on any 3rd party dependacies and known unknowns
- Story acceptance on functionality and copy
- Implement styled components
- Implement remaining content
Meanwhile, on the design track:
- Core flow walkthrough with team
- Page archetypes + UX revisions
- Design approval(s)
- Component library
- Asset creation
With each pass, the team would specify the acceptance criteria. At times these were baseline functionalities. Other times it would be copy or assets.
Meanwhile, as design lead, I took a first blush at both the flow and styling. The smart team needed approval from their German counterparts. I wanted to avoid a waterfall process but still had to provide an idea for how it would look and work.
I took the sketches and created click-through wireframes in InVision. In tangent, I identified the screens likely to be re-used—screen archetypes. These would exemplify layout and text styles for the remaining screens. It was important the design communicated what it might be like without tying the team down to exact specs. Positioning them as archetypes provided room for the team to make adjustments.
Both the flow and styling set enough direction to split the remaining design tasks.
What “iterative design in build” allowed:
- Isolated design churn —> Reduced development work
- Early access to a working app —> Opportunities for internal validation
- Working software —> Realistic expectations of time and scope
- Re-worked functionality without styling —> Quicker turnaround
- Copy seen in context —> Better, more accurate copy editing
All our development efforts focused on the core functionality. We wouldn’t be able to create meaningful, beautiful micro-interactions. At the time, frameworks such as Lottie didn’t exist. Instead, we added animations through custom designed GIFs (kudos to Paul Norris).
I facilitated a workshop with our Mercedes-Benz Research & Development team on KPIs. Customer satisfaction was a key pillar of their brand so I selected Google’s H.E.A.R.T framework by Kerry Rodden.
About the project
Lead designer at Substantial
UX, UI with Paul Norris
Built in React Native