Wiring for a Better Concept
While I think it is ideal that a project complete has proper user research, an a solid concept before I begin creating wireframes, I have had enough experience to know that it does not always happen that way.
The process of wireframing however, can help a client, project team, and developers realize form a solid concept.
The project I’m working on right now is a great example. Because of time constraints, I was given a very loose, high-level direction in the form of a statement of work (SOW) and told to create wires. As a result, I have to essentially pull the site layout, structure and interactions out of the least attractive portion of my person.
The process goes a little something like this
- I create wires and specifications,
- The team reviews and we all make recommendations for change.
- I then make the changes as the other project members revise and refine the vision and concept for the site we’re building.
- We then all sit down for another round of review/refinement.
While It’s not what I would prefer, I do see allot of good that can come out of doing things this way.
posted by matthewjdoty @ 4/24/2007 03:00:00 PM
2 Comments:
I have just recently been doing functional specifications for website redesigns and various website modules and our company follows a very similar procedure. The trouble I have been finding lately has been the tight timelines which has not been leaving us with an adequate timeline to produce a better product but unfortunately, sometimes you need to accomodate the client and their timeline requests. Since I have started in the HCI program I have been pushing to gather as many requirements before the wireframes even begin so there is not as much re-work that needs to be completed. Unfortunately sometimes the SOW's are so loose in structure that it isn't even worth creating the wireframes until the requirements can be better defined.
I see your issue. It can be really hard to get everyone on board with scheduling for each part of the process. Unfortunately, curcial things user research and user testing get cut. The project that I'm working on now, cut user testing in favor of the review process you described. However, we still spent more time on design than usual.
Needing to schedule all of these things doesn't necesssarily adjust the launch schedule. The project manager has to make sure that there is a good ratio of design time to development time to testing time.
Saying that good design will save you support time in the future, doesn't necessarily help the project manager get product out the door, which is his immediate goal.
The many frustrations of Design vs. Development.
Post a Comment
<< Home