Practical .NET

The Last Step in UI Design: Scripting Interaction

An interaction script bridges the gap between designing concepts and actually adding controls to forms. The interaction script will tell you what your application needs to do, leading you (finally) to what controls you need on which forms.

• By Peter Vogel
• 07/24/2014

I'm writing a course on UX/UI Design for Learning Tree International, so I've had UI design on my mind lately (this column and my previous two columns are the fallout from that preoccupation). I have to tell you: I'm worried about what the participants who come to the course will expect (assuming anyone comes, of course). I worry that the course's participants are expecting to be told where to put the cancel button on their forms, and unfortunately, that's not what the course is about. By doing the right things in UI design, when it comes time to start putting controls on the form, the answer will be obvious. This approach means we don't start building UI prototypes until halfway through the course. You can see why I'm worried participants who are focussed on building UIs might be disappointed.

In the course, as I did in my last column, I say the best way to create an effective UI is to not think in terms of "UI design" at all. Instead, you should take what you know about your personas and user stories, couple that with an understanding of user mental models and sketch out a series of conceptual designs without worrying about what controls should go on what forms. This process avoids the biggest problem in UI design: putting forms on controls before you find the right design.

Of course, in the end, you do need to put controls on forms. To move from that conceptual design to your intermediate design (your first draft of what controls you need to put on what forms), you must write an interaction script.

Your User and Your Application
The goal of the interaction script is to not drive down to the user's individual button clicks and keystrokes. The goal is, first, to describe what the user provides to the application and how the application should respond. However, you shouldn't limit yourself to just what your application does.

Your second goal is to include all the stuff the user does during the time your user is interacting with your application. Will they need to get additional information from some other source? Will they need to send follow-up e-mails to someone? Will they usually be interrupted? Will they have to leave your application and come back to it? If so, how will they carry on from where they left off?

But that's only your first two goals. The third (and final) goal for an interaction script is to identify all the barriers the user will run into -- all the places where your application could provide support.

Finding Barriers
For instance, imagine a help desk application. When a call from a distressed user comes in, the help desk operator will answer the call -- that's the first interaction. The second interaction occurs when the operator asks for the caller's name -- and that's also the first barrier. Can your application discover the caller's information for the operator? Once the caller is identified, can your application find help desk-related information the operator will find useful (for example, does the caller have an open ticket? What history does the caller have with the help center?).

Once the caller is identified, the operator starts gathering information from the caller about the current problem. This is the third interaction -- and the third barrier. How does the operator record this information? Could speech-to-text transcribe the caller's explanation of the problem and provide a way for the operator to grab critical information from that transcription?

The fourth interaction begins when the operator starts looking for an answer to the caller's problem. If the caller's explanation has been transcribed and the operator's identified the critical information, can your application use that information to support looking for an answer? Are there particular keywords operators use when looking for solutions to typical problems? And so on …

Many of the questions raised by the script will be answered through work you've already done in defining personas, scenarios and mental models. However, some of the questions raised by your script will lead you to additional research both about your users' jobs and the technology you might bring to the table. Some of these questions will be dead end (no answers available or beyond the capabilities of the technology available to you). Other questions will lead to more fruitful results.

By the time you answer those questions and fill in the details of your interaction script, deciding what forms (and what controls) you need to support those interactions will be a simple task. More importantly, though, you'll know that you're working on the right set of forms and controls.