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.

1. Technical Writers Drive Ektron’s User-Centered Development Process DocTrain EAST 2007

12. What the Customer had

13. How the Stakeholder Understood It

14. How the Project Manager Understood It

15. How the Developer Built it

16. How we fix it on release day

17. What the User really needed

18. How it was Documented

20. Ever meet this Fellow?

22. The Stakehorder’s Cycle Programmer gets a list of features Stakehorder Reviews the Project Programmer Creates Example

31. User Centered Design Process

32. Response to Gmail’s approach?

36. The Ektron Process

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. 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. 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. 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. The Ektron Process