Design Lead
3 designers
General Motor
2018-19
My Role
Persona, scope and happy path
Spec meets client's requirements
based on usability tests
The team knew few about the Cadillac Escalade owners, so we started with this.
The research team offered the following personas, after some survey and user interviews. I joined most of the user interviews.
Supermom: 34, Beauty Salon Owner, 4 kids
Hipster: 40, Recording Studio owner, single
Nearly Retired: 60, Construction CEO, single
I referred to them throughout the entire product development process.
ContentGM offered a requirement file, listing all the features they want. I went through the list, worked with PM to offer the following feedback:
Design vs Feature: e.g. "Need to have a direction arrow for each search result" vs "Need to help users understand the direction of each search result".
De-scope: I believe that for having a feature, we need a better reason than "It won't hurt", "We always have this" or "All others are doing it".
By going through and polishing the requirements, we had not only freed up more room for designing but also understood better for customer's goals.
After we had agreed on the scope of features, I began to think of some happy paths. I did this first to focus on the key features, without spending too much attention on the frictions of user experience.
I reviewed and iterated on 3 different paths I came up with until the whole team has the same vision.
Then, I worked with the research team and customers to test the happy path with our target users.
The goal is to prove the mental modal in the happy path, does offer an intuitive and enjoyable user experience.
It was really important to build trust with the stakeholders at GM so we can push the limit on the design. I spent 1 week with them to define this review process, which allows different audiences to review the design at different stages.
What we focused on:
Laying out navigation on a system that used slant has some unique problem.
For example, if later in the timeline, we decide to update some angle of the slant, all the screens would need to be updated manually.
This actually happened in this project, but since we defined how to handle it already, it didn't make a mess.
Flows
Define the relationships between different screens, interactions
Screen Descriptions
Define the cases on one screen, spec for UX
Change Log
Screenshot of the changelog, and link to the real page
Key Screens
This is to present and get feedbacks
Visual spec
This is to include all details for implementation
UI Assets
This is to help developers finding all related assets
Curve Definition
This is to spec different speeds for the animation, so the dev team can reuse them for most of the animation.
Global Cases
Those are the motion method that can be reused in multiple locations.
Specific Cases
Those are the motion for some special cases.
After we built the product, I worked with the research team to run multiple usability tests, then iteration base on them.
Not all can be accepted easily, but here are some examples.
Task: Open [favorites] during Active Navigation:
Finding from user research:
the back button is hard to find, most users scroll to look for favorites. This finding is applied to all tasks that
Task: Open [favorites] during Active Navigation: