At 5:24 PM -0400 10/20/07, Christopher Fahey wrote: >Do you (or your employers) usually create the functional spec >*before* the UI spec? I suppose this is a pretty traditional way of >doing things in big organizations, but I thought we were generally >moving away from that model. Are you comfortable with that approach?
BF: I always create a functional spec before a UI spec. These days my functional specs are often informal: perhaps a list of bullet points or a general description of what the end result is supposed to be like. But I feel it's essential to get an adequate sense of the range and scope of the job I'm being asked to do. >... (for example, does the system >use a session or a cookie to remember a user preference? which >database does the data come from?)... BF: To me, these do not belong in a a functional spec. A functional spec would say "we have to let users set [these] preferences..." and "there must be a way to store and retrieve [this] data...". *how* the preferences and data are stored and retrieved is up to the engineers to design. How the preferences and data are presented to the user is up to me to design. We both have essential roles in delivering the desired functionality to the user. Both of us must be successful for the user to have a satisfactory experience. >I think of this in architectural terms, where the architect designs >where the people go and how they experience the space, but the >engineers decide what kind of steel beams to use, where the rivets >go, how to route the water pipes and the electrical wiring, etc. BF: I, too, use the building-architecture analogy, and I equate myself in this analogy with the architect. A building architect always has to ask the client what kind of building to design and what are its key characteristics. What is its purpose, what is the budget, how many people, cars, etc. does it have to hold, etc. I suggest that the list of answers to these questions comprises the first (and sometimes final) draft of what I'd call a functional spec. >(I am not demeaning the work of engineers here. Engineers with the >right skills can certainly build, or help build, great user >experience specs. And, of course, the process of figuring out how to >effectively build and deliver the user experience as specified in the >UI spec is not trivial, requiring great skill, creativity, and >ingenuity.) BF: One key thing I've learned in my career is that the only thing a user ends up seeing or interacting with is what the engineers build. Therefore I only have influence, not control over the outcome. I can maximize my influence by working closely *with* the engineers to: (a) design something they can build (within the constraints of budget, schedule, legacy issues, etc.), and (b) getting them excited about how wonderful the results can be. >As UI designers, sometimes we have no choice but to follow a tech >spec. Many product managers begin with functional specs and then >bring on the UI team to "make it user friendly". BF: Whenever I've encountered this, the people who have worked on the project before I was brought on board have gone way beyond what belongs in a functional spec, or marketing requirements document, etc., and instead have already created a design (even if they're not calling it that). When in the past I've found myself presented with such a situation I have gone to the decision maker(s) and said, diplomatically and tactfully, you have two choices: constrain me to simply making minor improvements to the "design" you've presented me with, or give me the freedom to create the design that this product really needs. You're paying me, it's your call. >...If there is >a single thing that best exemplifies "user centered design", it is >the concept that the "UI is the spec" [1]. BF: At least on the face of it I can't agree with this, although maybe you didn't mean it the way I read it. To me user centered design starts with a deep knowledge of, sensitivity to and commitment to the users. Any design, engineering, testing, marketing, packaging, sales, distribution, support, etc. must flow from that for a product to be "user" centered. And as you may guess from my list, I feel that the user "experience" is affected by the full spectrum of organizational specialties. A good UI design is certainly a key contributor to a good user experience, but can easily be undermined by poor performance in other parts of the organization. >[1] http://www.37signals.com/svn/archives/001050.php BF: I read this, and it doesn't sound at all like my experience. I don't doubt that the writer(s) are telling the truth as it has been for them, but for me I have typically found functional specs to be empowering and unifying. -- ====================================================================== Bill Fernandez * User Interface Architect * Bill Fernandez Design (505) 346-3080 * bf_list1 AT billfernandez DOT com * http://billfernandez.com ====================================================================== ________________________________________________________________ Welcome to the Interaction Design Association (IxDA)! To post to this list ....... [EMAIL PROTECTED] Unsubscribe ................ http://gamma.ixda.org/unsubscribe List Guidelines ............ http://gamma.ixda.org/guidelines List Help .................. http://gamma.ixda.org/help
