The whole nine yards...

As soon as I was finished with building the CDE Tool I started designing the Dental Directory. The Dental Directory is simply a repository of employee information for the Division of Oral Health, open for all (within the division and of course at various levels depending on position) to use and maintainable from the field with minimal overhead. This was going to be another large application intended to improve the overall productivity of the Division of Oral Health. A few key questions arose from the development of the CDE Tool and I set out to answer them...

When can you have too much documentation? At what point should you finally define the behavior of an application? Well, one thing I learned from designing and building the CDE Tool is that you can never have enough documentation and you better define as much behavior as possible before you start programming. I vowed to learn from my experience and go all out, the whole nine yards! I created design deliverables at every stage of the design process and when warranted in greater detail than before. Although not so agile, both application were too complex to not fully define the behavior of the system before writing a single piece of code.

Creating the deliverables enhanced my design process. They keep me on track and focused on the problem at hand. I was able to articulate the vision of the design in a sound and understandable manner; deatils weren't left out. I designed as I wrote the paragraphs and drew all of the diagrams, it just flowed naturally and the Dental Directory came into being.

  • InterviewsI conducted contextual interviews with a group of over 10 users. The interviews were done either remotely or on-site. All interviews were recorded and transcribed. I created the matrix above to help visual and weigh the responses from the interviews.
  • Mental ModelsI created mental models for each functional area identified in the interviews. Tasks were gleaned from the transcription and then sorted (card sorts within the team). Existing functionality, content, and requirements populate the bottom portion of the Mental Model diagram for comparison to the top portion.
  • PersonasI developed one primary persona, Jeffery, based on the user research conducted. His goals and needs represent those of all potential users of the system. Except for a secondary persona, Brian, who was developed to supplement Jeffery and to represent users who have expanded informational goals and needs.
  • RequirementsAll requirements (user, data, business, technical) identified in the research and user modeling were captured in a spreadsheet for easy review, prioritization, and tracking of implementation.
  • Site ArchitectureThe site architecture was the result of iterative design on the white board and the creation of usage scenarios. The architecture details the organization of the major screens to be included in the application, including basic functionality.
  • Design Vision DocumentThis document was created to communicate the design vision (solution) to the clients. This was a necessary step in working with dispearsed stakeholders.All major features were identified, defined, and compared to the users needs. The site architecture was displayed in segements along with basic wireframes of the main pages. Key task flows were identified and sketched. The design relied heavily on the usage scenarios I created for each persona.
  • Detailed Archtitecture Architecture diagrams detailed the interaction between the various components of a page. Wireframes detailed data requriements, visual layout, and functional rules.