Best Programmers

  • Subscribe to our RSS feed.
  • Twitter
  • StumbleUpon
  • Reddit
  • Facebook
  • Digg

Tuesday, 28 January 2003

Posted on 15:58 by Unknown

User Manual for Building Your Own Plane



The manual is actually an image. Check it out and let me know if you liked it! ->Build Your Own Plane<-
Read More
Posted in | No comments

Monday, 27 January 2003

Posted on 12:38 by Unknown

How to save your client $1600 per task per year through Usability Testing



I have noticed quite a few mails asking how to conduct a usability test or how to interpret the results of a test. I thought it'd be a good idea to give you all a set of documents that resulted out of a usability test. I have changed the actual information for reasons of confidentiality, but it should give you a good insight of what a usability test is all about.

What is a usability test?



It is testing your product on actual users to find out 1)If your product is easy to use 2)If the navigation is user-friendly 3)Get 'feature' ideas to improve your product 4)If users were able to perform their tasks efficiently, and within acceptable time limits, and 5)To measure the 'joy of use'

To me, the most important metric is the 'task-time': When a user is taking longer to perform a particular task, that means something's wrong; could be the navigation or it could be the color scheme you chose or a combination of such common mistakes. Why is task-time important? If you can reduce the task-time of a particular task by say 30 seconds, and your product is used by a 100 strong company; and this task is a daily task, performed at least once... you have saved your client from a productivity loss of: 50 minutes per day. OR slightly over 4 hours per week. Assuming all 100 are paid $10 per hour. We are looking at savings of $40 per week PER TASK. And if your client works for 40 weeks in a year, you are looking at $1600 savings only on a simple task that users perform on your product. I may be indulging in some wishful thinking here, and maybe my math is terrible, but whichever way you look at it, usability does save money. There are other reasons why usability testing should be adopted in your development process, but I choose not to discuss them now. Shall write a separate piece on that later.

What is the Think Aloud method?



1)Identify actual/representative users (five users is my advice)

2)Make a list of tasks (example: Search and find the currency of Honolulu)

3)Choose a location where your users are comfortable; a location that reflects their working environment.

4)Notify users about your usability test. Send invites. Follow it up with a phone call or e-mail and confirm their participation.

5)Explain that they are not being tested, the product is being tested. Give them the tasks. Ask them to keep thinking aloud (say it as soon as a thought enters your mind!). And YOU shut-up!

6)Observe users. Their expressions. Those small clicks of the tongue indicating frustration. Those non-verbal hints (scratching one's scalp rapidly, in one short burst OR those little shrugs indicating helplessness) NOTE IT DOWN. ALL OF IT. Tell them they can abort a task anytime they want to.

7)Use a Dictaphone to record comments. Note down the time per task. (check with them if you can tape them)

8)Take the satisfaction survey (to figure out the 'joy of use' of the lack of it thereof)

9)Thank them and give them a nice gift (some people give cash, but I give dinner coupons)

10)Repeat steps 1 to 9 for all five users.

11)Sleep on it. Compile a report next day.

Usability Testing DOs



*Smile. Be a friend. Don't be this geeky dick. No one likes them.

*Observe. I can't stress its importance enough. You got to be a keen observer. You have to record what was 'unsaid' too my friend.

*Listen: Talk less. Do more. Give non-verbal cues to the user like nodding the head or through 'uh-uh?' 'Oh yes.' 'and?' 'hmmmhmmm?' You know.

Usability Testing DONTs



#Don't help the user perform the task. We are here to find out how 'intuitive' the product is.

#Don't crowd on the user. Give him/her the privacy that is needed.

#Don't interrupt when the user it talking to you. Your words can wait.

#Don't get too personal.

[These are by no means comprehensive. I am just jotting down whatever came to my mind. If you have some more, do contribute. Mail me to learn how]

Usability testing: Sample reports



->Download Sample Documents<-<

The zipped file contains:

1)Participation Questionnaire

2)Task-time report

3)Satisfaction survey

4)Task-sheet example

->Download Sample Documents<-

Disclaimer: Most of the surveys were based on the STC usability kit. I am still working on customizing these documents for my use. So use your discretion.

Read More
Posted in | No comments

Friday, 24 January 2003

Posted on 06:41 by Unknown

Job posting: Thanks to the TWIN List



I haven't linked the e-mail ids and instead of '@' I have used 'at' this is to prevent the spam-bots from picking up the e-mail ids. Don't want the Quinnox guys ending up with great offers for penis enlargement - suman

> Quinnox urgently requires Communicators for its Mumbai operations.Quinnox, a global Business Solutions group headquartered in the US, is focused on providing high-technology solutions and services to world-wide clients in the areas of e-Business, ERP, Enterprise Value Chain Solutions and Outsourcing. Our services include world-class software development, consulting, systems implementation, integration and outsourcing.

> Our unique strength is our long-term relationship with customers, who have benefited from our end-to-end IT solutions. We stand differentiated by our emphasis on a service-management culture of speed & flexibility, trust & integrity.

> Since its inception in 1996, Quinnox has successfully executed over 400 software consulting, development and implementation projects in over 38

> countries. Our operations are executed from 9 International offices and 3 world-class Global Solution Centers.

For more information, visit http://www.quinnox.com



TECHNICAL EDITOR/WRITER

Job Description:

> - Editing/writing of business proposals, software project document deliverables including system 'Help', white papers, quality-related documents - both software and other function-related.

> - Creating templates for various categories of technical documents.Providing in-house training in technical documentation.

> Qualifications: Graduate/Post-graduate with an added qualification in Journalism/Mass Communications/Technical Documentation; Very good communication and interpersonal skills; adequate experience with word-processing/document designing/publishing tools. Five years of related work experience in the IT industry.

> E-mail your resume to: career(at)quinnox.com by 31st January 2003.

>

> ***************************************************************

> Quinnox Consultancy Services Ltd.

> (Formerly iS3C Consultancy Services Ltd.)

> 170, SDF VI, SEEPZ, Andheri(E)

> Mumbai 400 096, INDIA.

> Tel: +91 22 2829 0100, Extn.253

> Cell:+91 9820093589

> Fax: +91 22 2829 1131

> E-mail: virend(at)quinnox.com

> www.quinnox.com

Read More
Posted in | No comments

Thursday, 23 January 2003

Posted on 07:34 by Unknown

Role of a Technical Writer: Mail to the TWIN List



Let's look at it the other way around. There are still a lot of organizations that do not have a documentation team. It is done as an 'add on' by the developers themselves. When you have tools like Robohelp, AuthorIT or those little beauties that abound (for free at times), that help you generate .hlp or .chm or xhtml... developers find 'presenting' information easier. So I had one of these developer friends remarking 'what's the big deal man? If I want to I can learn Robohelp in a week's time and I can become a tech writer.' I don't want to go on about how untrue his statement is. While the temptation to be a jack of all trades is overwhelming, please be warned that, writing as a skill, evolves over years. Writers tell stories. Applying this to our profession, we tell stories too, on how a product works, or how to troubleshoot something. It is all a story. Forget developers, if being good in a language is a major criterion for becoming a writer, every english professor in the world should have churned out best sellers. No sir. No m'am. Writers write. And it is not easy. Writing well? Oh, that's an entirely different story. So the moral is, stick to one profession, focus, and mature, instead of talking about how one can do a million things. Yes one can. But what counts is 'What are you best at?'.

Now, talking about QA. In India most companies have a QA cell: Objective: Get those damn certifications. CMM4, 5, six-sigma da da da. Very few are sincere in 'following' the processes or having a process-driven organization. I have seen many companies get cmm4 now and cmm5 6 months later and something else a year later. Excuse me! My friend working in Prudential told me that they have set up the processes for CMM2, and have been following them for the past few months, but they are very nervous; 'will we get CMM2?'

So if you have any dreams of changing the world by being a part of QA, waky-waky, it could be all a sham pardner. So stick to writing. Focus. If there's any profession under the sun that takes decades to master, it is writing. most of us here have been here for what? a few years? We'll talk about taking over other domains, after we conquer our own. And on a final note, please learn to discern this: Content from presentation. I see a million mails on FM and CHM, but not so many on the craft itself, writing that is. What gives?
Read More
Posted in | No comments

Wednesday, 22 January 2003

Posted on 01:46 by Unknown
Hi

A first post here ... check this link which carries an interesting write about the contribution of Technical Writing to Apple Computers / Mac

http://library.stanford.edu/mac/writing.html



Read More
Posted in | No comments

Monday, 20 January 2003

Posted on 21:01 by Unknown

Writing Web Help



I have been working on online help for the past year. When it started I was overawed at the size of the product and the documentation we had to prepare. But I learnt a lot on my way. Here are some tips that you might find useful

  1. Users don't read text on browsers. They scan. So highlight keywords, action words ('do this, do that')
  2. Cut down 50% of what you have written. Brevity can't be stressed enough. Please remember that reading speed on a computer screen decreases by about 20-25%
  3. Write in active voice
  4. Write 'action first. Effect later' (example: Click 'OK'. To go to the homepage. AND NOT 'To go to the homepage click 'OK')
  5. Write to a singular audience: Imagine that the user is sitting infront of you and you're telling him/her how to perform a task. People don't use your software in groups
  6. Iterative document design:Build a prototype. Test in on users. Build. Test. Build Test... of what value your documenation is if it doesn't help me in performing tasks? I can't take it to bed to read it like a novel!
Read More
Posted in | No comments

Saturday, 18 January 2003

Posted on 14:39 by Unknown

Calling all Graphic Designers



So you think you got style and spunk. You think your design and creativity kicks butt? Oh yea, I am lookin for ya ol' boy. I want you to design a logo for Technical writers of India weblog. Are you upto it? If yes, Get on it now and mail me your design. Shall announce the closing dates very soon.

What if my design is accepted?



Well, you can share the power and glory of tw-india blog. Your name shall be etched on the sands of time, along with acknowledgement right here on tw-india blog.

Let me know!
Read More
Posted in | No comments
Newer Posts Older Posts Home
Subscribe to: Posts (Atom)

Popular Posts

  • Use it before you write it.
    From the Nikkor ED 80-400mm f/4.5-5.6D VR Review (emphasis is mine): [quote] Here's the warning in the manual : "When the camera is...
  • Participative Help Design
    Participative Help Design I used a weblog script to create online help for -uh- using weblogs. I used a plugin to pull help topics as alphab...
  • 3rd STC Chennai Meet this sunday.
    3rd STC Chennai Knowledge Sharing Session this sunday, April 4th. This month's knowledge sharing session will be held this coming sunday...
  • Firefox: Tech writer friendly!
    Firefox has an in-built popup blocker. Firefox saves your screenspace through its tabbed-browsing feature. Firefox allows for opening mult...
  • Engrish!
  • Context Sensitive 'Sticky Notes': Stick a Sticky Note to your Blog!
    Conceptworld's Quick Notes Plus might appear like any other Sticky Notes Plus (QNP) program, but its context-sensitive notes feature is...
  • Writing SI units and symbols
    Quite a few of us do not write the SI units correctly. If you are a Physics or Chemisty student, and still remember what you studied in scho...
  • Finding the voice
    Excerpt from LOUIS MENAND's review of Eats, Shoots & Leaves: The Zero Tolerance Approach to Punctuation” (Gotham; $17.50), by Lynne ...
  • The Personable Manual
    Why do product manuals sound formal and stiff-upper-lipped? Why don’t users read manuals? These questions have haunted the hallowed precinct...
  • Tech-writers – A Necessary Evil
    In a world where accuracy is all important, a lot goes over the head of the dummy. I don't know if it's intellectual snobbery, but p...

Categories

  • conferences
  • contigency design
  • culture
  • design
  • error messages
  • google
  • hall of shame
  • ideas
  • management
  • manual
  • standards
  • stc
  • strategy
  • tools
  • usability
  • writing

Blog Archive

  • ▼  2009 (1)
    • ▼  February (1)
      • The Personable Manual
  • ►  2008 (5)
    • ►  November (1)
    • ►  September (1)
    • ►  May (2)
    • ►  April (1)
  • ►  2007 (7)
    • ►  October (1)
    • ►  August (2)
    • ►  June (1)
    • ►  March (1)
    • ►  January (2)
  • ►  2006 (10)
    • ►  November (2)
    • ►  October (3)
    • ►  September (1)
    • ►  August (3)
    • ►  June (1)
  • ►  2005 (17)
    • ►  December (2)
    • ►  November (1)
    • ►  October (3)
    • ►  September (2)
    • ►  August (3)
    • ►  June (2)
    • ►  May (1)
    • ►  April (2)
    • ►  February (1)
  • ►  2004 (32)
    • ►  December (4)
    • ►  November (1)
    • ►  October (3)
    • ►  September (3)
    • ►  August (2)
    • ►  July (5)
    • ►  June (3)
    • ►  May (1)
    • ►  April (5)
    • ►  March (2)
    • ►  February (1)
    • ►  January (2)
  • ►  2003 (42)
    • ►  December (2)
    • ►  November (3)
    • ►  October (1)
    • ►  September (3)
    • ►  August (7)
    • ►  July (2)
    • ►  June (1)
    • ►  April (4)
    • ►  February (4)
    • ►  January (15)
Powered by Blogger.

About Me

Unknown
View my complete profile