Product Quote Creation Application
Summary: The existing quote creation application was slow, confusing, and hard to use. I helped redesign it from the ground up, with the goal of reducing the deal cycle to 30 days or less. Using survey and interview feedback from sales representatives, we designed a guided quote process with fewer, better organized approval codes, which tested positively with about 15 users. After being paused for several months, new technical constraints prevented the design from being built as intended.
Company: Oracle
Industry: Enterprise sales tools/sales operations
Role: Co-designer
Team: 1 co-designer, 2 PMs, development lead
Timeline (design to development):
MVP (until project paused): ~3 months
MVP (when project resumed): ~2 months
Tools: Figma, FigJam, good old pencil and paper
Note: Some details, visuals, and application content have been intentionally generalized, reduced in quality, or obscured to protect confidential business information.
Overview
For companies selling products, quick and accurate quote creation is a must. This is especially true for complex quotes dealing with multiple products, discounts, and approval codes. When the quoting application is slow, confusing, and hard to use, consequences can range from missed deadlines to lost deals to a deal cycle that lasts way longer than necessary.
This was the situation for Oracle. Their existing quote creation application was incredibly complex. In fact, both new and existing users often couldn't complete the process without help from colleagues or help documentation. The application also ran slowly, failed to show approval progress, and used out-of-date UI.
Another UX designer and I were brought in to revamp the application from the ground up, with an end goal of reducing the deal cycle to 30 days or less. This required not only updating the visual interface, but the user flows as well.
Current State Discovery
Before designing anything, we had to understand how the existing application actually worked. We scheduled several meetings with key stakeholders, including PMs and developers, to get a detailed walkthrough of the application from start to finish. We used this demo to map the entire “as-is” flow in FigJam, which helped us understand existing functionality, pain points, and where the experience could be improved.
While demos are helpful, they only tell part of the story. To truly understand the problem space, we needed to hear directly from the people actually using the application.
User Research
We began our research by sending a survey to a broad group of sales representatives. Questions included how many quotes they created each quarter and what wasn't working well for them. 17 out of 20 sales representatives participated, and their responses helped us understand how they approached the application and what to explore more in follow-up interviews.
Survey notes in FigJam (intentionally illegible)
Over the following weeks, we met individually with about 15 sales representatives via 30- to 60-minute user feedback sessions to find out more about how they used the application, what they needed it to do, and where it was falling short. These sessions gave us a clearer, more grounded picture of what truly mattered to them.
Design Ideation and Exploration
After synthesizing our findings, my co-designer and I began brainstorming how we could address users' needs. Our ideation sketches were intentionally low-fidelity, as we wanted to align on direction first before jumping into high-fidelity designs.
We also worked with other stakeholders to tackle one of the application's biggest sources of confusion: the number of approval codes. We worked together to figure out which codes were no longer used, duplicates, and could be consolidated. We hypothesized that reducing the number of codes sales representatives had to review would make it much easier and more efficient for them to find the codes they needed.
My low-fidelity sketches for “create quote” guided process
Design and Iteration
We designed and iterated on version 1 collaboratively with the PM and development lead so that all perspectives were represented and what was designed could actually be built. Throughout this process, we kept returning to our user insights to make sure every decision was grounded in real needs.
Key functionality in version 1 included:
Organizing the quote creation process into a guided flow so sales representatives always knew where they were and what still needed to be done
Automatically adding approval codes to a quote based on products already added
Automating approvals when possible
Showing only relevant codes organized into clear and searchable groupings
Using clear language so content, including approval codes, was easy to understand
Including an approval tracking page with completed and pending steps
Later version of Add Products drawer in “create quote” guided process (recreation, not the actual shipped interface)
Later version of Price step in “create quote” guided process (recreation, not the actual shipped interface)
Accessibility was never an afterthought and was considered throughout the design process. For example, we:
Rewrote all error messages so that it was easy to know what happened and how to fix it.
Designed all clickable elements like buttons to be at least 24×24px (ideally 48×48px when possible) so that they could be easily distinguished and clicked.
Thoughtfully used white space and boundaries (like dividers and borders) to clearly convey content hierarchy and relationships.
User Testing and Refinement
We tested the initial design with about 15 users, which included both original research participants and new voices. Overall feedback was positive, especially regarding the reduced number of approval codes, guided process UI, and clearer verbiage.
Constructive feedback helped us identify areas to simplify and reconsider, including how approval codes were organized and step names and order. As we made these updates, we continued iterating on and reviewing collaboratively with business and users.
Outcome
Unfortunately, the project was paused for several months due to changing priorities. When it was picked back up, the development team switched to a framework containing a limited number of Oracle Redwood components. Although this didn’t prevent the team from releasing the MVP, it did require them to initially release it with alternative UI (like iframes) so all required functionality from the original application could be included.
A different designer is now working on this project, but the insights we gathered during discovery and user research continue to inform the application design and direction today.
Lessons Learned
User feedback is not optional: Having direct input from actual users meant our time and energy were focused where it mattered and that we were heading in the right direction throughout.
For example, the user feedback sessions showed us that our consolidated approval code categories and labels made sense to users, and that our initial Configure step design didn’t include a way for sales representatives to update the date range when needed.
Involving users also gave them a genuine sense of ownership and excitement over the end result.
Don’t be afraid to ask questions: This was a complex application, so asking stakeholders and users questions throughout the process was what allowed us to design confidently. Without a clear understanding of the application, we would have missed required functionality, made incorrect decisions, or misidentified problems.