--- In houstonhfes@yahoogroups.com, "alliwalk1980" <alliwalk19@...> wrote:
> In my current role, I'm in a new-to-usability/HF environment,
> also in-house, and it hasn't been uncommon to get 1-2 days for a
> review and recommendations. As a result, the "documentation"
> has been all over the place.
>
> I have only worked in-house, and haven't had the opportunity or need
> to extensively use wireframes, but do occasionally such as when
> recommending a new UI. I've learned through the grapevine that
> creating wireframes to deliver functional specifications is
> a standard practice in a lot of places for UX teams.

Wireframes in a specification document are a pretty common means of
illustrating how something should appear when communicating with teams
at the low to mid fidelity levels. But, they aren't the only means and
aren't appropriate for all situations.

But, it really depends on the situation. There are some outstanding
designers who would be extremely competitive if they wanted to leave
their current company and deliver few, *if any*, design specs with
wireframes since they work in a highly agile environment.

I think that being able to show samples of work and explain how you've
worked would be sufficient. If I were looking to fill a position, I'd
give high marks to someone who was able to adapt how they work and
communicate to match the situation.

For example, for a quick consultation on a dialog with a local
developer, a quick sketch on a whiteboard would be more appropriate
than a formal specification with annotated wireframes. If the
developer isn't local, but I've worked with them well before, a
scanned sketch or a quick wireframe attached to an email may be
sufficient. If the developer isn't local and I've never worked with
them before, a short specification document with wireframe might be
the best solution.

So, I'll give the classic consultant answer: it depends. :-)

Out of curiosity, where are you now?

Ron