Thus began the long process of iterating, finding time to meet with my busy stakeholders (CEO, clients, etc), and incorporating their feedback into the next design. As this cycle continued, the number of functionality requests increased, prolonging the timeline and logistical difficulty of this project.
During this long process, my CEO began introducing new design requests that all revolved around letting users do as much as possible at the same time. He still wanted bulk actions to be key, with the ability to receive, capture the payments for, and ship multiple orders at the same time, reasoning that this would cut time out of many users’ workflows.
He also introduced the concept of order tabs, so that users could quickly toggle between multiple orders at once.
“Order Quick Find” was a request based on categorizing orders for new users especially, so they could quickly find what they needed every time they entered the Recent Orders page.
His final request was for two viewing modes; a list mode for “super users” that had dozens of orders a day, requiring a sacrifice of detail for real estate, and a card mode for dealerships and OEMs that are smaller and have fewer orders a day, allowing for greater detail.
The above mockups are a result of all these requests. As time went on, and my meetings expanded to include the dev team, support team, and research with users, I found more and more problems with these designs.
Conversations with the dev team revealed that order tabs would be extremely difficult, nigh impossible to implement. Similarly, backend restrictions made it impossible to capture or ship multiple orders at once.
User interviews implied that they were also unnecessary as no users “toggle between multiple orders at once” the way this task had been described. The same seemed to be true for “Order Quick Find” as it was more confusing than helpful to those interviewed.
We also took a look at the average number of orders a user will have a day, and found that it was around 15, making the “card view” unnecessary. Based on this research, my design team and I also realized (admittedly a little late) that I had been operating under the assumption that our CEO knew exactly what the user workflow was, when this was not in fact true.