Xplan of today is interconnected with its data, the general idea being that a user should only enter client data once and that same data then flows to all the advice tools and modelling. To do this though means using standard areas and locations to draw the data from. The result is that today's solutions need to be double checked before falling back on custom fields and groups in order to maximise this linking and reduce double entry for users wherever possible.
The entity advice selector
An overview of some considerations worth noting from a recent question on using the entity selector.
I was recently asked what I thought about the entity selector and whether I’d use it in a particular development project. An innocuous enough question about a little spoken piece of xplan wizard functionality that might surprise you as to the range of considerations that can go into using it or not.
Entity advice selector: What it is and what it can do
When this configuration is enabled, the first page of your scenario wizard becomes a tickbox list of all the entities associated with this client (so you get a list of the entire client group). Ticking which entities you want to include for this scenario enables you to:
- Code the output specifically to those entities selected (can also tie in with IPS portfolios)
- Further condition elements of the wizard to those entity types selected
On the surface those benefits seem alright and for advisers who have used wizards or templates where you can include related entities, the ability to include a specific superfund for example, rather than having all of them come through, may seem like a good improvement.
But how does that fit into an overall picture of the user experience and expectations
The user experience
The experience a user has with what you build, be it a wizard or a config is one of the most important elements to delivering a result for the client. If what you build isn’t straight forward, intuitive and easy to use; allowing the user to comfortably achieve what they are trying to do, then the rest won’t matter. They will either stick to doing things as they were before or just skip through your wizard and do the bulk of the work outside of the system – both of which defeat what the business actually wanted to achieve (making things easier and more efficient).
So the end user experience matters.
This idea of functionality over the experience, best expressed as “it won’t be an issue once they understand how it works” is the whole philosophy that has led IRESS to have incredibly powerful software that so many clients struggle to use and get the promised benefits from.
You can see from the picture below, when using the entity selector you are condemning the first experience the user has with your wizard to be a barren, helpless, unintuitive experience on a virtually empty page that you can’t customise, can’t re-order and can’t marry any consistency to.
The alternative is a first page that welcomes the user, that informs them what this wizard can do, how they can setup the wizard, what options they want to include, introduces them to any help structures and sets the tone of consistency that can be replicated across many wizards. It’s like a night & day experience.
If the entity selector was customisable or an element that could go onto that first page, we’d be part the way set. But it’s not and its not the right first impression to make with users. This idea of functionality over the experience, best expressed as “it won’t be an issue once they understand how it works” is the whole philosophy that has led IRESS to have incredibly powerful software that so many clients struggle to use and get the promised benefits from. So small details count.
Consistency is key in many areas of user interface design and development. It provides comfort and familiarity to a user’s experience, promotes user confidence in the system and reduces learning times for users and resources for training. (The quote below from Karl Mochel, user experience designer, sums it up well). The user aspect aside, consistency has internal efficiencies in both coding and building by providing structure and re-usability of good elements that works.
Consistency lets a user expect to use things similarly. This eases learning curves and promotes efficiency. Inconsistency creates cognitive dissonance and an environment where the user has to constantly question whether the things that look the same will act the same. This makes them unsure of the system and themselves…
The entity advice selector creates a new element for users to understand without replacing any of the old paradigms. The established drop down of Client/Partner/Joint often used at the start of targeted wizards (advice for example) establishes this element to the user and its used consistently time and time again in everything from the xplan goals elements, cashflow, mindmap, right through likely to custom wizard groups such as a strategy group and “who the strategy is for” field within that.
So you might eliminate one to two fields from that first page of your wizard, but you’ve replaced it by adding a questionable new page and an inconsistent element to the wizard. Entity selector aside, whilst consistency is a good principal to apply its not a silver bullet and always needs to be balanced by what you are trying to achieve.
Targeting specific entities
I mentioned that one of the benefits (point 1) of the selector, was it allowed you to pick or target specific entities. So if a client has 2 superfunds and you only want to give advice to one of them, the end output won’t pull out both superfunds, only the specific one you ticked.
This is a benefit of the entity selector, but you can achieve the same result (with a scenario wizard) without using the entity selector and only at the cost of around 2-3 extra clicks of the mouse for the user.
So you can indeed merge out scenario data for related entities, without the need to use the entity selector. This therefore negates that benefit, whilst preserving your user experience and maintaining consistency with the rest of the xplan.
Length of wizard – number of pages
Good design takes balance, both in how much information you present on each page and the overall number of pages. Make no mistake, in wizards like fact find and advice, users will complain about the length of them (yes the number of pages) even when they have been built to be flexible and scalable. Just one of the things you have to balance and you don’t need a near empty page (…looking at you entity selector) adding to that.
The right tool for the right job
Despite the above, like anything in xplan development, be it coding or building, there are often few absolutes and a multitude of ways to achieving an outcome.
For example, a review wizard or basic investment roa that centres on IPS could be an ideal candidate. IPS allows you to view and model related entity portfolios from the client screen (no toggling needed) it also has a link to the entity selector by using ‘SX’ in the code to only pull through portfolios of those selected.
In such a case the entity selector in its current form may help deliver the best result.
I enjoyed this topic born from a simple enough question and think a lot of people might be surprised by how much discussion (and at times discourse) can be achieved from just one element in the system. It also served to highlight the array of considerations and competing design decisions a developer intrinsically has to balance when crafting a great experience for their clients and users.
Some further items or additional information
How to set up the entity selector
You can enable the entity selector on any scenario wizard by going to the ‘configurations’ for that specific wizard. See the screenshot below.
Why can I set it for non scenario wizards?
Based on its historical implementation and the coding for it, the entity selector should only be visible on scenario wizards. You may be wondering then why you can see and select the option for regular wizards (2.14, 2.15), this is most likely just a bug or lazy design.