If you’re like me, over the last few weeks you attended a few holiday parties. As online invitation sites start to replace traditional mail invites, I thought I’d take a look at a local start-up mypunchpowl.com.

Over the next several posts I’ll provide my opinions on the first time experience. From first engagement to sending out invites.

Mypunchbowl.com Home Page

Call to action

The homepage should have one focus which is draw the user into some kind of activity. Most analytics show this is where sites lose the majority of their traffic. It is crucial to engage the user with a label that has value to them. This home page has “Create free account” as the call to action. If you’re like me, that sounds like you’ve just tasked me with some work. I read that and say: “great, I’ll need to type in a bunch of fields on a form before I start.”

Recommendation:
Instead the label should read “Start planning your event” or “Send online invitations now”. Definitely something to test but it needs to express value to the user, not the site or the system.

Below the fold

The rest of the page has a lot of information. There are testimonials, planning advice, birthday party advice, learn more links, location maps, reasons to celebrate, send e-cards, and a message from the CEO. Some of these may be important when educating the return user but just server to slow the first time experience with visual noise.

Recommendation:
Reduce the total amount of information below the call to action. Focus only on what is going to convince the user to respond to the call to action.

It’s important to know whether a user is a new user or return user. The value proposition is different for them. The use of cookies and dynamic homepages are a great way to segment this traffic.

Why do I always feel like I’m fumbling around in the dark when it comes to Javascript debugging? Firebug and other tools have been making it a little easier but when you get an error like this:

It’s a little ridiculous don’t you think? I mean really, does IE think I have more than 130 million lines of JavaScript?

As a User Experience designer I’m responsible for providing design specifications to engineers. Sometimes the design problems are easy but more often they are complex and difficult to visualize. As designers we’ve latched onto some tools to help us communicate our ideas to our stakeholders. We use wireframes, mock-ups, omnigraffle/visio UML diagrams, comics, Powerpoint and a few other techniques to convey what we mean.

Here’s the problem: If you’re using a different tool, and designing without input from users then you are doomed to fail, or at least have a major communication breakdown eventually.

Have you ever read a book and watched a movie made from that book? Remember back to how different it was in your mind than how it was interpreted on screen. There are hundreds of pages with fantastic descriptions and still the interpretation can be so far off from person to person. That’s why it’s critical to get ideas into a working state as quickly as possible.

It allows the user to soak in the idea and start concentrating on the details. What if it did this? How does that work? Where do we collect this data? All important questions to be answered early. The user can’t start asking those questions unless they can interact with the interface, play with things and exploring. That’s where they prototype comes in.

Learn to design quickly, allow for full uninhibited feedback then iterate. That will give you the best chance at a successful, usable product.

At work I was assigned the task of evaluating the major libraries and selecting one for our web applications. I spent some time reviewing the major players and decided to switch from script.aculo.us to Jquery for the following reasons:

1. CSS syntax - Jquery uses the same syntax as CSS to identify elements within the DOM

2. Unobtrusiveness - Because the function identifies the object using the css selectors, there is no need to add any JavaScript in the markup.

3. Microsoft - It seems more and more apparent that Microsoft is hooking their cart to Jquery. Since we’re a .Net shop it was an easier sell than the others.

4. Support - There is a thriving community with examples, tutorials and forums for answering questions.

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.

I’m feeling a little left out of the iphone, ipod, idog phenomenon going on. So I decided to take a look at some common items and see if I can add “i” to it and see how they would look/interact. The first design is a simple thermostat. I’ll take a look at it’s UI and basic functions and see if I can make it into an ithermostat. The first time experience is below. I’ll create some of the additional screens later. Let me know what you think.

Default Interface

Unlocked