User Centred Development (UCD) and Technical Communication - Stephen Chalastra
Introduction
Despite the challenging weather, our STC Toronto Management Day was a huge success! Over 70 people attended the event, hosted by FrontRunner Training, in the beautiful and spacious main hall of the Estonian House in downtown Toronto.
As everyone enjoyed their delicious continental breakfast, STC Toronto Community President Anna Parker-Richards welcomed all our guests, and introduced the first speaker, Stephen Chalastra, who spoke about User Centred Development or UCD.
Stephen Chalastra is Manager of User Experience at Qualicom Innovations. He has over 30 years experience in the IT industry and a rich history in technical communication. This was his first time presenting this topic to technical communicators!
Wikipedia defines UCD as: “A design philosophy and a process in which the needs, wants, and limitations of the end user of an interface or document are given extensive attention at each stage of the design process.” However, it's more accurate to call UCD user-centred development. To successfully implement UCD, you need to be able to convince management of it advantages.
Many different phrases have described UCD throughout the years, including
- GUI design
- UI design
- Interaction design
- User-centred design (UCD)
- User experience (UX)
Therefore, design by itself is not enough, and has to be more than just functional. It must be easy to use, or you end up with something like a teapot with its handle and spout on the same sides. A case in point is Microsoft Word, which is often a struggle to use. By contrast, Madcap Flare was relatively well-designed.
UCD - Putting Lightning in a Bottle
UCD involves the challenges, goals and needs of both the business and users. It means designing a solution that will fulfill those goals efficiently and innovatively. You need to ensure the project is technically feasible, and validate the design with users at strategic intervals. The UCD process, when done correctly, is like putting lighting in a bottle. It is the "magic" that results in products and documentation that are easy to use and navigate.
Unfortunately, it's easier to say how not to do UCD than how to do it. In a non-UCD environment, a single Business Analyst will ask users their requirements, and then give these requirements to developers who then create the software and pass it on to QA to test. The problem with this traditional process is that there is little collaboration amongst the all the players and the end users. There needs to be more than just one person (the BA) in contact with the user. Instead, with UCD, there is communication across disciplines, and users are involved at all stages, not simply at the beginning.
UCD and Tech Comm
UCD is not just about code development. Technical communicators need to create added‐value documentation, and not just document the basic UI. Because users are often involved only at the start of the development process, by the end of the process, an intuition gap exists in the documentation. Technical communicators need to close that gap and create documentation that actually adds value to the user experience. We can do this by focusing on users and asking who are they and how will they be using the documentation.
Unfortunately, the technical communicators are often brought in too late into the process, with management stating the infamous phrase: “we can't involve tech writer yet – the code isn't ready”. UCD encourages technical communicators to be brought in as early as possible, in order to identify potential problems.
As an example of this: to delete the excess styles formed in Word, the online help only explains what you already know. To find the solution, you have to go on the Internet. Technical communicators are in a particularly good position to find usability and design problems.
UCD @ Qualicom
In Qualicom's UCD process, the BA works with the interaction designer employing usability principles; both work in synergy together. Technical writers are a valuable resource because they help document meetings between these two people. An interaction designer produces design guidelines, wireframes, storyboard and UI specs. All of this information is then passed on to the developers.
The Qualicom UCD road map involves several stages including: requirements planning and elicitation, analysis, UI design guidelines and functional specifications, and usability testing.
Requirements Elicitation
This stage involves understanding the business's challenges and goals, constraints and assumptions. The users’ challenges and goals, needs, and their capabilities are also all explored and defined. The BA works with a usability designer. They must understand what is most important to users. Less frequently used modules of the application must be easier to use than the more frequently used ones, where the user will quickly become an expert. Requirements for documentation at this stage include asking how do users get their information now, how would they like to get it, what do they know, and what do they need to know.
Requirement elicitation tools and techniques include: focus groups, contextual interviews, requirement surveys, documentation reviews, task analysis, competitive analysis, and a glossary. For all these things, one can get value to or from the tech writer. The tech writer can help “step in” for the designer long after they are gone. Note that this stage captures information; it does not dwell on the value of it. That is done in the next stage.
Requirements Analysis
In this stage, you validate, prioritize and document the requirements. Validation involves confirming the support for the business goals and project scope and evaluating the level of detail of user tasks. Prioritization involves determining resources and funding, and balancing the development effort against the perceived benefits. Documentation at this stage involves categorizing information into related functional areas, and ensure that the wording is positive and testable.
In this stage, you must avoid scope creep. Otherwise, it is like giving a user many complex remote controls, instead of the single simple unified one that they wanted. You need to document requirements using user personas. The technical communicator can design a requirements documentation template to help facilitate this.
Requirements analysis also includes using uses cases, usage scenarios, a business data model, visualization and requirements specifications. There must be sign off at all stages. Missing, incorrect or misunderstood requirements are responsible for bulk of software project failures. People who are too technical write requirements that are too technical. Quality requirements documentation that is meaningfully written leads to better user comprehension, more effective reviews, and better quality requirements.
UI Design Guidelines
In this stage, you need to know the business context of the product, and the company's corporate standards. If you don't know your users, you can't design or write for them. It is like the moose flying a plane with controls designed by raccoons – the moose can't use his hooves! You need to define expanded user roles using user profiles. Accessibility needs and usability principles are therefore critical at this stage.
UI Functional Specification
In this stage, you assess the use cases and begin to develop a vision of the user's interactions. You need to determine which requirements are most relevant, which users will be impacted, and if the requirements fit naturally into the design model. You begin to develop a navigation flow which asks: Where am I? What else can I do? How can I get there?
Later, you can start to design prototypes. Wireframe prototypes are a virtual mock-up of the UI, and act as a blueprint for construction that you can use and test. A dynamic wireframe gives a preview of the product's interface where you can enter data into fields, and can generate a Word document dynamically from the wireframe. Code prototypes are used to test proof of concepts.
Design Reviews
In this stage, you review the design for feasibility and develop prototypes. It is an essential element of UCD, and keeps the users involved and engaged. You need to ensure that the design is on track, that all the required functionality is included, and that the navigation is clear and intuitive.
Development
In the actual development stage, you involve the key developers early. The designs are reviewed for feasibility, and developers work with interaction designers to develop prototypes. Technical communicators can create the message text for the application, such as on-screen text and error messages.
Summary
The better the interaction and the interface design, the less need there will be for documentation fixes and band-aids. Technical communicators need to focus on creating added‐value help. To do this, we need to be involved as early in the development process as possible before the code is written. Involvement in design activities will lead to better documentation. Both technical communicator and trainers can be involved in integrating help into the interface, ensuring consistency in the UI, creating understandable message text, producing better project documentation, and testing the implementation against design.
The end result is "magic" - intuitive, comprehensive and meaningful products and documentation that are easy and fun to use.
