2

Let me first explain what does the attached mock do. It's an order manager application where the customer support can go through the orders for a customer. That's what the Customer Order screen does. The app also has different screens, and one of them is the screen to add/update the sales tax for a state. That's what you see on the Sales Tax screen. As you notice, the app has two child screens that can be seen at the same time.

While the user is going through the different orders, he finds out that the sales tax for the state of CA has changed. Nobody noticed the sales tax change in the complex tax system but a Customer Support rep found out about it. He brings up the Sales Tax screen and updates it from 9.2% to 9.5%.

Now the sales tax for the order has changed, so the total for the order has changed. The Customer Order screen should reflect the 9.5% sales tax and the new total.

Here are three options to handle this scenario:

  1. Should the customer support close the Customer Order screen and brings up again (or press the refresh button to refresh it)? The question is, does the app has to expect the user to use the refresh button or take some action to reflect the changes?

  2. Should the Customer Order screen update to the latest sales tax and update the total real time in other words reactive to the changes to the other Sales Tax screen? A nice message can be displayed on the Customer Order screen that the total has changed, so he has to save the order.

  3. Both the Sales Tax and the Customer Order screens should not be allowed at the same time (single screen interface). When the user brings up the sales tax screen, all other screens are closed. When the Customer Order screen is again brought up for the same customer, it will reflect the latest changes.

What I have seen in many desktop apps is the use the first option. I think this approach expects the user to less trust the app. About the third option, there have been discussion about the focus issue of multi screen applications, so use only single screens. In my opinion, using the single screens only increase the navigation and kill the productivity of the user. The web always embraced single page app (eg. google mail).

What does the UX gurus think about the user experience for the three options in this example? Or is there a fourth option?

enter image description here

  • Does this application support multiple users at the same time? i.e. is there a database the application is using to save orders? – FodderZone Aug 24 '14 at 13:38
  • Yes. This app being used by multiple users. As an example, you are a Customer Support user who is using the app. The user(s) next to yours are using the same app and probably looking at the customer orders from the same state CA but not the same customer order. Two users can't work on the same order by considering the productivity will be lost. This will be prevented by locking the order as soon as one user starts working on it, and not available for anyone else to pick up. Only when the order is approved, it will be available for anyone else to work on like a Customer Support in the shipping. – wonderful world Aug 24 '14 at 18:59
  • While a reasonable question for UX stackexchange as far as I can tell this example is a corner case. That is it has a small chance of affecting a small number of people in a minor way and very rarely. So if the tax and totals "just changes to the right number" then the design does not really matter. It is often important to prioritise UX work for higher impact issues. – Jason A. Aug 25 '14 at 6:13
  • This can be a corner case in this particular example. I described the problem as an example. You can consider that an app has to support this type of UX in many places of the app. – wonderful world Aug 25 '14 at 10:55
  • Curiosity question, why not to keep an open connection that deals with the tax system? so that the tax changes on the fly, since the tax change is only used for the view (the submission gets the tax anyways); I would just update it on the fly, and if there has been a change show a notification alert that "The tax has been changed. Please review your order" and the user doesn't need to do anything special other than do what he wanted to do, or cancel the order. – Gasim Aug 25 '14 at 21:00
2

Short answer: make it modal; the Sales Tax module is doing something systematically different than the Customer Order module. They should be displayed separately.

So my company uses account management software that (as you would expect) has dozens of screens that do and show different account things. On several of those screens we're able to see demographics for the customer; that data is relevant to the customer service agent no matter what screen she's on. But to change the demographics the agent needs to enter a different/modal screen because those changes should not be confused with other account functions, such as adding a payment plan.

Also, I like the UI telling me what it's up to, like "message sent", "page saved", "demographics updated". Maybe add a time indicator, like "Tax updated 2 mins ago" so it draws attention (especially for others) that something has changed, and serves as a confirmation that the change went through (i.e. helps users "trust" the application did what they wanted).

  • What you described is the way many desktop application work these days. I've described this in the option 3. In the Microsoft Windows world, in the beginning phase of the Windows OS, Microsoft has found out that Multi-document interfaces are confusing to the user. This is one of the reasons the technology like WPF (big brother to Windows Form) does not support it out of the box. With multiple monitors and powerful computers, why can't an application take all those resources and support multi-documents. The users who will use the app for years will like the productivity that comes out of it. – wonderful world Aug 26 '14 at 8:53
2

While page-refresh (or request), database locking and async can be technical solutions, I think that all three options are a little bit near-sighted.

Always manage expectations and tell the customer in the checkout process how sales tax is calculated, that it is subject to change and that there is an actual (support rep) person on the other side working on it. Then let the user know when and why the order amount changed by a few cents or dollars. This is a good opportunity to instill trust and authenticity in the purchase flow.

Mock up a few protos and run it by the project stakeholders and see if it sticks. You might just find a succinct answer without requiring engineering tasks. That will make you a hero.

Remember: UX design is not limited to a few screens. Consider the entire user journey. And you must also consider the entire user base; the support rep is a user as well.

Good luck, Ken

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.