I've seen many arguments where one person will say "That's confusing," without giving a lot of reasoning for why it might be confusing. Often times people who call something confusing understand how the feature works, but believe it would be confusing for others. Is there a way to prove that something is not confusing? Conversely, is there a way to prove that something IS confusing?
- You can show conventions. Show that the icons / process / terminology are the same as other well-known and well-used features in other apps.
- You can show statistics. # of people using it, or, if you really want to entertain alternatives, A/B testing results. It sounds like your service isn't live, so if this is important, hammer out a prototype and get some test users. If it's not that important, propose to do A/B testing when its released.
- Figure out the end goal of the process, and ask a number of non-technical people (at least 20) to describe how they'd setup a process that would accomplish it. Do a significant number of them match your process? Do a significant number of them match each other?
- Examine all the knowledge you assume a user has in order to go through the process, from the very basic (the button is clickable, "domain" means the URL / web address of a site.) to the more complex (you can undo any changes you make by viewing a list of revisions and rolling it back, clicking 'save' saves content but doesn't publish it, a 'dashboard' is an overview of account activity & a jumping-off point for site actions). Ask test user questions to determine how common the knowledge you assume actually is.
I try to keep it in mind as we develop, it's especially important for us because our target market is not at all web savvy (and them not having to be so to use our service is one of our big selling points).
Right now we're very focused on getting to a point where we can launch. Once we're at a point where we can start to optimize, I definitely intend to do this, using feature usage statistics as a priority guide.
Think as if you're a semi-proficient computer user. They often don't have the vocab to articulate what they mean(if they know what they mean).
Look at the UI of an Iphone or Xbox360, or process for signing up for gmail for good examples of "not confusing." Both are dummy friendly.
Don't lose perspective after having been immersed in the technical world. I've seen some very smart people completely lose grasp of how a non-technical person thinks. Words like driver and BIOS freak them out - forget Python and API.
If only one user thinks it's confusing, then it may or may not be. If a lot of users think it's confusing, then it's something that you need to look into.
- You can show statistics. # of people using it, or, if you really want to entertain alternatives, A/B testing results. It sounds like your service isn't live, so if this is important, hammer out a prototype and get some test users. If it's not that important, propose to do A/B testing when its released.
- Figure out the end goal of the process, and ask a number of non-technical people (at least 20) to describe how they'd setup a process that would accomplish it. Do a significant number of them match your process? Do a significant number of them match each other?
- Examine all the knowledge you assume a user has in order to go through the process, from the very basic (the button is clickable, "domain" means the URL / web address of a site.) to the more complex (you can undo any changes you make by viewing a list of revisions and rolling it back, clicking 'save' saves content but doesn't publish it, a 'dashboard' is an overview of account activity & a jumping-off point for site actions). Ask test user questions to determine how common the knowledge you assume actually is.