Let me explain the problem briefly: I'm working on user flows for a customer support system. The system is structured to have several (horizontal) modules, namely messaging, contracts policies, invoicing, etc. (Vertically) these modules can be conditioned based on the contract type. For example, for insurance contracts there'll be slight difference in invoicing module with the additions of "claims"; or messages module may show only messages related to specific contract instead of all messages.

Now, I want to compare two approaches for user flows: a) the "contextual" one where users first select the contract/contract type and then interact with modules and b) the "all-in-one-bucket" where users start their flow, and along the way choose "specialization", i.e. select contract/contract type, and based on that UI forms get updated (for example, choosing insurance contract will show a new section with "claims").

I am wondering whether folks know about good examples of these two approaches in existing products and what terminology one would use to describe them?

(for the terminology, I'm looking at borrowing the Strategy pattern from software design.)

  • In "borrowing" that software design terminology you are really hijacking it and using it improperly. Define your own terminology and make sure there is no ambiguity. – straya Mar 11 '20 at 1:47

It sounds like you are talking about Dashboard (your 'contextual') vs Wizard (your "all-in-one-bucket"). Dashboard being a set of top-level options with which you decide the context. Wizard is typically a set of screens/forms that prompt for the necessary information/choices to determine the outcome.

The Dashboard flow is simple, allows Users to get a feel for the system and their options up-front (without having to explore to determine possible outcomes).

The Wizard approach is good for prompting for a series of inputs, it can be more time consuming for the User and developer. It may yield a system that requires the user to explore Wizard flows just to determine possible outcomes (User Guide or something similar can mitigate that problem).

It is hard to determine what is best for your situation, for instance it is unclear as to what your Wizard flow would really entail, e.g. "where users start their flow" what is involved in starting a flow?

  • Thanks, I think this abstraction actually is very accurate for my case. The flow starts when user decides what to initiate, for example whether to write a message to customer support or whether to file an insurance claim. Now, in these "wizards" one required step would be choosing one of their contracts as a context -- i.e. health insurance, liability insurance, etc. After this step, the wizard adjusts, and displays possible actions a client can do. While in some cases (filing a claim) this approach might not be a big deal, in others (message search) this might add more friction to the UX. – peetonn Mar 12 '20 at 1:10

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.