TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
I have no idea if my experience is shared by anyone else, but I'll provide
it to give you one point of view.
-I originally started UI design because many of the programmers working on
the project did not have English their native language, and they had a
difficult time understanding the functional specs. I continued with it
because I'm pretty good at design (not great, but pretty good), and have a
strong ability to interact with both SME's and programmers. To me it's just
plain fun, it gives me a leg up on what the end-user documentation will need
to contain.
-I have no formal training in UI design, but took numerous courses in page
layout, advertising layout and design while getting my degree in Mass
Communications (long before the internet and before any design work could be
done on a PC). Understanding basics of visual design is key, and as many
posters have pointed out recently, the medium makes a difference in
comprehension levels, so after getting the basics, start researching how
comprehension is affected by display in the electronic world.
-I have used several references as a checklist, and participated in some
excellent workshops at TECH/COMM 99. Look for works by E. Tufte, Alan
Cooper, and Aaron Marcus for starters.
-The percentage of time devoted to UI design is dependent on the stage of
the project. I spend a significant amount of time with product managers and
analysts reviewing their functional specifications. I'm in the midst of
about 75% design time at the moment because we're starting development on
the next phase of a major application redesign (moving from windows to
browser).
-The point at which I start participating is very dependent on the structure
of the project team. Currently, we attempt to finish UI design when product
managers deliver functional specs to developers (or very soon after). Some
of our developers create their own UI when they do their technical
specifications, but a very aggressive delivery schedule allowed me the
opportunity to do more UI by taking that burden from the development leads.
I've also worked in situations where I was writing the specs at the same
time I was designing the UI, taking direction from product managers.
-If you are going to serve as a "liaison" between product management/SME
types and developers, my primary advice is to be patient and to try to
understand the mindset of both sides. I've had developers assist me with
the finer points of designing in HTML and VB and what the development tools
can and can't do. And I've had product managers provide outstanding insight
into how our users do their jobs. Successful UI is very much a team effort
that respects both kinds of input, and TW's are often in the best position
in terms of skill and talent to facilitate it. However, you may have to
"re-educate" management and developers about your qualifications to do this,
and how much it can add to the process.
As many before me have noted, we don't often have the same amount of
influence or respect as developers, but eventually, if you deliver quality
in a timely fashion, you can garner that influence and use it to improve the
product.
-On a philosophical note, I consider the goal of good UI to make a software
product as intuitive and easy-to-use as possible, and ultimately that means
very little documentation (in the traditional manual/help file sense) is
required. But Technical Communicators are the ones most responsible for
make a product comprehensible to end users, so it should be natural part of
the job, and apparently is evolving that way. At least I hope so :)
