Personas

Before getting into the actual process, let’s take a look at the context of the project. Let us take a look at the primary personas. Heritage Auctions  serves three primary user groups:

• Product Managers – The champions of the product. These decision-makers ensure the team uses the product and use the features that help them.

• Functional Manager – The other decision-makers that hold sway over the team and keep them accountable.

• Frontline Contributors – These are the people who are actually doing the work and using the application every day for their work.

Phase 1: Design

1.Kickoff which started with a meeting with the stakeholders and project managers to get an overview of the project and the expectations. Before the actual legwork started, the team gathered for a brainstorming/ sketching session. Since we were migrating old legacy applications, one of our key focuses was automation. We tried to identify requests that can have automation in addition to manual features. As we followed an agile approach, all requests were broken down into related groups to implement solutions in small launches and the scope was decided. This was followed by identifying the goal and success metrics.

2. Research. This included identifying the data metrics to improve on. Followed by qualitative research.

User Interviews. All of the users were Heritage Auctions employees from all departments who used these applications for various things like auction management, accounting, shipping, etc. We interviewed users not just to validate the other sources of data, but also as a basis for determining how the new designs could deliver dynamic content to specific segments. By developing a rigorous user interview process and tying questions to outcomes, we gathered highly focused feedback.

Stakeholder Interviews. Since this project would literally change the digital face of Heritage Auctions, we also interviewed executive leadership and product, marketing, sales, and customer support teams. We then cross-referenced the results with feedback from user interviews.

This was followed by Field observations. We went around the office to observe how users use the old applications and take notes about the current workflows.

 3.Ideation started with listing down the features that the users wanted. Depending on the features use cases were created to describe each user scenario. These use cases would translate to code tests in the later phase.While developing the wireframe we took into account the business logic and the patterns that we wanted to follow and created wireframes as a final result.

4. Reviews: After the wireframes were ready, they were reviewed within the design team first for patterns and semantics. Then the user testing was done with the end-users to get feedback on any changes that were needed and finally reviewed with the stakeholders before sending it over for development. Review for any technical issues was done with the development team.

Phase 3: Adoption

This included announcements of the newly launched features by stakeholders followed by necessary training and solutions will be moved to production.

Constant Testing and Iteration:  After the launch, the data metrics were against previous metrics goals. Designers followed up with users after 3 weeks of launch to get their feedback and again after 3 months to get data and feedback from users.