When to Wire
OK so I'm getting a little frustrated with a project that is asking me to produce wires without providing any clear direction as to what the requirements are. I'm also getting the impression that this is not the first time this type of thing has been done at my company.I've always done wires when we had a good idea what the user, tech and functional requirements were. However I'm curious to see if any of you have a different idea.
Let me know
posted by matthewjdoty @ 5/01/2007 04:49:00 PM
2 Comments:
Personally, when frustrated by a limitation like this, I tend to turn the table and put the onus back on the stakeholder. By this I mean, give them a wireframe that expresses exactly what you've been given so far.
Obviously, that would be nearly empty. But, if you bring that back and say "this is what can be produced based on the information you've given so far", it starts to make the limitations more concrete. They can then visualize how little they have and start to fill in the gaps.
"No, I want THIS over HERE too."
Naturally, situations change, but a little humility can go a long way.
"Well, this is what we've come up with so far, but it's not good enough. I can do more, but I'd rather have you show me the direction you want this site to go."
I have actually designed wireframes once where I had a clear understanding of what the requirements are, usually it is some background knowledge of what the application is/might be.
Look at your situation from a different perspective. Fuzzy requirements give you a greater creative freedom. Unclear sense of direction from whomever you are designing for usually means that they don't really know exactly what it is that they want and might be open to some ballpark suggestions from you in terms of layout or interactivity.
In a situation like this, your wireframes may be expected to be used as a conversation starter instead of a clear spec for the development.
Post a Comment
<< Home