Here are my notes from the panel today. I didn’t get all of the speakers’ names so I’ll leave them out for now.  

Besides RIAs, what other pressures have forced you to change your documentation style?

• Do less. Trying to outline a design by talking through it with a developer can be challenging.
• Waterfall – writing everything down in a fancy book didn’t work very well. Now we’re more interative and collaborative, more focused on creating quick and easy things and advance the conversation.
• Doing a lot more redesign work than fresh, clean design work. Don’t create brand new documents because artifacts are already there.  Using things like databases as documentation.

How do we figure out the tool we need for a particular audience?

• Do you think the biggest challenge we face is entrenched standards, which are preventing us from developing new techniques?
• Moving towards communities of practice, we can ask if we’re still solving the same problems, and then we can determine if we’re using the right tools

How does context impact your documentation?

• Consulting company, brought in to solve a particular problem. People do want things like sitemaps, which isn’t something we usually do. With every project there are new documentation challenges. We can tweak the process to accommodate that.
• In terms of methodologies, agile is better for refining than defining. Agile lacks the component of coming up with a vision for a project. You can lose sight of where you’re going in the long run.
• When we spend a lot of time on documentation, we get attached to it, and that can be problematic too. The good thing about agile, is that you can learn things halfway through and then go back and change things or change direction.

What kind of specific changes have your documents gone through since you entered the UX world?

• Documentation is usually seen as overhead. Doing live collaborative things can make that overhead less and less. Also, looking for tools and techniques to reduce documentation is one of the biggest ways it’s changed. We think more about how the documents will be used, disassembled, and metabolized into the organization. More flexible now.
• Not producing so many formal artifacts as much as we’re trying to get people into the same room to collaborate, work with sticky notes, etc. People see the collaborative work and they want to be a part of it
• Used to use the same kinds of documentation for every project. Now I try to find new ways for each project, so that we can get to a prototype environment more quickly. That matters a lot more now, and you don’t want to waste a lot of time with paper.

What about clients and documentation?

• Work with clients now in a completely new way. Before it was one or two meetings, and then I come back with a solution. Now I want the clients to be a part of the wireframing process because it helps to get feedback from all of the different parts of the business.
• We are becoming more facilitators that we are experts at coming up with specific deliverables. It’s more important to get everyone around the table.
• When people are dispersed around the world, there aren’t good tools to get everyone to collaborate. We need a virtual sticky note application.
• Facilitator is the role we’re now playing in a lot of organizations, because what seems like a design issue is really a business or organizational issue. The way the business talks within itself. The deliverables advance, step by step, the conversation between business units.

Are any deliverable types extinct?

• It’s been a long time since I did a full site map.
• We do have a full site map but it doesn’t look the same as older site maps, because not everything connects together
• There’s so much content that it doesn’t make sense to map it all out
• I stopped using wireframes because I can create high fidelity visual prototype quickly in Photoshop. Likewise there are people on our team who can create functional prototypes quickly. We iterate through a functional prototype and we then hand it off to the development team and the UI shouldn’t change – that’s the ideal.
• Wireframing tends to be an artifact of a different process. “This kind of stuff belongs here” is the question you’re trying to answer. Focusing on structure and trying to get buyoff. In an agile world, the buyoff isn’t really there anymore.
• There’s a trend in doing hi-fi prototypes right off the bat and that worries me from a usability testing perspective. I’m a big fan of low-fi prototypes. A lot of things get hidden if you go to high fidelity first.
• One of the flaws in agile is that it doesn’t leave room for testing in the design process.
• We adjust the fidelity of the prototype based on the intent. We use them to explore ideas, provide clarification, communication, persuasion, and inspiration. We adjust the fidelity depending on the purpose. Sometimes if you do a test with a black and white prototype, you may not see the same behavior as if you did the test with the bright green, bold button.
• Sometimes the client makes a difference. We did a project with orthopedic surgeons, and they didn’t react well to a sketchy styled wireframe.

UX Net Event in DC called Resume Roundup. We talked about the hiring process and then looked at people’s resumes. We realized it was more about the portfolio. What do you look for in a portfolio?

• Empathy – ability to present their work in a human sense. Besides good design, the ability to understand design as a story and its utility in human terms.
• It depends. Looking for someone clever and evidence of how they’ve solved things creatively. How they understand their stuff.
• I wouldn’t hire someone based on their portfolio because it’s hypocritical – my recent work is sketchy and random. I would be looking for the ability of people to explain the problem, use documentation to get through the process and communicate ideas. It’s about whether or not it works.
• Passion, empathy, curiosity. Interested in the process – what was the problem, what happened along the way. Visual design skills because these are visual communication tools.
• It can be pictures and stories – photos of sticky notes.

What about longer projects in corporate or government where the project cycles are longer?

• Patterns. Ultimately if you can establish ways in which you do things or particular interactions work, you can create variations through parameters.
• Beyond reusable elements, the research that went into the project and personas that were generated, which are separate from the interface – keeping them separate is helpful in keeping to tell the story.
• Stories are part of the process as projects go on. They get lost – people forget why decision were made. Need to come up with ways to maintain stories to keep them alive so we maintain context.
• We don’t do a good job of documenting design decisions, and we need to do that. Need to develop documents about reason and rationale.

What is the best tool or approach used in early design sessions with stakeholders? What successes or failures have you had?

• Whiteboard for requirements gathering. Then we come back with a photo of that whiteboard and move on from there.
• If you remember that you have to look at users, competition, and yourself and can bring that understanding to a group, you can facilitate the discussion in a meaningful way.
• Pen and paper can get you a long way in facilitating discussions early on. Can be in the hands of clients and stakeholders.
• Sticky notes and prototypes (paper or HTML).

This entry was posted on Tuesday, August 14th, 2007 at 4:06 pm and is filed under Usability, UX Week 2007. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.