ICS’ Head of UX Answers Your Questions
Participants in ICS’ recent webinar UX Design for Software Engineers posed a slew of interesting questions. I'm tackling a few here. Look for an upcoming blog with answers to even more of your UX-themed questions.
You recommended designing for 80% of users but isn't that a lowest-common-denominator approach? Won't a UI designed for a 65-year-old frustrate a 20-year-old digital native, for example?
This is a question designers wrestle with often. Like all technical problems, there are a lot of "it depends on..." parts to answer this. You have to consider many aspects of your demographic, including age, technical literacy, physical abilities and culture. In UX, we often take our user demographics data points and turn them into example personas that we then design for. Typically, there is a primary persona we focus on for the design effort.
So, we might ask who is the primary focus of the effort here — the 65-year-old or the 20-year-old? The answer will guide design direction. Ultimately, trade-offs will be made. If we make the right ones, both people will be able to use the UI without becoming frustrated. They’ll both be delighted instead.
Why do you think Rule 1 — always strive for design consistency — is the rule most frequently violated? Any hints for adhering to the rule while developing?
Rule 1 says that "consistent sequences of actions should be required in similar situations; identical terminology should be used in prompts, menus, and help screens; and consistent commands should be employed throughout." My statement that this rule is the most frequently violated is anecdotal. Over the years I've worked on many applications that had very obvious inconsistencies, and when I asked other developers why that was the case I’d hear, “Howard worked on those screens, and Colin worked on the other screens at a different time.” Apparently, Howard and Colin didn't communicate.
Like most folks, developers do what they think is right and may not bother to check on small details that they don't feel are important. Problem is, while those details may not be important in the moment over time they add up to glaring inconsistencies. Preventing this is a matter of paying close attention to detail and ensuring ongoing communication, establishing a QA policy, and tasking a lead designer or manager with catching these issues.
Regarding your recommendation to design first and code later, what if the design shows something that can't be implemented by existing technologies?
Better to find that out during design than after coding starts! Also, change your design. I would love to have an AI-based holographic projection system for my personal assistant, but the technology isn't there yet. One of the tenets of my team is to not design things that can't be implemented since that doesn't help with the business goals of delivering a product. Pushing the boundaries of technology and creativity is great, but at some point the product has to ship.
How does UX help with determining the best workflow for the application?
The workflow of an application is driven by understanding the target user and what they are trying to accomplish with the system. In the planning phase, a UX designer will perform a Hierarchical Task Analysis (HTA) of the problem space to gain a full understanding of what the user wants to accomplish, which will then drive the workflow design. Like many aspects of the creative process, planning is far more involved but a solid HTA is a great starting point.
How should I choose the proper direction in designing the GUI? Should I go into tiles and views for a newly designed app or use regular controls?
Such specific design questions like this are very difficult to answer in the abstract. The better questions are, what is the end user expecting for a UI design, and what are they trying to accomplish with the system? There are other questions to ask, but I would start with those and let the answers drive the discovery process, which eventually leads to a final UI design.
What is a good alternative to a dialog in exceptional cases, for instance closing without saving pending changes?
It’s a fine line between anticipating the user's needs and letting them do what they want, versus paying a high penalty for doing the wrong thing. Very often, the answer is — to borrow from a famous sneaker manufacturer — to just do it. Being proactive, but also providing a safety net in case we guess wrong, is a good design option to consider. If we think that over 80% of the time saving pending changes is the right approach, just go ahead and do it. But since we want to be very careful about not overwriting work the user might have wanted, we could save both versions of the file and then provide a mechanism to let the user decide which one they want.