Discover articles specifically written for new user experience designers. We will cover a lot of basics in here and a little bit on advanced topics. You will find no where like this on the web as I share with you my years in the field.
Yes, that is right mobile is here to stay and despite what you might think a mobile design can be as complex as a web application design. Why would I say this? Think about it… The rate of mobile growth is exploding. We have our tablets, smart phones, and the in between devices like the ultrabooks. With all of this technology, customers don’t just want to accomplish simple tasks, no quite to the contrary, they expect software to behave much like it does on the desktop.
That means smarter design, design that adapts to the experience, and design that adapts to the device. No, this is not an article on responsive design. That has been done to death this year (and the year isn’t even over yet.). What I want to look at is how we as mobile user experience designers make highly complex apps friendly to use. So let’s break down some design patterns and see what happens when we try to make them smarter, not just smaller.
Mobile Forms & Mobile Payments
The mobile payment market is ripe and rich. We are all working, living, and existing on our mobile platforms. The end result is the ability to make and complete purchases quicker. This area of design has a long way to go before it becomes as great as store fronts want it. Let’s take a look at some key items to remember when creating forms for mobile & portable devices?
- Shorter Is better – No brainer here, only collect the information you need when you need it.
- Form labels on top – Why? Quite, simply on smaller form factor devices labels aligned to the left may be hard to read and most likely covered up and not visible. This also poses a problem when a virtual keyboard is in use which may cover up the visible label area.
- Response Inline Errors – Now the goal here is to really eliminate as many errors as you can from the get go. The truth of the matter is there will be some — from password mistypes, to incorrect zips. No matter what you do you are going to end up with these errors from time to time. Save and dedicate small space near your input field for errors. Remember text might be scarce so make sure your message means something (if it’s icon, or a single word).
- Inline help – while nice on the larger devices can just get in the way when you are trying to complete a task. Be careful how you use this type of system.
- Eliminate the need for redundant entry points. Stop, truly stop, and think about why you need to duplicate data.
- Mobile Payments – If possible the best payment systems in the future are going to be coded, or be linked to some highly sophisticated encrypted payment system. We are not quite there yet, and if you have tried to make a payment for a product at a store on mobile you may have felt the pain. Keep the form to the necessities, Right now it is so easy to loose customers on accident because of form faux pas. Before you release that transaction form, test it, try it, live it and breath it. If you can’t complete it and your testers can’t complete it within a reasonable time , rework it!
One simple word on this – as any Information architect will tell you, chunk your content in easy to read bites. If you are building specifically for mobile smart phones, you may want to loose the verbosity in favor of clarity. Yes, even if your site is primarily aimed at marketing – think of using your elevator pitch.
Navigation & The “BACK” Button
I would venture to say most smartphones now a days have a back button built in. Just remember this and remember to work with the design then against it. I think we are still a long ways off before we see the back button disappear from inside your application. Be smart about leaving it in or out of your design. You may get some valuable real estate back if you don’t decide to have it on every screen.
What Is Your Mobile Product Purpose?
How Will Your Audience Consume The App?
Do you have a clear definition of the end product? Think about this simple problem I’m sure we have all faced. You are in the car driving to your favorite place and you want to make a quick stop at “X” shop only for a minute. You pull out the mobile fun and are plunked on the mobile version of the site. Great!, but WTF – Why can’t I find the button to locate stores. Why can’t check to see what products are available? Why can’t I do any of the things that exist on the primary site.
The mobile experience has been so reduced that you hastily look for a link back to the “FULL Experience” The full experience on the mobile should include the most used actions for that situation! Don’t make me search for Locations in a hidden button menu. Don’t make me guess which menu option they are under!
Here is a real world example to make this hit home a bit more.
This Christmas I wanted to do some last minute shopping. I was already out and about and decided to pull up the Galleria mall in Dallas. What are some questions you might want to know right away?
1. What time does the mall open?
2. What are the special holiday hours?
3. What stores are available?
4. How can I contact the mall information desk?
5. Map of the parking area?
In my case I just wanted to know what time the mall was open. This was probably the single most important piece of information for my holiday shopping needs. I searched for about 4 minutes and couldn’t find this one piece of information. So I did what we all do switch to the large site and started clicking like a mad men. In this case it was more of a Information Architecture. I just didn’t think to look under “VISITING.” Nestled under 1 more layer of navigation were the hours! I would have expected this on the home page. Why hide something that prevents people from shopping?
To sum this up. We as mobile user expect more. This goes beyond responsive design. Responsive design doesn’t matter if the design elements that are being changed have no bearing on the application completion tasks. In simple terms if a feature isn’t essential to your product think long an hard about where it should exist in your mobile application. Make it smart!
Well it’s day 3. And day 2 was a blur as it tends to be. Day 3 starts a little later with my frist session being on UX Tools. I’m curious to see what they will cover in regards to new quick UX tool technology. While I wait and since there is no one around to talk to directly I figured I would share a little bit about what some of the planned events are today.
In this article we will examine the type of UX person you are or will be. So join me for the first in a new article series. We will take a historical look at user experience, and then in future articles look more at your personal UX style.
Taking a look back at the past several years of User interface design has revealed some interesting insight into trends and techniques. The last few years we have been undergoing a transformation of the user experience. Today I believe this is no longer true, at least at this slice in time.
Today for lunch I decided to swing by Jack in the Box. Little did I know I was about to have a unique UI experience. Upon arriving we were introduced to the brand new (at least in this area) self order system. And thus began my customer experience.
If I had a million dollars for every time a client asked me to add more features, or more appropriately stuff and jam more features into an already bulging application, I would have published a book, bought a mansion, and maybe a small island somewhere in the South Pacific.
Welcome to my first in a series of design processes instructions and examples. These are setup in such a way as to walk you through development cycles in relation to creating, producing, usability testing, and execution from a UI Design stand point.
Let’s talk about proper widget usage. It’s imperative to know when to use the right tool for the right job. I wouldn’t use a sledge hammer to hang a painting (unless it was a very large painting.) I wouldn’t use a socket wrench as a pliers. I could use a butter knife to screw something in, but is that the best solution? It’s all about using the right application piece at the right time.