Lessons in UX Design for Non-Designers

Participants in ICS’ recent webinar UX Design for Software Engineers posed so many interesting questions I couldn’t get to all of them in my first post so I’m tackling a few more here. If you missed the webinar, you can watch it on demand here.

What are some good UX tools?

That is a very broad question since it covers many aspects of the UX process, and tools can range from the tried and true (pencil and paper) to the technical and sophisticated (eye tracking techniques). Like most UX designers today, we use the Adobe Suite for much of our visual design work. As far as specific design tools, my team uses prototyping tools like Axure to produce both low-fidelity and interactive wireframes for use during testing. In terms of testing, our feedback capturing is very straightforward: we record the sessions, and as a team analyze the results at the completion of the sessions. Sometimes the traditional ways still work the best.

What is the the best way to communicate motion design to developers?

We use a few techniques. One is to make an interactive prototype using a tool that lets a designer show how the motion is supposed to work. Again, we use Axure for much of our prototyping work, which lets us model motion such as screen transitions. For more complex interactions, we might create a video snippet using a tool like After Effects to show all aspects of the motion.

How should we address aspect ratio and layout? How do we design UX?

Questions of aspect ratio and layout are highly project dependent, and this question could be interpreted several different ways. From a developer's perspective, layouts in Qt are often handled with the Qt layout constructs (QHBoxLayout, etc).

From a designer's perspective, we have to consider the type of project we are working on the and the platform -- say desktop versus a mobile. Then we have to determine the ratio or layout change at run time, for instance a mobile device changing from portrait to landscape. The designers have to construct the correct design to solve the problem at hand, as well as consider how the design will behave when implemented with the applicable Qt constructs. Knowledge of capabilities and communication between the parties are essential to make sure the solution works as intended.

Regarding disabled functions like the copy menu item, how do you provide the user with information about why a particular function is disabled?

There are a number of ways you can give the user feedback about why an item is disabled. The simplest is probably the Tooltip, a small text box that comes up over a control when you hover over it with a mouse. Qt supports this natively for many controls. For traditional desktop applications, you can use the status bar at the bottom to provide a similar message. This is an example of the third rule of Shneiderman’s Eight Golden Rules of Interface Design: offer informative feedback.

Can consistency be more rigorously enforced with a richer type theory? C++ is strong in this regard, but it is possible to get even stronger adapting techniques from Haskell and the like?

Possibly. You can codify certain elements into pattern libraries, themes or even QStyle objects that enforce the use of visual elements like colors and fonts. Using the standard Qt dialog boxes can also help, and then further building a library of specific patterns to solve specific problems.

But designing and building a GUI is a complex endeavor.  I think you will only be able to get so far with the programming language and compiler enforcing things. At some point, you still need a person or team checking the details, be it within a single application, across a suite of software or for industry standards.

What are some universal design considerations people often forget, for instance red-green colorblindness?

A very common consideration is not only designing for people's physical capabilities, including such conditions as color deficiencies, but keeping in mind that physical limitations may appear only under certain circumstances, for instance while using a particular device or in a specific situation.

For example, text that looks great to a 20-something engineer on a large desktop monitor might not look as clear to an older user on a smaller screen. Or, a certain set of colors used for a mission-critical system might be hard to read under emergency lighting. That's why it is essential to know not only your user, but where and when he or she will be using the system you are creating.

For more on UX design, check out our blog.