Purpose Your goal is to create a design for a software interface. You will exper

Question

Purpose Your goal is to create a design for a software interface. You will experience the scope of the design process from brainstorming ideas and gathering information about users’ needs to storyboarding, prototyping, and finally, testing and refining your product.As you work on the software interface, you will demonstrate your ability to apply fundamental Human-Computer Interaction principles to interface analysis, design, and implementation. You will be responsible for delivering project components to your professor at several points during the course. Action Items A lo-fi prototype shows all the elements of a user interface, drawn out on paper, notecards, or cardboard. Its purpose is to get quick feedback from users early in the design process when changes are still easy and relatively inexpensive to make. You can use a lo-fi prototype to identify usability issues such as confusing paths, bad terminology, layout problems, and missing feedback. Watch the Hanmail paper prototyping video to see an example. Please note that your paper prototype does not need to be as extensive as the one shown in the video.Your prototype should allow people to navigate from screen to screen, recover from errors, and change their choices. Show sketches of all the important areas of your design. Don’t try to show every possible action or detail. Focus on the main interactions. Remember, this is hand-drawn so that you can make changes quickly and easily if you get a better idea. Keep track of what you changed and why. Refer to the Lo-Fi Prototype Rubric to self-evaluate your work and edit as needed.

Explanation / Answer

Interactive Systems

At its broadest, an interactive system can be any technology intended to help people complete a teask and acheive their goals, however this could include things like pens, which could help acheive the goal of leaving a message for a friend, so we tighten this definition to be any technology incorporating some form of electronic logic designed to help people complete tasks/acheive goals.

Alternatively, we could define this as any complex system with a UI. That is, something we need to give instructions to and know the status of in carrying out those instructions. These things are called systems (or artefacts), which we have dialogues with. Having dialogues with non-humans (and other animals) is a relatively new concept over the past 50 years.

Usability

For many years, the key has been thought to be making interactive systems usable, i.e., giving them usability.

To be usable a system needs to be effective. The system supports the tasks the user wants to do (and the subcomponents of such tasks).

We could also consider other components to make things usable. Efficiency - the system allows users to do tasks very quickly without making (many) errors; Learnable - the system is easy enough to learn to use (commensurate with the complexity of the tasks the users want to undertake); Memorable - the system is easy enough to remember how to use (once, learnt) when users return to asks after periods of non-use.

We are now moving beyond that to consider satisfaction - the system should make users feel satisfied with their experience of using it.

Positive user experience, rather than usability has now become the focus of the design of interactive systems, particularly as we have so many systems that are for leisure, rather than for work. This expands usability to cover issues such as:

Another way to think about usability is for the user interface to be transparent/translucent to the user - the user should be concentrating on their task, and not on how to get the system to do the task. This might not be the case originally however, though. For example, with the pen, you had to think about it when younger and how to use it, and now you don't.

Difficulty in Designing Interactive Systems

Designing interactive systems on computer systems for non-experts has only been developed for 25 years, whereas something like teapots has had 4000 years to be perfected (and still has dripping spouts!). Books have had 500 years to develop systems containing the best design features (page numbers, table of contents, index, chapter numbers, headings, etc) and books can be used as interactive systems.

Affordance

Some things, e.g., doors, have a method of use which is ambiguous. Doors should afford opening in the appropriate way, their physical appearance should immediately tell you what to do.

Affordance could be formally defined as: "The perceived and actual properties of an object, primarily those properties that could determine how the object could possibly be used" (Norman, 1998).

Affordances could be inate, or perhaps culturally learnt, but a lifetime of experience with doors, etc, means the interface to these systems is (or should be) transparent. Well designed objects, both traditional and interactive have the right affordances.

Are Current Systems Sufficiently Usable?

It's been estimated that 95% of functions of current systems are not used, either because the user does not know how, or doesn't want to. One of the causes of this is that anyone can use a computer these days.

Key Principles of Interactive Design

Interaction Styles

We need to get computers and complex systems to do things - somehow we have to "tell" them what to do. In turn, they have to give us information - the status of the system, what to do next, what's wrong, how to fix it.

One metaphor for this is to consider interacting with these systems as a dialogue - you tell/ask the system to do something, it tells you things back; not too dissimilar to having a conversation with a human being. Another metaphor is to consider these systems as objects that you do things with and interact with (for example, putting waste in a waste paper bin), or as navigating through a space and going places (the web).

Command Line Dialogue

This style is not widely used, but is useful to understand it to consider more recent and long-term developments. This is the first interaction style that appeared on PCs, taking over from mainframe systems.

The conversational metaphor applies here, where you're talking to the computer through your keyboard and it reacts. However, the language you speak in must be correct to the last dot and in the correct order, much like speaking a foreign language. The system doesn't give you any clues on what to do, so you must remember (or use a crib sheet), the syntax of the language. These commands can get quite long and complex, especially when passing lots of options and (in UNIX), piping one command to the other.

You also get limited feedback about what is happening, a command such as rf may return you directly to the command line, after deleting 0 or 100 files. The later versions of DOS took the feedback step too far, however, asking for a confirmation of every file by default. This is programmed by the interaction designer, and they have to remember to do this and get the level of interaction right.

If you do get the command correct, however, this can be a very efficient way of operating a complex system. A short, but powerful, language allows you to acheive a great deal and people are willing to invest the time to learn this language to get the most efficient use of the system.

However, although computers are good at dealing with cryptic strings, complex syntax and an exact reproduction of the syntax every time, humans aren't. This interaction system stemmed from the fact that processing power was expensive, so humans had to adapt to the way computers needed to interact, not vice versa. This is no longer the case.

Menu Interaction Style

Although the command line style was good for experts, it wasn't for novice of infrequent users, so an interaction style was developed which is almost the complete opposite of command line dialogue in terms of strengths and weaknesses - menus.

Menus are simple, as not much needs to be remembered as the options are there on screen and the physical interface corresponds directly to the options available. Feedback is immediate - selecting an option will either take you to another screen of menus or to perform the selected task.

Feedback is natural and built in -you can see whether you are going the right way, because either something relevant occurs - much like handling objects gives you instant built in feedback.

Selections from objects (such as radio buttons) can be thought of as a menu, even though the selection method is different.

Menu systems should be usable without any prior knowledge or memory of previous use, as it leads you through the interaction. This is excellent for novice and infrequent users (hence their use in public terminals of many varieties). However, a complex menu structure can complicate matters where particular features will be found (e.g., IVR systems)

Expert and frequent users get irritated by having to move through the same menu structure every time they do a particular task (hence shortcut keys in applications such as Word), and menu systems also present a lack of flexibility - you can only do what menu options are present for you, so menu driven systems only work where there is a fairly limited number of options at any point. Items also need to be logically grouped.

Form Fill-In Interaction Style

A form is provided for the user to fill in. Perhaps not the most revolutionary or interesting of interaction styles, but it is based on another real world metaphor - filling out a paper form. This also illustrates another problem with metaphors, not everything transfers well from one medium to another.

Forms present lots of little problems:

However, this system does have strengths. If the system is well-designed, any novice can use them and it has a strong analogy to paper forms, and the user can be led easily through the process. However, they are easy to design badly, and hence confuse and irritate the user.

Direct Manipulation

The heart of modern graphical user interfaces (GUIs, sometimes referred to as WIMP - Windows, Icons, Mouse/Menus, Pointers) or "point and click" interfaces is direct manipulation (note, GUI and WIMP themselves are not interaction styles).

The idea of direct manipulation is that you have objects (often called widgets) in the interface (icons, buttons, windows, scrollbars, etc) and you manipulate those like real objects.

One of the main advantages of direct manipulation is that you get (almost) immediate natural feedback on the consequences of your action by the change in the object and its context in the interface. Also, with the widgets being onscreen, you are provided with clues as to what you can do (doesn't help much with items buried in menu hierarchies). The nature of widgets should tell you something about what can be done with them (affordance), and with widgets, many more objects can be presented simultaneously (more than menus).

However, interface actions don't always have real world metaphors you can build on (e.g., executing a file) and information rich interactions don't always tend to work well with the object metaphor and direct manipulation becomes tedious for repetitive tasks, such as dragging, copying, etc...

Natural Language Interfaces

The ultimate goal of the conversational metaphor is for us to have a dialogue with the computer in our own natural language. This might be written, but spoken seems easier. Voice in/voice out systems have been developed, where the computer recognises what you say (using speech recognition technology) and produces a response, spoken via text-to-speech (TTS).

This kind of system should be "walk up and use", just speak your own language and this should suit both novices and expert users. This isn't yet technologically feasible, as the AI is largely fake and can only recognise key words. If speech recognition fails, it is easy to get into nasty loops, where it is not clear as to how you get out again (this is the feedback principle). There is also the problem of different accents and recognising older voices, and privacy and security issues are introduced.

Design Lifecycles

How do we get from interaction ideas and information about the users and how the users would like the system to workto an elegant, interactive system? Methods are needed to structure and organise the work, so one of the key points is to involves users in all phases of design. It's argued that it is too slow and and difficult to involve users in the design cycle, so how can this be tackled?

A number of different theories and methods are developed to describe the methods. In HCI, these are called design lifecycles, and all lifecycle theories and models include four basic components, although they emphasise different aspects of them. These components are:

Before we can continue, we need to consider what we mean by the term users. We can consider three levels of users:

You can also consider stakeholders "people or organisations who will be affected by the system, and who have a direct or indirect influence on the system requirements".

Waterfall Model

The advantages of the waterfall model is that each stage produces a set of specifications that can be handed on to the next stage, and the work is compartmentalised into clear chunks. There is some feedback from each stage back to the previous one, but this slows down the whole process.

With the waterfall model, it is very problematic to change the requirements as the project develops, and is difficult to consider alternate designs. Any change in design ideas are difficult to implement, as the system must be recoded.

Spiral Model

This model never really gained acceptance in the long-term in software engineering, or in human-computer interaction. In the 1980s, two models emerged from work on HCI, instead of software engineering, like the waterfall and spiral models. These models focus on the need to build interfaces and interactions to meet the needs of the users.

Prototyping

Users often can't say what they want, but as soon as you give them something and they get to use it, they know what they don't want. A bridge is needed between talking to users in the abstract about what they might want and building a full-blown system (with all the expense and effort that involves). The prototype is that bridge, it might be a paper-based outline of screens, a video simulation of interaction or a 3D cardboard mock-up of a device.

Prototypes are very useful for discussing ideas with stakeholders, and it encourages reflection on the design and allows you to explore alternative designs without commiting to one idea and to make ideas from scenarios that are more concrete.

Low fidelity (lo-fi) prototypes are not very like the end product and are very obviously rough and ready. They are cheap and simple to make and modify and it makes it clear to stakeholders that they can be criticised. They are fairly low risk; designers do not have much to risk with them, but they do not allow realistic use.

One form of lo-fi prototyping is storyboarding, a technique used in the film industry. A series of sketches, usually accompanied with some text (e.g., a scenario), show the flow of interaction. This is useful if you're good at sketching, otherwise it can be daunting.

Low-fidelity (lo-fi) prototyping is characterised by a quick and easy translation of high-level design concepts into tangible and testable artefacts. Lo-fi is also know as low-tech, as the means required for such an implementation consist, most of the time, of a mixture of paper, cardboard, post-it notes, acetone sheets etc. A clear advantage of lo-fi prototyping is its extremely low cost and the fact that non-programmers can actively be part of the idea-crystallisation process.

Lo-Fi as a remedy to tunnel vision

Whatever the background of the students, it was observed that putting students in a condition where they do not have the time for high-tech implementations forces them to focus on the conceptual design stage and explore design alternatives before deciding which one to carry forward to the next stage. This is especially important for students with an IT or SE background, since spending more time on the conceptual design stage forces them to pay more attention to the psychological aspects of HCI design. In addition, experimenting with lo-fi prototypes prevents them from getting tunnel vision and going for a type of design they are familiar with and know how to implement, as opposed to the design that best meets the user requirements.

For example, a group of students was asked to present the conceptual design of a hand-held communication device for children aged 9 to 12. Given that they had only two days to come up with a first design, the requirements were defined in a brainstorming session within the group, as they did not have the time to go and talk to actual children. Despite the fact that the user needs and preferences were ill-defined, the group opted for a medium-fidelity prototype. They designed a desktop simulation of a palm-top device, which looked more like an adult’s expensive gadget than a communication device for children. When asked about the functionality their system would support, they replied that it would run Windows CE and thus, that the children would be able to install whatever they wanted… The point was that these students rushed through the conceptual design stage only to be able to present a neat simulation.

Unleashing the students’ creativity by exploring alternatives can best be achieved by promoting throw-away prototyping. By presenting it as an exploration phase, students are more likely to focus on the iterative refinement of their ideas rather than on the details of their technical implementation. Although some students prefer to see their ideas turned into a visually pleasing computer-based system straight away, one should bear in mind that the refinement of their medium-fidelity prototype might take precedence over testing the relevance of the system for its target users. If the educational objective is to teach students that HCI design consists of several well-defined stages , then care should be taken that the students do not neglect or skip parts of the process just because they want to demonstrate their programming skills.

Conclusion

The advantages of lo-fi or low-tech are numerous. In addition to being cheap, fast and accessible to non-programmers, these rudimentary techniques can yield a maximum of feedback on design ideas at a minimal cost. Insisting that students should consider adopting low-tech throw-away prototyping instead of going straight away for a computer-based evolutionary prototype might help them explore alternatives and, above all, focus more on HCI aspects of the target system.

Related Questions

Navigate

• Browse (All)
• Browse P
• Subjects

Integrity-first tutoring: explanations and feedback only — we do not complete graded work. Learn more.