I joined the Amazon Business team to design and tailor the Amazon shopping experience for business consumers. The challenge was to craft a unified experience for customers ranging from small business owners to enterprise businesses worldwide, and recognizing that they have different needs to be met.
To educate the Amazon organization about the difference between Amazon Business and Amazon customers I designed these gaming cards. These cards are two-faced; the first side has the Amazon Business persona and the other side has the Amazon.com persona. What's also interesting is the powers on each card represents what's important to the individual persona. I showcased these with the Amazon design community at the Conflux 2015 (Amazon UX Conference).
I designed 7 major experiences, and was a part of 6 research sessions. I was responsible for designing Customer Service Central, Search within Orders, Invoice, Custom Order Fields, Line of Credit, Bulk Actions, Account Activity Email and more within Amazon Business. If you want to learn more about the use cases and details, shoot me an email at email@example.com. Here is a quick glance of the few projects I can share:
Amazon Business UX process is fused into 5 stages. The first step is to create a foundation of user needs and pain points and combine it with generating lots of ideas around these problems. This is followed by design where pixels are crafted into stories, and led into evaluation to achieve the highest quality. Once the design is iterated and reviewed enough times that it encompasses a holistic experience, the design is handed off to dev team. The UX is there for support actions such as demo, fit and finish etc. The key takeaway is UX is involved throughout the product cycle to ensure that the product is always solving for the customer. Continue reading for a more detailed version of the process.
Research & product vision
To understand customer needs, expectations, priorities, and constraints, I collaborated with the UX Research team to close these knowledge gaps. This helped to inform the project's roadmap, success criteria and approach.
Next, I partnered with PMs, TPMs and the development team to brainstorm and create low fidelity visuals of the possible user experience to include in the product journey map. I also identified which UX activities are merited given the details of the project and its UX risk (based on complexity and knowledge gaps).
To solve for the right problem, I drew out user stories that represented real people in real places doing real things, and not an abstract, feature oriented description of the functionality. I wrote user stories from user's perspective, focused on the value they will receive (typically by stringing multiple use cases together to enable the user to feel a sense of accomplishment at the end of story). The story included steps that can’t be influenced from a technology perspective, so I remained technology agnostic when writing the narrative.
To communicate and bring a vision to life, I used storyboarding. I created storyboards that comprised of multiple personas, scenarios, requirements and possible solutions. This was helpful to build the foundation for the detailed UI design and also facilitate communication among multidisciplinary stakeholder teams.
2) Mocks, Flows, IA, Prototype
For each project the fidelity of the mocks differed and were based on numerous variables including complexity of the user stories, the need to envision architecture, the timelines, the number of partner teams who needed to understand the design intention, etc.
I prototyped interactions for the usability study and for the projects that required outputs in a more dynamic/interactive fidelity and involved different motion/animation/coding effects. I also used prototyping to validate a proof of concept for a proposed design.
Once the designs were complete, I presented my work in front of my peers to ensure the highest quality was met. In the next review, I walked the Amazon Business and partner teams through an end-to-end experience by printing out mockups and sticking them to wall. Not so ironically, this process was called Wall Reviews. For one of the projects, I also presented the design to the leadership across Amazon at CXBR. CXRB is for projects that have a company wide impact.
4) Design Handoff
Once the projects were reviewed by the team and stakeholders. I handed off the designs to the development team with annotations, redlines and style guides (deliverables varied across projects).
5) Support & Demo
Before prod release I did design QA with the dev team to test use cases and tighten any final experience gaps.
I captured the lessons learned and best practices that I want to repeat (or not) on a subsequent project. Here are some of my takeaways:
- Don't be married to designs
- Evaluate when to use sketches vs. wireframes vs. hi-fidelity mocks
- Always have two designs, one required, one ideal
- Inform design decisions based off use cases
- Set the right expectations with stakeholders
- Design solutions to be usable, scalable, international, accessible and responsive