paper & pencil

Good Reads Week of Oct 5

The Future of Health Care Is Social
In this feature article, frog design uses its people-centered design discipline to show how elegant health and life science technology solutions will one day become a natural part of our behavior and lifestyle. What you see here is the result of frog's ongoing collaboration with health-care providers, insurers, employers, consumers, governments, and technology companies.

A shorthand for designing UI flows
Ryan of 37Signals describes a new shorthand for UI flow diagrams. Very simplified version that I think will come in handy at the start of a complex project.

Why Traffic Signs Don't Work (And What You Should Learn From It)
People respond more effectively to natural cues rather than artificial ones.

8 Ways Doing Less Can Transform Your Work & Life
Focus, quality over quantity, do better not more.

Facilitation: A Love Story
Facilitation is easily one of the top skills a UX professional should master.

Beyond Goals: Site Search Analytics from the Bottom Up
Overview of bottom-up analysis of site search stats and how it can complement a top-down approach.

7 Tips to Sell Your Ideas the Steve Jobs Way
Great tips for presentations and even for design sessions.

Good Reads Week of September 1

http://www.slideshare.net/billder/designing-humanity-into-your-products
Bill DeRouchey's presentation to relax and be human. (via David Kozatch, IxDA list)

http://www.agileexperiencedesign.org/profiles/blogs/story-mapping-with-jeff-patton
Video of story mapping with Jeff Patton and David Hussman at Agile 09. (via Anders Ramsay, agile-usability list)

http://unify.eightshapes.com/efficiency-tips/8-tips-for-organizing-project-files-folders/
Helpful summary of organizing files when multiple folks work on the same files.

The Secret to Writing Well
http://www.thinkingandmaking.com/view/the-secret-to
(More) Tips for Writing Well
http://www.thinkingandmaking.com/view/more-tips-for
Tips on writing and editing well from Austin Govella. (via Google Reader)

(un)Synchronizing UX & Development
http://www.thinkingandmaking.com/view/agile-ux-un
Working through how much UX should be handled in an Agile fashion. (via Google Reader)

35 Excellent Wireframing Resources
http://www.smashingmagazine.com/2009/09/01/35-excellent-wireframing-resources/
Links to articles, tool lists and other resources for creating better wireframes. (via Google Reader)

4 Lessons that Helped Me Optimize My Workflow
http://freelanceswitch.com/productivity/4-lessons-that-helped-me-optimize-my-workflow/

Getting up earlier, scheduled breaks, strict interruption management, take advantage of spare moments. (via Freelance Switch)

Mommy, where do ideas come from?
http://www.cooper.com/journal/2009/08/mommy_where_do_ideas_come_from.html
Exploring ways in which ideas come to be.

Playfulness in design and in the process

In the past week I've come across 3 articles on designing for delight as well as usability. Evidence of this, according to Fred Beecher, is in the undeniable success of the iPhone despite its many usability flaws, which he describes in detail (good tips on what not to do). I love this line:

While it’s still my responsibility to prevent things from sucking, now it’s also my responsibility to add a little playfulness.

Chris Fahey aims to put "three delightful details" in his designs:

...a humorous error message, a helpful hint at a difficult juncture, a way to skip a step in a process, etc.

And Dana Chisnell describes the 3 levels of happiness in a design: Mindfulness, Flow and Meaning.

Absolutely we should strive to delight in our designs. We should also have this goal for the design process. This is easily accomplished by making the design process visible and involving everyone in it - whiteboard sketches and walking through paper wireframes or prototypes. Especially when it includes markers. Seriously, who doesn't like to play with markers?

It also helps to introduce humor when there is a conflict over how to address a specific function. Suggesting something crazy like having a little head pop-up, usually of some colorful executive, a la "Clippy" style.

I've found when everyone can share in the designs and share in some laughs, it is much easier to arrive at a shared vision.

Integrating UX & Agile

Last week I attended a panel on integrating user experience into Agile development, put on by the Western NY Human Factors and Ergonomics Society (WNYHFES). The panel was interesting in that I learned more and more companies are embracing Agile in some way. However, there was not nearly enough time spent on how to integrate user experience methods into the process. Maybe there can be a part two.

What I'd like to see in a part two is more on cycle 0 and the UX processes that need to occur outside of and before Agile development begins. And more on how  to *design* in a more agile fashion. Rick Cecil's article for UXMatters addresses some of these topics. Lastly, a question from the audience on how to use Agile within fixed price projects could use further exploration as these are a fact of life for many agencies.

Here are my notes:

• Development is broken into shorter, smaller chunks: Analysis > Design > Coding > Testing
• Testing phases are informal, more like unit testing
• No clear answer on doing end-to-end testing
• Addresses the challenge of not knowing everything up front
• Add features as you determine need with users
• Mostly used with smaller teams
• Constant communication with developers, testers, stakeholders, etc.
• Can solve problems faster as they come up
• Agile assumes 1) everything is not known early; 2) discovery throughout
• Focus on delivering working code to customers at frequent intervals
• Constant collaboration to deal with new discoveries and to move forward
• Can be done (and is) with remote teams
• UX/UCD works 1 cycle ahead of development

Best part of the presentation was the following diagram from Desirée Sy's paper Adapting Usability Investigations for Agile User-centered Design.

---

Image above is from The Journal of Usability Studies, Vol. 2, Issue 3, May 2007, pp. 118 and reuse is subject to the following:

Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Copyright 2006, ACM.

The Lifecycle of a Wireframe

Nick Finck posted slides from his Puget Sound SIGCHI lecture on The Lifecycle of a Wireframe. Some slides are repeated and it's not clear why without hearing the presentation but it contains a great summary of key concepts and questions an IA should always be aware of.

The Life Cycle of a Wireframe

View more Microsoft Word documents from Nick Finck.

My overall strategy for IA is 3 step process; understanding the problem (note: not merely identifying the problem but really understanding it), find a solution (there may be more than one solution, but there is often only one right solution), and present the solution (a large part of your job as a IA is presenting your work so the client can understand the results).

Putting Disorientation into the Design Process

Jared Spool describes the technique of putting disorientation into the design process - or "hunkering" as one person they studied called it.

Even though each craft was different, the behavior of hunkering was the same:

• They lay out whatever physical pieces they have -- raw materials, sketches, and images they'd collected.
• They work to put things close to where they'd be in their final form, relative to the other pieces.
• Then they step back and ponder it for a while.
• In some cases, they walk around to view it from a different angle, to see what it looked like from another perspective.
• Then they start back up to work.

Hunkering doesn't seem to be the appropriate term here as that implies leaning in and getting to work. The process described above is the opposite motion of stopping work, stepping back and assessing the design.

I used this process frequently as I'm sketching designs and creating wireframes and prototypes. The process is also used within our team by conducting design reviews with the product manager, developer, QA and system architect leads. In a recent project, conducting these reviews allowed us to catch many issues early on that would have been very costly to fix in code.

Bringing Holistic Awareness to Your Design

Joseph Selbie studied design teams and found a correlation between successful web applications and holistic understanding across team members.

The more each team member understood the business goals, the user needs, and the capabilities and limitations of the IT environment—a holistic view—the more successful the project. In contrast, the more each team member was “siloed” into knowing just their piece of the whole, the less successful the project.

The author describes 5 key ways to achieve holistic understanding:

1. All team members conduct at least some user research
2. Team members participate in work and task flow workshops
3. Team members share and discuss information as a team
4. Team members prioritize information as a team
5. Team members design together as a collaborative workshops

I disagree with the last one and would amend it to say Team members review and provide feedback on designs together as a team.

Selbie's company also created a Feature and Activity Matrix for prioritization, which ranks features across technical feasibility, business goals and user need.

No designer is an island

Sarah Nelson of Adaptive Path recommends a collaborative design process to help navigate through office politics and other hidden stakeholder agendas that can kill a design project.

I advocate for a very specific type of collaboration; I call it structured collaboration. It’s not rocket science but it can be a powerful addition to your toolbox. Unlike simply going into a room and working together informally, structured collaboration consists of thoughtfully designed work sessions, using visually-based techniques, physical materials (stickies, paper, pens) and planned activities to move the design process forward. Structured collaboration is loosely based on Participatory Design techniques, where users are directly engaged in the design process. Since these users are typically not designers, games, activities, and other visual tools help them express their ideas in ways designers can interpret. Structured collaboration does not replace other design tools; it simply helps designers better understand and balance the needs of a diverse set of constituents.

Is Good Design Replicable?

Joshua Porter of bokardo.com asks "Is Good Design Replicable?"

I ask because many people seem to think process is the key to good design. For example, on almost every thread of the IxDA mailing list, there is an argument about which design methods are better…are personas better or is genius design better? What method or process should we be doing to get the best possible product? The implicit assumption is that if you perform some particular UX method then you’ll produce consistently better design: the right process = the right product.

So, the obvious question to ask is: Is there evidence that someone following a certain process produces great design every time?

Be sure to check out discussion that follows the article as well as on IxDA Discuss.

Getting Real About Agile Design

Cennydd Bowles promotes Agile in a recent A List Apart article:

For many designers, Agile is already a fact of life (and for those less accustomed, some recommended reading follows at the foot of this article). We are reaching the point where we must either acclimatize or risk being bypassed. The good news is that Agile does allow us to still do the things we hold dear—research, develop a vision, and test and improve our designs—we just need new techniques. Now is the time to get real, and prove design can adapt, if we want to stay relevant in these increasingly unreal times.

The author provides a nice list of recommended reading on Agile. I found the article interesting but not too all that provocative until I went to the discusion and read David Malouf's comments:

Iteration is not a fools foley. It is purposeful and leads to better design. Artistic creativity is an important part of all levels of a design process. It is the core method of exploration of ideas based on the solid and proven belief that the 1st idea is not the best. Evaluative methods suggested in Agile get the current design right, but they do not actually address making sure you are doing the right design (read Sketching User Experience and see Bill Buxton’s and Alan Cooper’s Interaction08 presentations regarding these issues (interaction08.ixda.org). So to me because you don’t really seem to get the importance of real design methods it would be easy to negate their importance towards creating successful products and services in exchange for expediency.