I've had lots of meetings recently where I've been trying to stipulate why certain patterns and paradigms aren't appropriate. There have been numerous reasons for this that I kind of intrinsically knew. Things like mental capacity of the user, expectations of the user and being careful not to overload them with too much at once.
I've been struggling to explain why and how these things exist, and why it matters. And further, how it is really a thing, and not just me trying to go overboard on the designs.
After browsing this, I thought I might breakdown some of the key challenges I've come across and why they are important considerations in the design of our software. For me, this relates to enterprise software which thousands of people use every day to ensure customer satisfaction and an income of $8 billion.
If we give more options to our users, it takes them much longer to arrive at a decision.
This seems obvious, but is an easy trap to fall into, after-all, don't we always want to give our users choice?
This has been something I've tried to combat in a number of ways.
First of all, reducing the list of choices we give to our users.
Secondly, if the choice can't be reduced, revealing the options in a logical and progressive way.
Thirdly, ensuring our naming conventions make sense, and removing unnecessary abbreviations.
This is one I'm constantly referring to with the teams I work with. And I'll be honest, sometimes when I say "cognitive load", I feel a bit over the top. After-all, we aren't asking our users to work on complex algorithms or life-or-death systems.
But I try to think of it another way. Cognitive load is really the mental effort that is required to complete a task. When we are talking about a fairly complex enterprise sales journey, which needs to be efficient to allow our staff to get the job done, it's very important. If our staff are spending more time inputting data, and less time speaking with customers, we haven't done our job properly.
There are a few ways I've battled with this issue.
A big one is reducing the amount of information presented at any one time.
Secondly, presenting related information together instead of expecting our user to go and find it (such as a pricing schedule alongside the pricing calculation).
The third one is important, especially in a product that we are building in an agile way, with new features being released every few weeks. That's presenting those features when appropriate, alongside further information, so as not to bombard our users with new flows out of the blue.
Reviewing and improving iconography and colours, so that common tasks and options can be processed by the user faster.
This paradigm refers to showing content only when it is necessary, and slowly building to more complex interfaces. This helps to keep the interface simple for new or returning users and progressively brings power to advanced users.
If I think about some of the key ways this might work, opportunity management comes to mind. In sales, an opportunity refers to an account or contact who has entered into an initial agreement with you for a sale. It's the first solid indication of a working relationship with a customer, and therefore requires lots of data be entered. Things like accounts, contacts, expected revenue, cycle times, sale categorisation, and team creation amongst many others. In fact, there are over 100 fields a user might need to fill in. It therefore makes sense to show these things at the right time.
One way to resolve this is to have the creation form contain only a few of the most relevant fields to get the process started. Once created, the user can then opt to fill in more as they have the information or time to do so.
This ensures more data is entered more often, and our sales pipeline remains up to date.
With large customer management systems, there are endless forms and fields to be acted on. This presents as complex and confusing to many users. How then might we make it easier to understand and act on information?
One way is to ensure the information architecture and visual presentation of data is better. By using elements like headings and subheadings, images, icons and alert boxes we can help present information better. Some other ways we improve this is by adding more whitespace/contrast between items, or the opposite, by grouping and repeating items that relate.
I've also paid particular attention to reading patterns, to layout information in the F/E or Z reading styles.
This one was an interesting find, but something I've been doing unconsciously. When there is less effort involved, users are more likely to act.
This relates back to a few of our other items. Reducing complexity in the system and cognitive load, improving disclosure and options we present, has led to improvements of 27% of our sales pipeline, indicating success in this factor.
You've probably heard of this one. This is the principle that tells us people are limited to holding and acting on seven pieces of information at any one time.
To ensure the success of this commonly forgotten (irony?) law, we have implemented appropriate chunking of data entry and information presentation.
This might present itself as columns in a table, hierarchy of information (subheadings within forms), data selection and menu items.
This principle also compliments the generally accepted fact that the simplest option is often the best when compared to a more complex answer.
Josh is a product design leader based in Melbourne, Australia. He has been working in the design space for 7 years across various industries.