One of the outstanding sessions I attended was What's the secret Formula? (PNL14). The panelists were (in alphabetical order):

• Dan Harrelson - Senior Technologist, Adaptive Path LLC
• Daniel Makoski - Microsoft Corporation
• Jensen Harris - Principal Group Program Manager, Microsoft Corporation
• Mike Schroepfer - Vice President of Engineering, Mozilla Corporation

The panel was moderated by Nishant Kothary who is a user experience evangelist at Microsoft. The list of panelists as well as the subtitle of the panel - A panel on designing stuff that rocks - promised a pretty user experience (UX) centric discussion. Fortunately they kept this implied promise and I found myself agreeing with most of the points made during the discussion. The following list is incomplete and by no means a transcript (meaning it is based on what was said during the panel discussion but the details are my take on the issues discussed by the panelists though you will notice quite a bit of overlap when watching the recording):

• The ownership of UX must be shared by the whole product group
  Sure, there are UX engineers who are the real experts and program managers usually care about UX as well. However, if developers do not care about UX when implementing features and testers do not look at the software under test beyond the specification the end result will most likely be suboptimal from a UX standpoint. To make things even worse the UX bugs that shouldn't have been there in there first place often have a lower priority than certain types of functional issues and the chance of getting the UX bugs fixed continually decreases as the ship date comes closer. That said there must be an understanding in a product team throughout the different roles that the idea of getting it right the first time applies to UX as well and that it's not enough for a feature to work in order to be of high quality as soon as a UI is involved.
• There has to be one vision for the product
  This is basically the limit to how much any individual can determine the UX and design for any given part of the software. Though the ownership and thus the responsibility for UX is shared the end result must be consistent in order to achieve a high overall quality. This suggests that there should be one vision and one set of design principles that everyone on the team believes in and - since there will be disagreements along the way - that a very small number of people should be in charge of making final calls on any decision if necessary so that at the end of the day the product looks like it was designed by one person although a large number of people contributed to make it happen.
• Share user feedback with the developers
  This goes for both negative and positive feedback. Negative feedback is important so developers (as well as testers and program managers) understand that some users will notice for example when UI elements are one pixel off even though the user may not be able to accurately express what the problem is (the user may just report that the affected UI "looks wrong"). Even more reason to take these issues seriously. Positive feedback is equally important. Jensen mentioned the example of the UI font for MS Office being changed and developers not understanding why since the new font wasn't that much different (at least from their point of view). But users did notice a difference (and again they might just say "I don't know what you did but it looks better") and sharing this feedback helps people in the technical roles to get a different perspective and be more open in the future.
• Get continuous user feedback
  Mike talked about how Mozilla has volunteers around the world testing the latest Firefox build every day and how it allows them to try new things and quickly get feedback. Now, obviously that doesn't work for every kind of software project. But getting user feedback throughout the development cycle to validate that you are on track and that changes and new features actually meet the needs of the customer leads to better products. For some projects this might be limited to beta releases other projects might have to resort to closed user groups under NDA but getting that feedback in early makes a difference so it's important to figure out which way of gathering feedback and how frequently works best for your project.
• We are not the customer
  I thought about typing this one in all caps but that would be rude. This is nevertheless a very important one. No matter if you are a developer, a program manager, a tester, a product manager, a designer or a user experience engineer (though UX engineers are usually very aware of this), no matter if you work for a global player or a startup, no matter if you work on a closed source or an open source project, you are not the customer! We use and think about software differently than everybody else and I'd say this is a pretty general rule with very, very few exceptions (and I can't even think of one right now - I just assume that there is one... there is always one). If you think about Microsoft Office it is probably obvious that the people who work on the product have a completely different point of view than the majority of end users. But even here in Microsoft's Developer Division this is true. Now you might think "you guys are developers, your customers are developers, what's the problem"? While we create IDEs, frameworks and controls for developers the majority of those developers create applications for end users who are not developers. That said, it is very important to figure out what the customers want - and it is a really good idea to have UX experts for that since customers often can't tell what exactly they need - and not to speculate what they want or even worse assume that they want what you want.
• The first step of designing is a low-fidelity prototype
  Let's work our way back to low-fidelity. It's tempting to do UI prototyping in a designer like Expression Blend or in Visual Studio. Those are the tools we know and they get the job done. But for prototyping they can actually be dangerous for a couple of reasons. For example they constrain you to whatever they are able to represent and they generate source code (if there is anyone out there who has never seen source labeled as "prototype" mysteriously becoming "product" code please leave a comment). The next step back is a graphics application like Expression Design or Photoshop but not everybody involved in the prototyping process knows how to use them which finally brings us to low-fidelity which can be done by anyone (even end users like your parents) at any time and is usually primitive enough for not having people get too attached to the prototype. I'm talking about any non-electronic method of drawing on a surface. Whiteboards, flip charts or simply a pen and a napkin if nothing else is available.

Again these are just a couple of points I thought were most noteworthy (which is of course completely subjective) and I really recommend watching the recording of the panel.

This posting is provided "AS IS" with no warranties, and confers no rights.