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.