Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Technical Writers Drive Ektron’s User-Centered Development Process


Published on

Presented at DocTrain East 2007 by Bill Cava and Greg Stout -- On the eve of a production deadline, have you ever reviewed your documentation and caught yourself thinking: “I could have designed this better”? We have, and decided it was time to change.

If a feature is hard to document, then it is hard to explain. When something is hard to explain, it is also hard to use.

At Ektron, we have a staff of smart, talented, and technically savvy writers with years of experience. And with the classic development process, the keen insights of the Documentation team are entirely excluded until the product is ready for delivery. After many enlightening incidents, we realized there just might be a better way to do things.

By turning the traditional development process model on it’s head, and implementing Agile, User Experience Driven Development, we have been able to code faster, code better, provide higher quality documentation, and, at the end, a better user experience.

With Ektron’s current development process, significant prototyping and documentation occur for each feature and project before a single line of production code is written. By involving the Documentation, QA, and Support teams at Step One, front-line experience can be added to our development processes. By providing thorough prototypes before development we have been able to reduce costly iterations in our development process.

Our process also produces less disposable project documentation The documentation produced through out the process evolves from feature specification to the user explanation shipped in the finished software manuals.

Today we will discuss an innovative new approach to developing software that puts the Documentation team at the front of the development process. Since Documentation is naturally focused on the User Experience, by having the Documentation team leading Development, each and every Developer can focus on providing the best User Experience possible.

We’ll explain how our new process not only sharpens product quality, but feeds the Developers, QA and Senior management with critical information throughout the process, allowing each group to participate with more completely and efficiently.

Learn about how we have restructured our entire development process to a more Agile and efficient machine, focused primarily on the User Experience and producing a more thoughtful and finely crafted piece of software.

Published in: Technology, Business
  • Be the first to comment

Technical Writers Drive Ektron’s User-Centered Development Process

  1. 1. Technical Writers Drive Ektron’s User-Centered Development Process DocTrain EAST 2007
  2. 2. <ul><li>Bill Cava, ektron Chief Technical Officer </li></ul><ul><li>Greg Stout, ektron User Interface Development Engineer </li></ul>
  3. 3. Documentation Drives our Process <ul><li>Documentation plays a pivotal role </li></ul><ul><li>in defining all new features and the direction for all development at Ektron. </li></ul>
  4. 4. Back in the day… <ul><li>Stakeholder went directly to a lead engineer </li></ul><ul><li>Engineer developed it </li></ul><ul><li>QA tested it </li></ul><ul><li>Documentation documented it </li></ul><ul><li>Support supports it </li></ul><ul><li>A Simple Process </li></ul>
  5. 5. The Reality <ul><li>Lead Developer goes straight to code </li></ul><ul><ul><li>solving the “Programmatic Problems” </li></ul></ul><ul><li>Interfaces created to serve code </li></ul><ul><li>Inconsistency </li></ul><ul><li>Many cycles of re-development </li></ul><ul><li>Mad Dash through QA </li></ul><ul><li>Delivered Late </li></ul>
  6. 6. <ul><li>What about Documentation?? </li></ul>
  7. 7. <ul><li>The After Dinner Mint </li></ul>
  8. 8. The Hidden Costs <ul><li>Wasting resources, time, etc, etc, </li></ul><ul><li>Potentially losing out on quality </li></ul><ul><li>Over time you lack Innovation </li></ul><ul><li>Poor interface makes unhappy customers </li></ul><ul><li>Poor documentation makes Support calls </li></ul><ul><li>So many more… </li></ul>
  9. 9. Who Were the old Players <ul><li>To fix the problem, You must understand the players. </li></ul><ul><li>Stakeholder </li></ul><ul><li>Developer </li></ul><ul><li>QA </li></ul><ul><li>Support </li></ul><ul><li>Documentation </li></ul>
  10. 10. A Stakeholder <ul><li>A stakeholder directs a project. </li></ul><ul><li>They have a key understanding of the projects primary goals. </li></ul><ul><li>Their primary job is too communicate the goals to whomever will develop those ideas. </li></ul><ul><li>They are involved in reviewing the project </li></ul>
  11. 11. Challenges of the Stakeholder <ul><li>Analyzing a feature from all angles is difficult </li></ul><ul><li>Communicating is difficult. </li></ul>
  12. 12. What the Customer had
  13. 13. How the Stakeholder Understood It
  14. 14. How the Project Manager Understood It
  15. 15. How the Developer Built it
  16. 16. How we fix it on release day
  17. 17. What the User really needed
  18. 18. How it was Documented
  19. 19. <ul><li>Is the stakeholder without blame? </li></ul>
  20. 20. Ever meet this Fellow?
  21. 21. A Stakehorder <ul><li>A stakehorder runs a project. </li></ul><ul><li>They have a key understanding of what the projects primary goals should be BUT they feel that only they can understand the goals so they don’t involve others. </li></ul><ul><li>They like to say, “ I’ll come back to see if you’ve got it right.” </li></ul>
  22. 22. The Stakehorder’s Cycle Programmer gets a list of features Stakehorder Reviews the Project Programmer Creates Example
  23. 23. Engineer <ul><li>As unchanging as the mountain or the stars </li></ul><ul><li>The Zen in the process both Yin and Yang </li></ul><ul><li>The Engineer simply is the engineer </li></ul><ul><li>Engineers fail when they are asked to do that which is not engineering </li></ul>
  24. 24. QA <ul><li>Job is to find Bugs </li></ul><ul><li>Finding bugs take time and a deep understanding of the feature being reviewed </li></ul><ul><li>Trained to think about the User </li></ul><ul><li>QA fails when not given enough time </li></ul>
  25. 25. Support <ul><li>Talk to Customers everyday </li></ul><ul><li>Acutely aware of what confuses, frustrates and angers customers </li></ul><ul><li>See each new feature as a chance to make new friends with people they have never met </li></ul>
  26. 26. Documentation <ul><li>Job to document each feature so that a new user unfamiliar with the product can use it </li></ul><ul><li>Think about everything from User’s Point of View </li></ul><ul><li>Product wisdom, have been at the company a long time </li></ul><ul><li>Some of the brightest but often the most marginalized </li></ul><ul><li>Documentation fails when not given enough time or information to properly document. </li></ul>
  27. 27. Why it DOESN’T Work <ul><li>Being a Stakeholder is challenging </li></ul><ul><li>Engineers think about Engineering </li></ul><ul><li>QA takes time and takes understanding </li></ul><ul><li>Documentation isn’t given enough time to understand the feature </li></ul><ul><li>Documentation started at the 11th hour </li></ul><ul><li>Documentation out of synch as changes happens </li></ul>
  28. 28. How we changed <ul><li>Understanding these roles and what they COULD bring to the table allowed us to completely redesign our process to produce even better software. </li></ul>
  29. 29. User Centered Design Process <ul><li>Optimize the user interface around how people work, rather than forcing people to change how they work to accommodate the software </li></ul>
  30. 30. User Centered Design Process <ul><li>Email (dis)organization? </li></ul><ul><li>Look at the many ways in which people prefer to organize email </li></ul>
  31. 31. User Centered Design Process
  32. 32. Response to Gmail’s approach?
  33. 33. User Centered Design Process <ul><li>Simplifying the structure of tasks, making </li></ul><ul><li>things visible, getting the labels right, </li></ul><ul><li>exploiting the powers of constraint, and </li></ul><ul><li>designing for error. </li></ul><ul><li>Wikipedia - User_Centered_Design </li></ul>
  34. 34. Usability Principles <ul><li>Consistency </li></ul><ul><ul><li>Icons, Titles, Processes, Consistent Navigation </li></ul></ul><ul><li>Simplicity </li></ul><ul><ul><li>Simple tasks should feel simple </li></ul></ul><ul><li>Subtlety </li></ul><ul><ul><li>Advanced tasks should not interfere with #3 </li></ul></ul><ul><li>Discovery </li></ul><ul><ul><li>Software should be forgiving (undo) and helpful (contextual) </li></ul></ul>
  35. 35. How the Roles Change <ul><li>Stakeholder </li></ul><ul><li>Developer </li></ul><ul><li>QA </li></ul><ul><li>Documentation </li></ul><ul><li>Support </li></ul><ul><li>User (User Experience) </li></ul>
  36. 36. The Ektron Process
  37. 37. The Ektron Process Now the stake holder meets with a team comprised of people from each department. They are interviewed by the UX group and specification for the feature are defined
  38. 38. The Ektron Process Documentation starts before coding Offers direct input into the feature based on experience with the product as a whole They document the Mockup as if it was the finished product.
  39. 39. The Ektron Process Now Engineers have a complete Mock up showing specifically what the UI needs to look like and how each function needs to work form a user perspective. When coding they solve problems from the users perspective.
  40. 40. The Ektron Process Offers advice about specific tests they intend to run, before coding has started . They offer insight about how similar features have failed, before coding is started . A QA engineer is assigned to the feature to help review and test during the whole production period.
  41. 41. The Ektron Process
  42. 42. <ul><li>“ Best-in-class companies are 74 percent more likely than average or laggard companies to start the documentation process at the same time as the design process.” </li></ul>Best-in-Class Companies Involve Technical Communicators in Early Stages, Report Finds By: Cecily Farrar, Intercom Assistant Editor Intercom: May 2007
  43. 43. <ul><li>“ Involving technical communicators early helps the project team meet deadlines—best in- class companies meet their documentation targets on a 92 percent or better average—and allows for coordination and communication in relation to product changes.” </li></ul>Best-in-Class Companies Involve Technical Communicators in Early Stages, Report Finds By: Cecily Farrar, Intercom Assistant Editor Intercom: May 2007
  44. 44. What about me? <ul><li>What if my group is not a part of engineering? </li></ul>
  45. 45. <ul><li>Best-in-class performers are 69 percent more likely to place the documentation team in the engineering department. </li></ul>Best-in-Class Companies Involve Technical Communicators in Early Stages, Report Finds By: Cecily Farrar, Intercom Assistant Editor Intercom: May 2007
  46. 46. <ul><li>“ Increased collaboration between engineers and technical writers keeps documentation up-to-date with design changes and results in successfully hitting launch dates,” … </li></ul>Best-in-Class Companies Involve Technical Communicators in Early Stages, Report Finds By: Cecily Farrar, Intercom Assistant Editor Intercom: May 2007 (The best in class (companies) make two-thirds fewer post product launch changes than laggards.)
  47. 47. <ul><li>Thank you </li></ul>
  48. 48. <ul><li>Keep in touch! </li></ul><ul><li>Bill Cava CTO </li></ul><ul><ul><li>[email_address] </li></ul></ul><ul><li>Greg Stout UI Dev </li></ul><ul><ul><li>[email_address] </li></ul></ul>