Is this the right feedback?
Not much to go on. You may need to test and probe more about what’s really bothering users. Is it really a strictly aesthetic problem? And does this user feedback come from users simply viewing the prototype or actually using it in a task? You can get very different reactions depending on how you’re testing. For example, users that say big buttons “look ugly” when passively viewed may suddenly appreciate them when using the app because they’re easy to click.
Feedback from actual use, of course, is what counts. Don’t throw a mockup on the wall and ask a group of users how they like it (or at least, don’t do just that). Show the mockup to one user at a time, and let them walk through a specific typical task (e.g., “You need to find out X in order to do Y. What do you click on this page to get that information?”).
”Too big”?
I’ll assume the feedback is from users using the prototype. Perhaps the user complaints about the buttons being “too big” and the UI being too much “like a smartphone app” really represent a problem with wasted real estate –a whole web page to do so little. Maybe what’s really bothering users is that they have to make this choice every time they use the app, which gets tedious. The solution is to flatten the navigation hierarchy and eliminate view-selection as a separate page.
Suggestion 1: Combine with sub-options
If each button takes the user to another set of options (e.g., a list of computers, files, or servers), then put links to those options on this page (e.g., have three scrollable columns listing computers, files, and servers).
Suggestion 2: Default view
If there aren’t more options, then consider combining the view-selection page with the view pages by showing one of the views by default. Across the top are normal-sized controls to change the view. These could be toggling buttons, radio buttons, or tabs (the latter if the views have substantially different layout from each other), so that they both show the state (what’s being viewed) and the options (what can be viewed). Each provides one-click access to an alternative view.
The default view could be what users usually want to see on average. It could also be whatever view the user was last using in the previous session (in case certain users prefer certain views, or users tend to continue work where they left off between sessions). Possibly there are ways to automatically distinguish which users tend to use what view (e.g., by job position). User research will determine what the default should be. If user research reveals that all three views are equally likely for any user, then picking an arbitrary default view may still be a good idea. It reduces the chance of clicking by 1/3. If a view loads quickly, that may make a more efficient UI.
Suggestion 3: Combine with the superordinate option
Another way to flatten the hierarchy is to combine view-selection with the next layer up (if any). For example, instead of an “Explore Data” link on the home page, you could have three links: explore computer, explore file, and explore server.
”Not Differentiated”?
The user complaint about the options not being differentiated enough may be a problem with the option labels, not the page itself.
Suggestion 4: Reduce repetition
Each option starts with “Read from” which gets in the way of the user seeing what really distinguishes the options: computer, file, and server. Consider parsing that phrase out as a title so that the text in each button is more differentiated:
Read from: [Computer] [File] [Server]
Or maybe you don’t need “read from” at all. Is there anything else users think they can do to a computer, file, and server?
Suggestion 5: User’s words
The terms “computer,” “file,” and “server” may also be confusing to the users. After all, aren’t files on a computer? Isn’t a server a type of computer? Doesn’t a server serve files? Research your users to find out what they call the three options. Select terms that make sense from their perspective. For example, maybe it’s “Devices,” “Documents,” and “Network Connections.”
Suggestion 6: Give examples
Maybe the options are too abstract for the users to grasp well. To make option labels more understandable, list concrete examples of the kinds of things you mean (e.g., “Devices: printer, keyboard, mouse, hard drive, video card and other parts of your desktop or laptop”). If you take Suggestion 1, that can take care of it.
Suggestion 7: Less bold icons
You icons may be meaningless to first-time users (do your users even know what a server looks like?). That may be okay –the icons may still be useful for users to quickly distinguish the options after they’ve associated them with the text labels. Just make sure the icons don’t overpower the text labels such that the users are slow in seeing them. Or make the text bigger and bolder.
