Defines user interface interaction design in industry, describes the interaction design process, and provides some insights into the pros and cons of a career as an interaction designer.
1. Interaction Design in Industry Lawrence J. Najjar, Ph.D. [email_address] 5th Annual Regional HFES Student Chapter Conference California State University, Long Beach February 27, 2010
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
Notas do Editor
This is what I’d like to talk about today. The process is a good way to understand what we do.
The point I’m trying to make here is I’d like to talk about interaction design and I know a little bit about it I like to write, so I’ve written a bunch of papers. If you’re interested in what I talk about today, you might want to read some of the papers on my Web site. In fact, Dr. Vu and Dr. Proctor have been kind enough to allow me to present papers in some of her conference sessions and to write a paper in her Handbook of Human Factors in Web Design book.
After Paige invited me to do this talk, I had to decide what I wanted to talk about. This meeting is run by a student chapter of HFES. In human factors we try to think like the user. I wanted to put together a talk that would be helpful to you. Most human factors jobs are in industry, so I thought I’d talk about what we do there. References: More than half of all survey respondents (55.5%) work in for-profit organizations 1 (HFES 2009 salary survey); about 85% of us work in industry 2 (UPA 2009 salary survey)
Way things work rather than the way they look (which is visual design) I’m talking about the user interface controls on the page – which ones are there, how they work, what they do. Not going to talk about how user interfaces are coded
I’d like to walk you through the process, the GENERAL, most frequent steps we follow on an interaction design project There are other possible steps (task flows, content analysis, usability tests) that can also be added One thing you may notice as I go through the process is that it is a user-centered design process . We focus on the needs of the users. Also, in this process we start high and work low ; start with broad, general info and work to low, more detailed design specifications
The first thing we want to find out are the goals What does the business want from this project? Why are they doing it? Why are they asking us to create this application or design these new functions? What are the users trying to get done? What tasks are they trying to get done? Why are they using the application? Finally, what is the purpose of the application? What needs is it trying to address?
Remember I said we focus on the needs of the users? To do that, we start out by talking to users & stakeholders One interviewer, one note-taker: One person asks questions, maintains eye contact, asks follow-up questions. Other person take notes. Stakeholders are very interested in the project’s success, know the domain, and have a broad, strategic view of what the application can do for the organization Stakeholders know WHY the project is being done and WHAT they want the outcome to be Also, we want to make it clear that their opinion is important and is being listened to Talk for 1 hour because that is generally all the time you can get Talk to about five stakeholders Users are more tactical & use the site to get their tasks done Talk to them in their work environments because can learn more about their needs Talk for 1 hour because that is generally all the time you can get Talk to about 20 representative users We ask background questions & open-ended questions Specific questions help you identify who you are talking to and how representative they are Open-ended questions are great for getting unexpected info (What do you like? Dislike? Change?) We summarize what we find in the interviews Often use bullets Your users are like this, they need this, they don’t like that
We get a little narrower We take all the notes from the 20-something interviews and distill them down to something that is easier to work with -- personas We use that information to create five or fewer personas – describe a representative user of the application – background, goals, tasks, needs, priorities, challenges/problems You could think of a persona as a user profile that has been personalized We use the personas to guide us during design (e.g., “Anna needs [function x]”) We design a user interface that meets the needs of the users described in the personas We review the personas with clients and refine them Usually the clients nod their heads and say “That’s right. That sounds like Mary or Steve or whomever.” Sometimes we have to make a few minor changes
Now, we get narrow, even more specific, more refined We take what we’ve learned from the interviews and the personas and write functional requirements Often break the requirements into 2 categories – Functions and Content Functions = Actions Content = Information So a company intranet will have functions like completing your timesheet and information like how to get an employee discount on a new computer Functional requirements are the most important task Tells you what you are going to design Doing a good job here helps the rest of the project be successful Prioritize using criteria like “Value to Users,” “Business Feasibility,” and “Technical Feasibility” Scoping means estimating how long it will to take to code a function If it takes too long to code a function, the client may want to move it to a later phase of the project Can have a couple of hundred requirements
We get even more narrow, more specific Using the requirements, we organize the information in the application into sections and create wireframes for individual pages Either draw all the application pages or representative samples On some projects, we write task flows; sometimes is not efficient because the boxes and arrows are so abstract that many customers don’t understand them; everyone understands page drawings.
Look at the five most important or frequent tasks So, guerilla usability – no usability testing lab, no tightly controlled conditions. Just looking for ways to improve the design. After getting feedback, we improve the wireframes
Then we get the most narrow; we write detailed interaction design specifications
So, these are the interaction design steps we reviewed User-centered Broad to narrow Did not include competitive assessments, content inventories, task flow diagrams, usability tests which we do when needed
Here are some things you might want to know about interaction design in industry Insights Greater design creativity: Have to go from list of requirements to a blank screen and design a wireframe Impact: After you’re done, people use what you’ve designed, often every day at work. Academics can have long-term impact if they come up with a new theory that explains human behavior. Delay of gratification: Companies want to get a quick return on their investment. They want your work finished quickly so they can launch it quickly. Publications can take a year to come out. Do good work fast.
I’ve done interaction design for a while, I figured I’d share with you some of the things I’ve learned. Some words of wisdom… Easy is hard: To design and build a simple, intuitive user interface you need a committed client, determined development team, solid process, plus hard work, skills, and time. User interface design is an art and a science: But it is more an art. When I started out, I was trained as a scientist and was dutifully looking for research to support my design decisions. I learned pretty quickly that there usually isn’t a study to help me decide what to do. Most of my design work is based on experience and judgment. No one gets it right the first time: But more experienced designers get it more right the first time. Even experienced designers don’t get the design right the first time. Iterate your work. Get feedback from users. Like anything, the more you work at it the better you get. As you get more experienced you get a feel for what you’re doing and avoid dead-ends that would have tripped you up earlier in your career. Users are bad designers but good reviewers: Users know their domains really well, but they are not trained designers. Work with users to identify their challenges, needs, and preferences. Listen to their suggestions. Ask them how to organize information. But don't let them design. Instead, ask users to give you feedback on your designs. Just because you can, doesn't mean you should: Don't show off your team's ability to add fancy new functions or use the latest technology in the user interface. Give users only what they need. Users just want to get their work done. Don’t use technology just because you can. Keep it simple. Several iterative designs of a static, low fidelity user interface are more effective than one version of a dynamic, high fidelity user interface prototype: The key to successful iterative design is the ability to make changes quickly. It is much easier and cheaper to change a static wireframe drawing than a dynamic, coded prototype. Plus, the designer can make the changes rather than a developer. So, iteratively design static, low fidelity wireframes until you get the interaction design right. Then, if possible, work with developers to code an interactive prototype to help sell the design throughout the organization. No one takes the training. No one reads the Help: Users are busy. Design so that users can get their tasks done without training or assistance. Assume users know their domain but not your application. Provide training and online Help, but design the user interface to assume users are not going to use it. Air traffic controllers don't want a "Help" button on their keyboards: But an "Info" button is just fine. When I was designing the keyboard for US air traffic controllers, I put a Help label on the F1 key – the top left key in the function key row at the top of a keyboard. After I presented the design, an air traffic controller took me aside and said something like “About that key…” So I gushed about what it is and what it does. He listened patiently, and when I was done he told me that air traffic controllers get years of training. Air traffic controllers tell pilots of aircraft carrying hundreds of people what to do. Air traffic controllers don’t need help – but they do need information. So, I quickly changed to key label from “Help” to “Info.” The lesson learned was “know your users.” Initially, visual design trumps interaction design. Over time, interaction design trumps visual design: People react emotionally to images, colors, and fonts. But once people begin using an application to get their work done, ease of use becomes paramount. Pictures are better than words: People remember what they see, not what you describe. If you want clients to understand your design, show drawings. I’ve learned this the hard way. I’ve written detailed task flows and gotten clients to sign off on them. Then when start building the actual pages with task flows, clients tell me that is not the way their business is run. But they signed off on the task flows. Clients never really understood the task flows the signed off on. So, I try to show page designs when discussing task flows. You can do great user research and analysis but clients won't be comfortable until they see the first wireframes: People have to see something. Textual deliverables – words – don’t cut it. When you show page layouts, people understand what you’re doing and feel more comfortable about your progress. Good design is more effective than good testing: The key to success is to design a user interface really well the first time. Better to design a good user interface and find minor changes in usability testing than to design a bad user interface and try to make major changes after usability testing. Time and money run out. If you design a bad user interface, even if you test it over and over you’re unlikely to get it as good as if you had an expert design a good user interface right away. The usability tests are like band-aids – you make little improvements but don’t get the time and money to make big changes. Also, it is a lot harder to find a good designer than a good tester. I’ve found that it is easier to find someone who can perform a good usability test than it is to find someone who can create simple user interface designs. So, given the choice, try to become a good designer. Interaction design, visual design, programming. A person can be great at only one: I’ve been seeing a lot of ads where they want someone who can do all three of these tasks well. I’ve never run into anyone who could do two of these tasks well. I think it is just the way people think: Interaction designers think like users. Visual designers think like artists. Programmers think like computers. I’m thinking the ads are combining three different jobs into one to save money and make things convenient – one person owns the front end. That person analyzes users, does the interaction design, draws the graphics, and does the front-end programming. Quality lasts. Doing work fast or cheaply does not hold up. What you save in cash you spend in support or future fixes. Quality work holds up over time.
If you want to contact me, here is my e-mail address And if you want to read other papers I’ve written on this topic, feel free to check out my Web site
![Interaction Design in Industry Lawrence J. Najjar, Ph.D. [email_address] 5th Annual Regional HFES Student Chapter Conference California State University, Long Beach February 27, 2010](https://image.slidesharecdn.com/interactiondesigninindustry-7-110130144310-phpapp01/85/Interaction-design-in-industry-1-320.jpg)
![Agenda ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)