Designing & Drawing Mobile Interactions

From MobileDesign

Presented at Design for Mobile 2009

[edit] Presenter

Steven Hoober (Little Springs Design)

1 PM | Monday

[edit] Abstract

Interactive has been seeking to find a solution to consistent, repeatable good design by hiring great designers, applying patterns and other single-axis measures. A unifing process, procedure and methodology is needed instead. Mobile is, if anything, worse with a focus on technology and and (recently) visuals, but lacking in broad application of design at all phases.

During ten years of interactive design, including managing an intractive team for Sprint, Steven Hoober has developed a comprehensive process for gathering, and analyzing information to create designs that meet the needs of the user, the goals of the business and the ability of technical teams to build.

This afteroon session will be occupied with series of brief lectures on design philosophy and hands-on exercises to analyze and design an example mobile website.

Attendees will receive Steven's forthcoming book on design process to assist them in implementing better process when they return to their jobs.

[edit] Course Outline

These are the terrible notes I used to guide myself through the course, for those who are interested.

PRECONDITIONS: Paper, makers, pencils, postits, whiteboards.

[edit] 0:10 (1300-1310)

What is Design – Here, just cover what we mean by interactive design, and intro to the class.

DEFINED - Interactive is all about the space between a machine and a person. It's about how that person becomes a user, by making the system do work for them in a directed manner. While we generally mean digital systems, this all applies to practically any sufficiently-complex system.

UI - It is all about interfaces, and not just graphical. Auditory, gestural, haptic, etc.

The point of the class: I think design IS drawing.

The design process cannot just be internalized. Make it visceral (moving muscles and dragging things across paper) to express, understand and improve.

We will do a lot of individualized exercises here.

The book, and all these procedures, are frankly universal. We're going to focus on mobile as we get deeper into it, basically because it's a mobile conference.

Additionally, mobile is small, task-centric and time-sensitive (generally) so has to be designed more robustly. Good procedures are important to follow to assure the system functions correctly.

[edit] 0:10 (1310-1320)

So, who does what? – Poll students on what their role is, what they want to do, individual, small, corporate, etc?

[edit] 0:02 (1320-1325)

Process, procedure, methodology – This is a set of procedures and methodologies, not so much a process. If I use that word, don't read too much into it. Use what you can, what makes sense for your situation and organization, etc. Note the book has a LOT more details on these distinctions, and on the individual procedures. (See 1.2)

Mobile is the same as anything else; not that it's the same design, but that you can design anything with this process, as long as you know the technical limits and contexts of use of what you are designing for.

[edit] 0:30 (1325-1355)

Gathering – First, do not draw. Spend your time reading, talking, listening and writing.

Talk to clients. Ideally sit with them, else send off surveys. (Sample questionnaire, 1.4.5, p. 43 onward)

Talk to users. If you just cannot get research, use friends and family, ask for others, do google searches even! I have made (good) personas from reading resumes and other s searches.

Talk to implementers. Work with IT, in an IT-like manner.

Consider contexts of use; I'd like to say this is mobile-specific, but it's just more important. Always needs to be considered – where are they using it, in what social environment, etc. Similar to the user/persona development (pick a few, not all of them).

Create requirements (do this?) or work with IT requirements folks, and prioritize them.

Create design objectives (can do this very formally, with morphology (1.4.8) or by simply cutting into the key business requirements (1.4.9).

HAND OUT “REQUIREMENTS” FOR LAWRENCE TRANSIT

This was created by a student researching the transit system here in Lawrence, and by others (not me) here at LSD; it is a bit typical of the sort of information you might expect to see from a client or from dedicated researchers; both too vague and too specific. We'll talk about it more in a few minutes.

[edit] 0:15 (1355-1410)

Information Design Theory and Principles – Right behind the core concept of interaction being the user employing systems, is that of information design.

Information Design is a “sense making” tool. It is used to make sense of (understand, evaluate, then influence) reality.

Information, that we are working with, is not reality. It's a representation of it.

PROJECT Info Design sample docs (PDF)

Procedure for Information Design (2.1.3):

FILTER

• Hide all information, process or system interaction the use will not need.
• Make visible all information, processes or tasks the user will want or need.
• Define the limits of any user interactions or customizations.

GROUP

• Determine user goals and tasks within the remaining information & functions.
• Group information and functions by task and goal.
• Group all other information by user logic.

PRIORITIZE

• Organize groupings heirarchically by user interaction, user logic or task process flow.
• Offer the lowest number of user interactions (clicks) possible.
• Consider architectures that present multi-layer information in an apparently flat manner.

ARRANGE

• Place items on individual pages based on grouping and priority.
• Specify a single template for use on most or all pages.

OPTIMIZE

• Revise the design, iteratively and with user feedback if time allows, to assure it is the right solution.
• Confirm with technical resources that it can be built and modify as necessary if not.

Only talk about it in samples. Show example box models, etc.

PROJECT WX pages (FH11) on Progressive Enhancement

Do not design one perfect screen: I call this Progressive Enhancement, though it's not precisely correct. Whiteboard my typical box sample. You are designing components, which can be reused, modified as needed, and appear based on rules.

[edit] 0:40 (1410-1450)

Information Design Procedure – Do the above. Prefer to break into teams, even if just two at a time. Try to use multiple methods (paper, whiteboard, postit) in the ONE exercise.

This is the whole system. Not a page. Pages, states, screens, etc. will fall out of it.

Let's make a box model. Take the requirements we have already got (see printout) and make each one a box or other element...

List out each requirement. Prefer to write them, but editing a piece of paper is okay. Or, each on a postit. Your choice.

TODAY, we're first going to make you think about the requirements list. Of course, you'd usually have done this beforehand and have gotten it all approved by the client, but I want you to have to think about it as part of this exercise

Consider the value of a service from a mobile POV

• “#34 Posted minutes to next train/bus at stations/stops” -- Bad req, as it's too specific; but we can toss the locale (At stations/stops) and use it anyway by placing the info on the mobile device.
• “#40 Safety from crime on trains/buses” -- Can we do anything about this? It's a great BR as it doesn't imply a solution. This is where brainstorming solutions and 'you as designers' come in

Move the filtered ones to the side. This is where the postit's help. For speed esp, but you can do it on a computer, etc.

Group related items (better to move to postits at this point instead of earlier) – Remember to group by user tasks, not systems or internal policy

Rearrange based on priority – Remember this is the user priority (multiple user populations are where you use the personas and those analysis tools)

Arrange items, move them adjacent and otherwise let them fall into natural areas from existing templates, or general practice

Scale! Sort of, only. Consider a sample number of items per line, lines per screen... scroll etc. so it's just a guideline for now; discuss my disbelief in “the fold.”

Pages should fall out of this by the grouping. Or, states if not explicit pages. Make sure, so the next step works out for us.

[edit] 0:10 (1450-1500)

Drawing is Scary – Poll the class again. How many can draw? Talk about how this works for those who cannot draw as it's a modeling language, so is all about pre-built components, and finding solutions based on recycling – Hint: try to restrict designers/artists (if just a few) from drawing, though they can talk all they want.

Reuse stuff from anywhere if you really cannot draw. Print out your favorite website and cut the components away as for the post-it exercise. You can get pre-made libraries, or make someone at your organization create these.

[edit] BREAK - 0:30 1500-1530

[edit] 0:15 (1530-1545)

UML, et. al. – How UML applies to the box model, directly. How it relates to IT process, OO design and dev, etc. Briefly. Do NOT cover each piece of the language, but more generally the concept.

Show samples of documents in HL format, and the nesting and linking.

[edit] 0:40 (1545-1625)

Drawing for Designing – Let's turn the Info Design box models into high level diagrams of the system. Specifically, the jump from the whole system to beginning to detail individual states.

For the exercise pick 1 state/page/screen to do this detail for. Not the home page, but they can choose (individually) which one to do.

Just draw on paper or whiteboard. Don't care which (or, combine it so they get clarity of paper for writing and paste it to each box in the whiteboard). Box, with divisions, and info as for HL diagram.

Project the sample document from the book for them to refer to. They should refer to the Info Design diagrams they made and NOT erase them

Lesson is about analytics; they have to explicitly note what is going to happen, and how the interaction occurs, in words.

If they complete that, detail the links in and out...

[edit] 0:40 (1625-1705)

Designing in the Details – Move up to the next level. Heirarchy of design:

Position > Size > Shape > Contrast > Color > Form

...and apply it to each element. Move them around, change them. Use patterns, brand standards, other good ideas from other sites (encourage folks to bring up their favorite solutions, put on the screen).

Complete this detail for about 1 page, or one per “team” of folks there. Not the home page, but they can pick on they like the looks of.

Mention re-use of components, and how this one page design is a valid sketching method, then you take the components and apply them to other pages, do NOT design other pages as entire entities.

[edit] 0:25 (1705-1730)

Wrapup – Provide time for questions and more discussion. Or draw some more. Or... something.

[edit] Discussion

[edit] Alison Hoober says:April 17, 2009, •Apr17•1914

Barbara's workshop: Gesture Design for (and with) Mobiles - will be held in The Eldridge hotel's All American Room at 1:00 p.m. Monday April 20th.

Steven's workshop: Designing & Drawing Mobile Interactions - will be held at our Little Springs Design Headquarters, 1901 Massachusetts Street at 1:00 p.m. Monday April 20th.

• • For anyone who would like to carpool to our LSD office, please meet at 12: 40 p.m. sharp in the lobby of the Eldridge Hotel.

Our building resides on the south/west corner of 19th Street and Massachusetts Street. We have two small parking lots on both the north and east side of the building which do not connect to one another.

Maps of the area can be found here: http://designformobile.mobi/downloads/d4m2009maps.pdf

[edit] Guest replies:April 20, 2009, •Apr20•0933

Thanks for the pic, that helps

[edit] Media & Downloads

• There was no slideshow. But some photos of the session are available at the d4m flickr pool
• And, the book used as a guide for the process is available for purchase