A few months ago I wrote to this list, sort of complaining and sort of asking for advice on whether I should stand my ground on asking for a feature that our test users wanted and the absence of which I felt would seriously degrade the user experience.
This week the product is in beta test... with the feature (view screens that are actual designed renderings of data rather than edit screens with every control disabled) in place. I thought I'd write back to the list first to thank everyone who responded, and second to toss out this little bullet-point list of things I learned/was reminded of during this exercise. 1. Be patient. Development cycles are long and developer whims are transitory. 2. Design the product you want to see produced. Gather data to support your design choices, and design to those data. If the data are behind you, your life is easier. 3. Involve people early and often, preferably in the same room as the developers. (Probably the oldest lesson in the UX book, and one I teach my students. Turned out to be highly relevant here.) When the developers get an earful from people who are not you, it makes you look like the most reasonable person in the conversation. 4. Be that "most reasonable" person. In this design process I've compromised on dozens of points that the developers wanted changed, while gently advocating for things I felt would have significant negative impact on the user experience. 5. Reasonable people keep lists. When we deviate from the product I want (see point 2) I keep a record of it. I make sure QA has a copy of the original design doc and we design test cases for the application based on that doc. When there are variances we can file them as defects, as design changes, or as features for the next release. Just because I didn't get everything I wanted in this first release doesn't mean I've compromised away my design vision. 6. Development never goes as fast as everyone wants, and idle developers are often willing to do things they thought they didn't have time to do. In this particular case, the view screens were largely implemented during a cycle that had the UI developer waiting on the back-end developer to catch up. He had a couple free days, and a doc that described the feature. And he had heard the intended users asking for the feature (see point 3). So he implemented things. And once they were implemented they were much easier to integrate into the app during the next down cycle. Best regards, --Alan ________________________________________________________________ Welcome to the Interaction Design Association (IxDA)! To post to this list ....... [email protected] Unsubscribe ................ http://www.ixda.org/unsubscribe List Guidelines ............ http://www.ixda.org/guidelines List Help .................. http://www.ixda.org/help
