paper & pencil

Thoughts on UX & Agile Integration

Came across Integrated Usability in Agile teams from the trenches via the Agile Experience Design group on Linked In and it contains some great tips for UX folk working in Agile teams for the first time.

I've been working in an Agile-ish shop for just about a year and I love it, having been seeking out opportunites to do so for a couple years prior to that. To me, the tenets of Agile made perfect sense to me as change is inevitable and Agile is about embracing and dealing with change rather than fighting against it. 

To add to Robin Dymond's list, here are some additional items that have helped me be Agile in my IxD work:

• I've found being both the Product Owner and the IxD on projects helps me organize my IxD work as I have deep knowledge of what is most important to my customers and ensures I'm working from business priorities.
• Also, it helps to have quick & easy access to all the people I service - business stakeholders, customers, and the development team. One of many reasons I have always preferred working for smaller companies.
  
  
• Having breathing room between major development projects to take care of incremental improvements to existing applications allows me to increase my understanding of the business needs and the needs of the people using the software. This knowledge then feeds into the major development projects. During the gap between major projects I can also take time to develop conceptual models and high level interaction models so that I'm not as rushed when sprint 0 of a project hits. 
  
  
• Using software (VersionOne) to organize the enormous backlog of requests across numerous software applications.
  
  
• Lastly, working with a CTO that evangelizes both Agile and UX and has mentored me on taking a more systems engineering approach to my IxD work has been a very large part of the success I've had with Agile.

The Marshmallow Challenge

Tom Wujec demonstrates the power of prototyping through the Marshmallow Challenge. Kindergartners fared better than recent business school graduates... which is funny & scary.

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.