Issues other than Data
I like the way you framed your question, “decrease the cognitive load.” This is the best way to put it - far better than asking, what’s the best experience?” Simply put, users cannot enjoy any experience that is cognitively effortful.
The UI you’ve presented appears to show users three questions. I don’t have much context for understanding the system you’re working on, so forgive any guessing I must employ. That said, I see three big issues not addressed in other answers (organized from smallest to biggest issue).
Word Count and Writing
I assume the UI’s presented questions are merely dummy text, but maybe not. If so, they demonstrate common flaws.
Don’t use prose (writing in complete sentences) in the interface unless you absolutely have to. Once content exceeds 4-5 words, you’ve transitioned from what most users can unconsciously scan to what demands conscious reading. Conscious effort is where cognitive load mostly lives. The repeating question’s word count, 13 words total, is a bigger problem than the accompanying data discussed in other answers.
Avoid passive verbs on interface elements (is, was, have, are). Instead use action verbs (add, remove, buy, delete). Passive verbs are easy to write, but hard to read (because they bore readers).
And always look out for any words that repeat without need. JazZRo caught the repeating “compared to average” label and wisely moved it to the column label.
Ultimately, the text, “Are you satisfied with the amount of time it took to register your application?” could possibly be shortened (depending on particulars I don’t know) to…
- Did this take too long?
- Too long?
- Registration time? (good or bad)
Garbage in, Garbage out
Of course, a different user group might have written the questions, with a second user group consuming them. It’s tempting for UX folks to just accept this. And often, UX teams work output experiences exclusively, while input UI’s get designed by developers. Whatever the reason, ignoring the input UI conjures the garbage in, garbage out problem.
User group 1 writes poor questions as system inputs, which then presents to user group 2 as system output. If the system’s output content demands effort all by itself, polishing the UI will accomplish little.
Worst of all, poor quality or highly variable output content forces design teams to shift their design priorities - from, designing for usability, to designing for versatility. Imagine if the questions in your UI ranged from 3 to 40 words. Such variability of word count demands UI and layout changes to compensate - the tradeoff, reduced simplicity, and usability.
If these questions are indeed user inputs, then the true design problem lives in the input UI. Catch the problem where it starts. This would give the greatest positive impact.
Most UX folks don’t know what Choice Architecture is. Before I dig into that, imagine I’m a user asking the following questions.
- What do I click on here?
- Do I pick one of these questions to read more?
- Do I rate these questions? If so, where are the ratings?
- What does ‘preview’ mean anyway?
- Does just showing me the questions count as a preview?
- Am I allowed to not preview?
As clean and logical as this piece of experience appears, I fundamentally don’t know what it wants users to do. That the word “Preview” appears a bit vague isn’t the issue. Instead of presenting a choice, the experience is merely a presentation - of information.
It might sound like heresy, but no user actually wants information and what they expect in an interface are things to click on - options - in other words, they want a choice.
Choice architecture looks at things differently than information architecture. Instead of asking, how do I show this information? it focuses on the diamonds in the flow chart, the choices. An interactive experience is really a series of choices. What UX staff do is design the choices (not pages) that users encounter and react to.
When the choice at hand is not clear to users, severe confusion
results. Even if everything else (design, AI, UI, copywriting) is
As I mentioned before, I’m only seeing a slice of the experience. It looks like just a piece of a larger page. But in my experience, when a page is broken into self-contained modules, each module must present a clear local choice for users to decide against.
Hope this helps.