I’m at the UIE 13 conference. It’s day 4 and I’m learning about “gallery pages”. I sat at lunch where the discussion was about why we each decided to attend this conference.

I’m not sure I get a tremendous amount of practical knowledge (except for the Ajax talk). It’s more important for me that I emerge from my cocoon of my work environment and interact with other UI/UX folks and discuss ideas. I think teams can sometimes create echo chambers. I work with a bunch of great creative folks but it’s nice to share and discuss ideas outside that environment.

Some people attend for networking, learning or just to get out of the office. I go to soak up ideas I can take back with me in creative battery form for future use. Now if they weren’t so damn expensive it would be nice

Attending day two of the UIE. Spent the morning in Adaptive Path/ Luke Wroblewski. Both were excellent speakers. A little high level for my taste but overall pretty good stuff. They both provided good support for making a case for design in an organization.

Jared Spool was entertaining as always. I was a bit disappointed with the recycled content.

Jeff Patton’s talk on Agile and UCD was excellent. It’s what I’ve suspected for a while which is; design, iterate, design iterate is better than design and throw over the wall. The challenges for designers is greater than developers since they need to live in the past, the now and the future to do their work effectively. Jeff provided 12 best practices for UX designers to adopt to help transition themselves into an Agile development methodology.

Day one ended at 5:30. A great start to a conference. Learning how to use Ajax as a tool and progressive enhancement to ensure your product degrades gracefully was well worth the time. I may pick up Jeremy’s book today. Tomorrow is a full day of talks. I’m looking forward to Jeff Patton’s UCD/Agile talk.

I’m here at the UIE 13 Conference here in Cambridge MA. Day one is all day sessions. I’ve chosen the Bulletproof Ajax: Designing Interactive and usable Ajax solutions by Jeremy Keith.

Jeremy went over the building blocks of Ajax and some of the history. I’m really enjoying the high level building block discussion. I always find it easier to embrace a new concept if someone explains the “why”. Jeremy has done a great job keeping the technical stuff light while balancing the need to understand the fundamentals. I’ll update later after we put some of the fundamentals into practice. Stay tuned.

Practicing UCD in an Agile development environment can be daunting, frustrating and scary for the traditional user experience designer. After all, we like to design, research, survey, ask questions and create informed designs which get passed to development. UCD naturally fits better in a waterfall methodology.

Here’s the problem: It’s too damn slow. All that work takes time and unless you have great project management who can effectively stack concurrent activities you become the bottleneck. The designer is seen as the obstacle and not the problem solver. Agile development relies on everyone on the team working together in an iterative fashion to complete the work. But wait! what about my research? How can I influence the design if code is being written on day one? How can I survey users? How can I do my job?

You need to change mediums. You need to get closer to your product. You need to transition your skills and you need to get more involved. User’s don’t use your wireframes and photoshop mocks, they use your product. You need to learn the skills necessary to influence change within that product’s interface layer. For webapps you’ll need to bone up on your XHTML/CSS and JavaScript chops. You’ll need to get your hands dirty and work along side your engineers.

It may take some time to gain the skills and the trust to allow you into the codebase for a lot of organizations but that is where you need to be. It’s where the decisions are made it’s where you can have the greatest control it’s where you can influence change.

Since Agile is iterative you maintain the option to make changes during the development cycle. You don’t need to get everything “right” from the start. Let’s face it, we can survey, interview, test and design until we’re blue in the face but we’re not always going to hit a home run. Agile allows you to chip away at the large chunks and create the fine lines later in the cycle. You have the opportunity to test during development and make changes on the fly. It’s faster and more liberating since you are in control of the layer you and your users care most about, the UI.