One important UX job title is User Experience Designer. Sounds like UI Designer but it isn’t.
So, what is the difference between designing a user interface and a user experience? Answer is, “Almost Everything.”
Designing a user interface is actually pretty straight-forward. It’s all about where you put the buttons and controls to match the work flow or user story, plus maybe the colors, labels, error messages, and like that. It takes knowledge, experience, training, and more. It can be quite convoluted, for sure, but still reasonably simple.
Designing a user “experience” is a completely different idea; an experience has less to do with the UI design itself than about how the user feels while using it. Experience is something that happens between the ears of your user, after all, so how are you going to design that?
Like UI design, you’ve got to start with a plan. However, trying to design a user experience requires defining and understanding exactly what kind of experience you want your users to have while interacting with your system, and knowing how to evoke the experience you want the user to have. That is the difficult part. In my experience a good user experience comes from giving users freedom while encouraging the correct path or direction subtly and sensitively. Jack-booted thugs never create good a good user experience!
For example, designing a meal might be deciding on a theme, then assembling recipes, inviting friends, buying the food, and preparing and staging the meal.
But, what will your guests experience while attending your dinner? This is where you start in designing a user experience… how do you want your guests to feel? Welcome? Entertained? Safe? Comfortable? Appreciated?
Too often our users experience frustration and feelings of inadequacy when interacting with software that is poorly designed. Fancy buttons and garish colors distract, heavy graphic design obfuscates the system’s purpose, error messages offend and berate rather than help the user. Inconsistent labels confuse and mislead.
Focusing on the experience first can help us design what the user sees and interacts with to create the experience we want them to have.
Experience: delight, ease of use, satisfaction, accomplishment, understanding. Plus some of the feelings from the “dinner party” above; welcome, entertained, safe, comfortable, and appreciated.
Just how will you create the experience of delight in your users? Not an easy thing to facilitate, believe me. However, careful design can indeed create a delightful experience in your users.
Think about the user interface designs that make you feel smart and competent; just what was it that made that happen? They are logical, light and simple. You know instantly what you need to do to reach your goal(s). Along the way the colors and shapes are not intrusive — you really don’t notice colors or shapes, they simply support your understanding of the system and lead you from step to step to your goal. Perhaps a simple animation makes the state of a switch perfectly clear, for instance. You sweep through and quickly accomplish everything you need to, and the result is delight.
The delightful system has no ego. It doesn’t draw attention to itself. It always makes its intentions known through subtle clues. It doesn’t overload the user’s cognitive capacity with useless bric-a-brac. The scent of its different offerings is clear and unmistakeable. It is accessible, and its controls have “roles” so that where the user’s device can support it, the user sees a keyboard that facilitates the task at hand like entering an email address or a telephone number.
Perhaps it’s not possible to make every design “delightful” to the degree you’d like — the very nature of some systems just won’t allow that to happen. But, a clear understanding of what your users should “experience” along with keeping focus on that will help you shape and form your experience design to facilitate your users loving the system.
Did you know that words have a scent?
It’s true, and it’s an IxD principle that is very critical in designing effective user interface designs.
So lean over and sniff very carefully — can you smell those roses?
No, not that kind of scent. Scent is a word we UI Designers apply to navigation and other UI components that help a user “sniff – out” where she wants to go in a site. It’s extremely important to choose your navigation words carefully so that the scent is powerful and useful to your users!
Time for a bad example and a good example:
Bad Example: That little “hamburger” icon in many, many mobile apps. Why is it so bad? It has NO scent at all! Many users will not see it, will not touch it, and will leave the site rather than expand it to see what the hidden menu says.
I admit to using the hamburger icon in some mobile designs, and the majority of us have done so. I also commit to never using it again! If you review a design that has that little hamburger icon, tell your UX person and developers that you just won’t accept that kind of laziness, and demand they get a good solution for your mobile app design with lots of scent for your users. It will pay off in a huge way!Read More
I’m a UxD. User Experience Designer — “U” for User, “x” for Experience, “D” for Designer. Face it, it’s a cool title! Almost anything with an “x” in it is pretty cool, and to have the “x” be lower-case makes it seem cooler.
There are many titles out there in the user interface design field, some are pretty distinct and easy to understand while others seem to overlap. Here’s a partial list in alphabetical order:
There must be others.
Do you see the issue here? This is a proliferation of titles in what is essentially one profession. They are not so much titles representing specialties as they are (almost) duplications. An MD, for instance, might have a specialty of Genetics, but that wouldn’t change her “MD” title.
There are differences, of course, and I believe that some of this proliferation is from both practitioners and employers attempting to be or get an expert with a certain emphasis, like Human Factors as opposed to Interface Design which might be viewed as less desireable for some applications.
There are also be some actual differences between Design, Research, and Engineering. That leaves three major groups plus an extra for these 18 titles, where the differences are interesting within each group.
We all understand the designer group; we take stuff and and make it look nice and work well by applying design principles. Having been raised and trained as an artist it’s natural for me to be a designer, also very satisfying even if the look and feel is done by someone else. There are important differences between these six with the focus implied by “Experience” or “Centered” words. Designing a user experience is very different from designing a user interface. While I’m comfortable with any/all of these titles, and would not change my approach based on any particular title. I always make my designs “user-centered” and emphasize designing a great “user experience” while the UI design will take care of itself.
Engineer implies creating the works of things as compared to assembling the look and feel like designers attempt to do. UI-related engineers do the technical of user interfaces, applying human factors and HCI, amongst other things, and in some contexts might imply a developer role — requiring the engineer to code the actual front-end.
We all consider ourselves Software Engineers and that is the official title often applied in the corporate environment so that Human Resources Departments know how to set pay scales.
Accessibility engineers hold a special place in this list, and must have specialized knowledge and experience — it’s not just a title.
Section 508 is an amendment to the 1973 Rehabilitation act and requires certain levels of accessibility for all web sites funded in any way by government. Newer additions to accessibility expand requirements for a broader spectrum of human factors — it’s not even appropriate to label most if not all of these “Human Factors” as disabilities. WAI-ARIA comes a lot closer to broad accessibility than did Section 508. Many other organizations, appropriately, choose to apply these standards to sites and applications deployed for public access. Semantic markup, alt tags, object role definition, and other strategies help those with disabilities of many kinds use the site without blocking assistive technologies, for instance. Ever wonder how some mobile apps know how to serve up a special keyboard that makes it easier to enter a URL or an email address? In most cases it’s ARIA roles.
Other nations have similar standards and many have named them Section 508 to simplify things.
User testing is a huge area of endeavor and has specialties and sub-specialties. In general, there are two areas of user testing; qualitative and quantitative. These two divisions are served by several approaches such a contextual, formal, focus groups, surveys, and questionnaires. Most of these approaches apply to qualitative type testing, while quantitative usually applies to more formalized testing focused on speed and accomplishment goals.
I’ve rarely worked as any of the other titles without being asked to do some type of Information Architecture, though I have never worked as nothing but an Information Architect. There are many who perform the important activities of this title without doing any User Interface types of things at all, and great information architecture is essential to great apps.
It’s not intractable to deal with all these titles. Perhaps as the professions become more standardized and grow to have actual requirements and specific definitions some of these will go away.
There are certifications popping up all over as schools realize there is money in educating people to work in the field. There is no overall certifying body like you might find in the medical field or legal field, and this is probably a good thing.
I’m kind of partial to IxD for the Interaction Designer title, but I doubt that will be the final choice should it shake out to a formal, certificate-required profession. Only one of my contracts since 2003 has emphasized the IxD title. Still, one can hope!
Pay attention to the essential differences between UI and Experience, plus “extra” defined above will get you the degree of separation you want. Choose your own title from among the group titles, and interview carefully to try and zero in on that individual that you think will share your vision and effectively apply her knowledge and expertise to your special project.
I was once asked to analyze an app with the purpose of telling the owners why everyone in the company hated it so much — not an unusual request by the way.
Reason number one was the app was as ugly as any app I have ever seen, and that fact had to figure into the intense dislike expressed by its users. It was developed on an ugly gray background with thoughtless and spurious colors, and to multiply its woes, when the window was resized, all the text and all the fields expanded or contracted to fill the new space, often resulting in extremely ugly, blocky text and text fields.
The second reason was only a little harder to find; inconsistent everything! I found about 40 UI objects in the app, and there were over 70 different names for those 40 objects — a real user-turn-off in my opinion. Sometimes the differences were minor, like inconsistent capitalization, and in other cases the differences were stark as in a button labeled “DELETE” in one location where in another location, with the very same action, the button was labeled “REMOVE.” There were also semantic issues with control placement and other glaring errors.
This was an app used only by the company and not exposed to thousands or even hundreds of users. But what about ubiquitous apps used by millions of people? It’s amazing but there are glaring inconsistencies in some, especially between web and app versions.
A prime example is Gmail! The web version provides a good user experience as does the mobile version. Requirements of screens types dictate some differences like separating of emails into tabs, “Primary,” “Social,” and “Promotions” and allow the user to add more tabs if we want; sweet! The mobile version just doesn’t have the space for this luxury, but does include all the user-created folders, another great feature.
The inconsistency? Different names for spam emails! In the web version spam emails are dumped into the “Spam” folder, while in the app version they end up in the “Junk” folder. It seems to be a trivial difference, but it is annoying as I find myself doing a double-take when switching from one to the other.
There is also another inconsistency, probably the domain of Apple Mail for iOS, that is much more annoying and that is how deletions are handled between the desktop and app versions — deletions are allowed in any tab or folder in the browser version, which is appropriate and useful. In the app version, though, there is no “Delete” in the Inbox folder, Drafts folder, Sent folder Junk folder, Trash folder, or user-defined folder, and to trash an email requires a (careful!) swipe, a touch to expose the “More” menu, then a “Move Message…” then a touch on “Trash” — did you count the steps required? …four steps to do one of the most common actions! Pathetic! Only the “All Mail” folder has a “Delete” control. It is also the only folder that allows “Delete” with a left swipe, where the other folders left-swipe action provide provide only “More,” “Flag,” and “Archive.”
Another problem here is that there is no “Archive” folder! Where the hell do “archived” emails go? And, how can I get them back to the inbox when they are “archived” by mistake?
What more can you expect from a free app? Sorry, I want consistency!Read More
What is a wireframe?
Technically, wireframes are simple, black on white line drawings of an interaction. The idea is to show how an interaction might work while being completely agnostic to visual design. A wireframe could be produced with pen or pencil on paper, or with some kind of software.
I kind of like wire frames that look like they were hand-drawn — just an idiosyncrasy of mine that is possibly shared by other interaction designers, being as there are several software ways to produce designs that look and feel like hand-drawn wireframes.
In many situations, though, “wireframe” is used for page and flow designs where the site or application designs being called wireframes are extremely tight and fully-colored and styled representations, and properly so. Example: I recently worked on a large national site moving older pages from a content management system that was being dumped to a new system. The new design was done and extremely detailed, and so our wireframes were appropriately fully rendered, pixel-perfect pages. There was no point in changing the really well-done designs into black and white drawings.
Wireframes are, after all, a tool for building interactions — not the “end” itself. Although I have to admit a dark desire to build an entire site that looks like a hand-drawn wireframe!