UI Design Articles
View the latest Uidesignguide articles organized by discipline, and interaction design field area.
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!
This is the third article in my long running series on Agile and User Experience Design. I have a feeling this will generate quite a bit of discussion and as an experiment I will also post this on my Google + stream. Let’s get started shall we.
As a UX professional, agile is less about a methodology and more about adaptive design practices. It’s about taking all of your “UXPERIENCES” and squeezing them into a magic box and then pulling out the tool, item, or design pattern you need. It’s about taking business requirements and using an idea to formulate working models and design concepts. The tools are not the Swiss army knife, you are! The key to making Agile UX work for you is the ability to draw upon experiences and resources quicker and faster. You need to be able to filter what’s important and what isn’t.
I recently received a preview copy of “Designing for the Greater Good.” by Peleg Top & Jonathan Cleveland. This is a hard bound coffee table size book full of non-profit design examples. Often, the world of non-profit design is viewed as second rate and a burden or after thought. This book helps to show that just because a designer is not getting paid, that beautiful non-profit design can and does happen everyday. Inside you will find a showcase of some of the best non-profit design available today.
When I travel to conferences and speak with people about their agile UX experiences I come across a lot of repeat questions. Most of these pleas for help are about time management, rapid design sketching, traditional usability approaches, group design mentality, lack of support for UI development, and let’s not forget meeting burnout.
Even today UI designers hear the word AGILE and there mind is flooded with demon visualizations straight out of Dante’s Inferno. Why has this methodology caused so many headaches to UI Designers world wide? Why are they terrified? Can we beat them, or should we join them?
Almost daily I face this this challenge. In fact it is infuriating about how many times in the day a usability concern is locked into the backseat. New features almost always seem to win versus making a new product better simply by improving the usability of an application.
Think of it like Jenga. In the game Jenga you must pull out the bottom blocks and place them on top. Every time you place a new block on top the structure becomes shakier and is unable to support the weight until it eventually all crumbles to the ground.
First off let me state it’s been awhile since I have posted. This is mainly because projects have kept me busy.
Lately, I’ve been trying to push the power of paper-prototyping. It’s a tough concept to get across though because some just don’t see the value. In fact, the customer, BA, Product Owner, just want you to show the customer a mocked up (coded) prototype. This is nerve racking because problems and issues in the design can be ferreted out much quicker using the paper prototyping method.
The title pretty much says it all. After working for a while now in an agile development model. I’ve discovered several disturbing things that really cause a loss of sanity. The agile development cycle is quite fast. Depending on your team it has different lengths. Most iterations seem to be 1 week long. During that week developers develop working software. Notice I said working software and not “USABLE.”
So as I was laying here sick in bed and thinking about design stuff. That’s the great thing or a curse about having a design based job. Even while you are sick you can’t always turn off your brain. So unless asleep or staring at the tv you are always thinking.
Imagine with me a minute that you have just identified in your Book Keeper 2.0 web application that too much information and functionality is jammed into the “add new book” page. The business analysts insist that everything needs to be available to the user. They “need” to have the ability to do numerous things on 1 particular web page.
One topic that constantly is under debate in the corporate design world is: “Who makes the final decision.” Does the designer, business analyst, information architect, developer etc? Personally, this has been a major area of contention. When it comes to design and the user interface everyone wants to proclaim they are Caesar. Can you blame them? Everyone wants to have a say in what an application looks like?