Competitive Benchmarking
Every worthwhile design process starts by determining the current status quo for users. This is accomplished by assessing the competitive landscape to determine how well user's needs are being met. Given no direct competitors, I look for comparable products. For example, while designing a gestural language for the Cadillac CT6 touchpad, I benchmarked the Macbook Pro trackpad and other vehicle controllers.
Contextual Inquiry
Contextual Inquiry is a user-centered design ethnographic research method, part of the Contextual Design methodology that was developed by Karen Holtzblatt and Hugh Beyer. I had the fortune of training and working directly with Karen and Hugh on a GM project through their design consultancy, InContext. I also received training through Cooper (the UX design firm founded by Alan Cooper) where we observed and practiced such interviews. After training, I had the opportunity to utilize this method to great effect. Prior to conceptualizing a solution, it helped gain an understanding as to how users experienced a particular product.
Strategy
Once the competitive status quo and user's mental model are known, it is imperative to work out a feasible strategy with the business and engineering teams. I frequently engage Product Owners, engineering teams, Project and Product Managers as well as any stakeholder that places a role in bringing the product to life. As a champion for the customer's experience, I go to planning meetings prepared to assert what is necessary to execute the greatest achievable design.
Storyboards
I then like to create use-case scenarios in a format that stakeholders can comprehend without focusing on UI implementation details. Instead, the focus is on the product's integration into a user's life. This was especially useful when working on the launch of Onstar 4G LTE, as the internet connection provided in the vehicle had almost no UI despite its significant impact on user experience.
Wireframes
Next, I establish a navigation structure and organization that makes sense to users. This is achieved through open and closed card sort exercises with 30 or more representative users. I then can create rough wireframes to experiment with different solutions and visually communicate layout and structure to other teams to collect feedback. As part of my Cooper training, I also learned to make early wireframes as rough as possible. This means starting with pen and paper and grinding out several iterations before moving into digital mediums. After, I evaluate according to the 10 Norman Nielsen heuristics and optimize before testing.
Rapid Prototyping
I believe in getting users involved as early as possible. This means putting together quick prototypes, conducting testing and iterating based on findings. As a side benefit of early prototyping, the act itself often forces designers to be more thorough in their design. I've made a significant number of Axure, Keynote and paper prototypes and can build great prototypes extremely fast.
Visual Design
At this stage, I apply style and visual polish to the design. Depending on the project, there are often brand requirements that must be taken into consideration. Once known, I render beautiful mockups and use them to gather feedback from stakeholders. For these purposes, I'm proficient with Photoshop, Illustrator and Sketch.
High Fidelity Prototype
Once the look and feel is established, I create (or request) a high-fidelity prototype to assess design through usability testing and subjective satisfaction surveys. Also, this prototype acts as a companion to the design documentation. This is also where more nuanced characteristics of transitions and animations are decided.
Documentation
For more complex projects, I spend significant time communicating the design to the engineering team. Specifically, I create Style and Interaction Guides to communicate the final design. This works best as a companion to the high-fidelity prototype. In Agile work environments, this usually requires making documentation in preparation for each Sprint.
Engineering
Depending on the size of the team, I sometimes find myself sitting with software engineers to discuss different execution tactics and answer questions regarding the design intent. When the team is really small, I may even write code myself. This is where my engineering education comes in handy.