Design Process

At Heritage, our small team has developed a detailed design process. Not all of these steps are required for each project, so I try to think of our design process as "tools in a toolbelt" that I can pull from as needed. While they are listed here in a certain order, many of these parts of the process require revisiting during a project. There are a few key steps that cannot be skipped or reordered, however, and each step must be handled intentionally and with care.

Design Process

Design Process

The most important step I take when I start on a project is to drop my ego entirely. At Heritage, the users I design new tools for are world experts on their respective categories. In order to design the most effective software, I need to learn about their processes and their unique needs. The best solutions result when I combine my objective observations, empathy for the users, and sharp design instincts.


This is the best opportunity for the designer to set the tone for the project. This meeting should include explaining the Design Process, determining the best communication style that will be most effective with stakeholders, setting expectations, determining goals, and nailing down the scope of a project.


Often, stakeholders are unaware of how much thorough research is involved in the design process. Additionally there is a larger picture to consider when designing an interdepartmental application. Transparency about what stakeholders and users can expect from the design process earns the designer an appropriate amount of professional respect, and sets a collaborative tone moving forward.

Hopes and Dreams

Similar to the start of the Double Diamond approach to design, opening up the discussion and asking stakeholders what their hopes and dreams are gives them a chance to spell out all of their goals, desires, and even vent about their frustrations. Listening and observing during this phase gives designers a good feel for the communication style that might be most effective moving forward. The stakeholder will often talk themselves out of off-the-wall requests that would be costly to build with minimal payoff, simply after seeing the design process laid out ahead of them. This helps narrow focus to the issues that need design work the most.

Automation / Manual Work

Most employees at Heritage have too much on their plates, and spend time working on repetitive, analog tasks that often take place on sticky notes or in spreadsheets. Identifying and automating these processes minimizes human error, records more meaningful data, and gives employees more time to focus on the more important tasks on their plate.


Depending on the scale of the project, a threaded design approach may help. If it is possible to implement smaller parts of a bigger solution, setting smaller milestones will get incremental improvements out for users faster, and will make for easier testing and adoption.


In my experience at Heritage Auctions, the demand for design work is very high, and our team is very small. By reassuring stakeholders that the solution will be a living organism, and this is "just phase one", the designer ensures nobody will walk away from the kickoff meeting feeling they need to rush and squeeze in all of their requests at once. It is important not to dismiss the ideas that won't be included in the scope of the project. Instead, it helps to suggest the project manager involved should follow up with the stakeholder after the meeting and help set up Jira tickets to go on the Design Queue. Since Jira sorts by business value and ROI, these projects will wind up in the correct place on the queue, and will receive attention when they are towards the top.
Once the stakeholders are satisfied with the agreement that there will be tickets for additional features down the road, the project scope can be defined.


In order to present a project's success to C-level managers, a designer should be prepared to discuss metrics. When stakeholders define their goals, it becomes clearer what should be measured.


Having stakeholders define their goals helps to determine what metrics would be the most useful, and helps prevent future scope creep. While not all goals need to be numeric, it is invaluable for designers to be able to translate the goals and successes of a project to dollars and cents so they can effectively communicate in the proper language to C-level executives, managers, and employees alike.

This stage of the Design Process should be spent mostly in the field with users, if possible. At Heritage, we are fortunate to have our user base in just three buildings, all within 15 minutes of each other, so tracking down the right users is a simple task. This is an opportunity to get developers involved and gather metrics, talk to users about their processes and needs, and really understand what their environment is like. While the stakeholder's objectives helped define the project scope, observing and speaking with the end users will help shape the solution.
Heritage does not have a User Research specialist, so as a UX Designer, I have had the opportunity to wear many hats and own the Design Process from beginning to end, including User Research in and out of the field.

Data Metrics

Not all metrics can be gathered by a developer, but for the metrics that can, this phase involves sitting down and running queries to understand and record data that can be used to compare after a project has been implemented.
Understanding the data better will also help designers understand some of the technical constraints that may come up.


Balancing both stakeholder and end user motives with the financial motives of executives is key. Understanding what motivates, upsets, delights, and burdens the end users requires the designer to spend time asking the right questions, gaining insight into the individuals that will actually be using the solution at the end of the project. Especially at Heritage, each team is entirely different. Getting a good handle on the personalities I'm designing for equips me to design better solutions.

User Request Notes

User Request Notes

Field Observation

Observing the workflow of end users as they work naturally will shape the end solution. Designers benefit immensely seeing firsthand every post it note stuck to computer screens, every spreadsheet that holds isolated, stale data, and every time users have to run across the room to grab a sheet of paper from a pile on an unused desk. An active designer will jump at the opportunity to question the employee's process with a sense of childlike wonder, and attempt to identify cumbersome processes that can be digitized or automated for users. While some processes must remain manual, there are ways a designer can take the "guesswork" off of their plate, and create a product that works seamlessly alongside their manual work.


This stage is for fleshing out use cases, recognizing patterns, diagramming the business rules and fleshing out wireframes.


Between the kickoff meeting, user interviews, and field observation, there should be a fairly robust list of user requests written down by this phase. The designer should at this point confirm that the requests are within project scope.

Use Cases

Translating the requests to Use Cases creates a common language for Project Managers, Developers, Stakeholders, Users, and Designers to use when testing and discussing the project going forward. These Use Cases should easily translate to Code Tests so developers can set themselves up for simpler testing in the future. This is an organic document that will grow as needed, even after the solution has been adopted.

Business Logic

Work with stakeholders to define the rules that will be implemented with the solution. Designers should be prepared to ask questions based on some of their observations from doing field research. Any rules that are decided on should be translated to Use Cases.


With a robust Design Library at hand, designers can pull tools off the shelf to determine the product's workflow. Using a design library saves on developer hours and helps to ensure a consistent experience application-wise, and across both Desktop and Mobile platforms.

Checkbox Collection Pattern

Design Library - Checkbox Collection Pattern


Documenting use cases and visually representing user flow can help untangle complex logic and business rules. Diagramming helps discover holes in logic, or find patterns that were hard to recognize prior. This can also minimize future bugs, as developers have an additional resource to refer to while programming the solution.


Creating simple wireframes equips developers with what the front end needs to look like, and gives stakeholders a good idea of what the solution will be. Designers can run testing to see how users interact with the product, and iterate accordingly.

World Coins Cataloger Page Wireframe

World Coins Cataloger Page Wireframe


Since much of the Ideation process happens isolated from other team members, the next step is getting everyone back on the same page, and ensuring the designs are airtight.

Design Team

Other designers may recognize patterns or problems that had been overlooked. Having fresh eyes on a project can also help point out missing information or logic holes that were less obvious.

User Testing

Observing how users react to a prototype can shed light on their process, and help determine if the solution is as solid as it can be. While the stakeholder probably has the ultimate signoff, including the users in the testing process can ease adoption down the road, and build a sense of camaraderie between the design team and the users.


The outcome of this meeting should either be an agreement that the solution is ready for development, or a clearer understanding of what the stakeholder really needs. As long as the channels of communication remain open and the designer knows what to do next, this stakeholder review is a success.


By including the developers throughout the design process, designers equip them with a thorough understanding of what needs to be built. Going over the use cases can also be beneficial, as they will be a guide when the developers write code tests.

Alpha Testing

Alpha testing is done with developers, designers and project managers.

Code Tests

Developers should sit down with the designer and show them that all of the code tests, based on the use cases, are passing without problems.

Integration Tests

Designers and project managers should use the QA version of the application to put the use cases to the test. If everything passes, the designer can move on to beta test with users. If the use cases do not pass, the project goes back to development for fixing.

Beta Testing

This is testing done in QA with the users and stakeholders.


The designer should have the users test the solution in QA. The use cases give the meeting a "script" to follow, so running through these scenarios in the application will assist users in testing the solution.


This step involves running through the use cases with the stakeholder and sharing how the users reacted to the testing. If both user and stakeholder tests go smoothly, the project is ready for launch.


If users navigate the tests with ease and seem to understand how to use the solution, then it has passed the usability test, and with stakeholder approval, can move on to production.


Users should seem comfortable and delighted with the solution if the the solution is to launch to production.

Roll Out

Necessary training should be held, and the stakeholder should make sure that all parties affected by the new product are aware of the launch.


Communicating the solution to all users affected by the launch is important. The more transparent the designer and stakeholder can be with users about the new product launch, the better.


Hold a training with the users, the trainer, a project manager, a designer, and if they can make it, the stakeholder.


The solution is put in production for use.

Follow Up

Designers should follow up and be aware of the impact the solution has had. They should also follow up about adoption and any issues users are having.

Data Metrics

Measurable results should be tracked after launch so a designer can communicate the impact of the project. Measure numeric impact of a project, as well as the satisfaction and delight of the users affected.

Field Observation

There will often be new or niche use cases that come out of this, as users can't always be expected to communicate every niche scenario they'll encounter until they actually experience it. If there are new use cases, document and plan for them in the next iteration.

3 Week Review

The designer should check in with the users and stakeholder after three weeks to see if things are still going smoothly. Some personalities are less likely to report problems as they feel they're "complaining" or "bothering someone unnecessarily", so it's good to open up the forum and give them an opportunity to voice their concerns.

3 Month Review

Several months of usage will mean the users and stakeholder should be very familiar with the new tools they have been given. Users likely have lots of valuable feedback, and they may have come up with new further improvements to discuss.

← Heritage Auctions Work

Go Top