Not exactly.

In my last position, our documentation method to define the
functionality was a written document that went to the development
team. 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.

I guess I'm worried about not remaining competitive. Does this make sense?



--- In houstonhfes@yahoogroups.com, "Ron Vutpakdi" <vutpakdi@...> wrote:
>
> --- In houstonhfes@yahoogroups.com, "alliwalk1980" <alliwalk19@> wrote:
> >
> > Ron, Are you documenting hardware products or screen-based
> > interfaces?
>
> Screen based interfaces, which is part of the reason that PDF tends to
> work fairly well, at least in my context.
>
> >
> > I'm curious about this topic because it seems like the emphasis
> > should be on the evaluation, design or problem solving, with
> > less emphasis on any specific type of documentation only.
> > Shouldn't the documentation should fit the communication need?
>
> I agree entirely. The amount of detail and type of documentation
> depends entirely on the situation. For really small things or things
> that have to be delivered in a hurry, I deliver very little
> "documentation" if possible.
>
> I'm curious as to what the situation is that lead you to ask? Is
> someone pushing a certain type of documentation on you?
>
> Ron
>