A technical writer’s role in software quality – an experiment Asha Mokashi, SCT Software Solutions, Bangalore

2 Objective Share the experience of playing other roles in a product team, highlighting the methodology followed

3 Contents Going Beyond Roles – Why ? Going Beyond Roles – How? Moving Forward Constraints and Benefits Conclusion

Going Beyond Roles-Why?

5 Our Unique Advantages View from both sides – possible user’s perspective and Development/Design team’s point of view Overall view of product across functions Interaction across Development and Quality Testing teams

6 Why go beyond roles? Helps utilize other talents/abilities Reduces the Us-Them divide Results in improved content in Help as you get other perspectives, more co-operation Creates ownership over product, not just over Help Explores new avenues and aids in career growth

Going Beyond Roles – How?

8 Company/Work Profile SCT Software Solutions – administrative software for the higher education market Approximately 1,300 higher education clients around the world Product based company - offshore development center in Bangalore Direct interaction with client rare

9 My Work Profile Part of team that creates a financial aid application Complex application, vast domain, sole technical writer 3 years experience in company, worked with other applications

10 Going Beyond Documentation Understanding processes Identifying lacunae Undertaking responsibilities

11 Understanding Processes Understanding the Design, Development, and Quality Testing Process Reading design documents, following mails between Development team and Product Manager that are copied to the team Attending design and planning meetings, discussions Interacting with Product Manager, Development, and Quality Testing teams Discussions with Project Leads to understand areas of improvement

12 Identifying Lacunae Insufficient information about users, usage, and usability Insufficient awareness about implications of incorrect usage and error Insufficient information about business processes Communication gaps resulting in insufficient clarity and understanding at design stage

13 Undertaking Responsibilities Providing feedback on user interfaces, navigation, and error messages Gathering and sharing information on product and business processes with the team Participating in the team’s effort to improve product quality – team divided into various groups concentrating on different areas. Volunteered to work in the Usability group, as the contact person

14 Usability Group Work Methodology followed: Identify deliverables Submit a list of deliverables with dates Keep an activity log Consolidate learning Give recommendations to team Plan for future activities

15 Deliverables 1. Presentation on usability to increase awareness 2. Presentation on usability testing 3. Prepare profile of a typical user and identify conditions of product usage 4. Conduct usability testing 5. Give feedback, from a user’s point of view, during Functional Specifications meetings

16 Deliverables (Contd.) 6. Go through all the screens and log errors, inaccuracies 7. Give feedback and raise usability issues in functions being developed 8. Identify lacunae in Functional Specifications, give feedback to Product Manager 9. Create a Finding Your Way chapter in Help 10. Present findings and process to company

17 1. Presentation on Usability Introduced Usability as a concept to the team, its history, its growing importance, and related it to our products Introduced Human Factors Engineering, User Centric Design Pointed out myths about usability, why it is neglected, and why we cannot afford to neglect it

18 2. Presentation on Usability Testing Introduced methods of Usability Testing, Test Plans, Usability Management Presented Usability Testing report prepared by a Product Manager for another product

19 3. Preparation of User Profile Sent Audience Analysis questionnaires to Product Manager - for example, got information on educational level, age group, computer proficiency of users, familiarity with student aid, familiarity with other aid- related software etc. Collected job profiles from the Net, especially those from the sites of our client universities Collected first-hand information from implementers and support people

20 Preparation of User Profile (Contd.) Some findings: Most users are not familiar with Windows Financial Aid counselors work under a lot of pressure, handle huge amount of data, are frequently interrupted Evaluated on ability to complete tasks on time – panic when errors occur: “This is my fault, not the application’s”

21 4. Usability Testing Identified people in office who came closest to the user profile we prepared – using methodology learned, assigned tasks to them, and made observations Presented results to team with recommendations. For example, error messages could provide solutions, so the user is not stuck without knowing what to do next

22 5. Feedback during FSP Discussions For Functional Specification (FSP) discussions read the FSP from a user’s point of view Raised issues that could create confusion or difficulties for the user

23 6. Logged Errors Went through the product screen-by-screen, logged UI errors, and suggested improvements List sent to the Product Manager who approved these changes Changes implemented during the next release

24 7. Feedback during Development Gave feedback and raised usability issues in functions that were being developed or to which enhancements were being made Pointed out improvements, suggested better error messages, and navigation that saved time and gave more choices to users

25 8. FSP Feedback Identified lacunae in FSPs and made a feedback list Collected inputs from all team members and feedback sent to Product Manager

26 9. Finding Your Way chapter Created a Finding Your Way chapter in Help that helps users to configure the application from scratch It takes them step by step through the various tasks that they can perform with the application Helps users associate business processes with the application

Presentation to Office Presented the whole process to the entire office as a model process, describing the methodology followed Stressed the importance of “Doing it right the first time”, and how important it is to build in quality right at the design and development stage itself, as it is impossible to catch all errors in testing

Moving Forward

29 Moving Forward Initiate usability work across teams – a Usability Group has been formed with representatives from all teams Get more user feedback on product and Help – identify usability-related requirements Make checklists at FSP, Design, and Development stage, build in more processes for quality check

30 Moving Forward (Contd.) Focus on usage scenarios, anticipate problems Make our applications usable for physically challenged users

Constraints and Benefits

32 Constraints Insufficient availability of time due to project pressures. In the initial stages had to put in a lot of work after office hours and during weekends Breaking established beliefs and practices People need to be convinced of the necessity to change - biggest challenge

33 Benefits Heightened awareness of usability and usage in team – becomes everyone’s concern Time wastage due to insufficient information in FSP, or errors corrected very late, is reduced Better and more informative error messages

34 Benefits (Contd.) Findings about usage used to create better system test plans Finding Your Way chapter made a standard across all applications Better working relationships and more co-operation from developers as far as documentation is concerned

35 Benefits (Contd.) Better Help due to my improved understanding of business processes and user requirements, and more information flow from developers Usability group created with members from all teams. This has the potential to make a great difference across all products in the company

36 Conclusion Going beyond roles - learning experience that opens up new possibilities constantly

37 Thank you for your time !

38 Questions