Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.

This sketch starts to flesh out some thoughts around a "pre-tool:" A tool that gathers some basic information about the prospective user from a friend or family member. The pre-tool user is not the eventual First Discovery tool user,

The goal of the tool is NOT to start creating a set of preferences; It is to gather just enough basic information about the user's capabilities to get past that initial hurdle of not knowing anything about the user's capabilities.

The information gathered will be used to define, control, direct and filter the flow of the First Discovery tool. For example, if the pre-tool establishes that the user does not understand sign language, then the First Discovery tool will not bother to ask the use if they would prefer sign language. Most information given by the friend/family member will be verified by the user during the First Discovery process.

This sketch separates the pre-tool information gathering from the First Discovery process. There is no assumption that the two will happen at the same time, or that the First Discovery tool user will be present when the pre-tool user is answering the questions. This arose from the use case prepared during the seniors break-out session, where our user was doing First Discovery at home, alone, using a machine her family had purchased and pre-configured for her. (How realistic is this scenario?)



  • the pre-tool user is someone who knows the First Discovery tool user (i.e. the a friend or family member) and is familiar with the person's capabilities; (I recognize that this does not handle cases such as a library employee helping a patron)
  • the pre-tool user may not be filling in the pre-tool questions on the same computer that the First Discovery tool will be using; (is this reasonable?)
  • the pre-tool user is fully capable of using the pre-tool without any accommodations.



  • While this sketch was developed with the Seniors application setting in mind, I imagine the basic ideas would be applicable in other application settings.
  • It might be that the answers to the pre-tool questions might actually modify further pre-tool questions, for example: if the expected device is identified, questions about physical capabilities might be tailored to be specific to the requirements for that device.


In the sketch below:

  • the numbered points represent a single screen;
  • the bullet points after a question are the answers that the user can choose from (likely radio buttons or check boxes);
  • the first iteration of the pre-tool might omit some of the questions or options, based on the expected capabilities of the first iteration of the First Discovery tool. For example, if we don't expect the First Discovery tool to support voice input, we might omit the pre-tool questions about whether the user can speak;
  • the question marks represent where more or other options might be useful but I don't know what those might be;
  • the italicized text in brackets are my thoughts, questions or comments.







1. Personal Identification


of First Discovery Tool User

First name


Preferred language

(include caveats that this information is only for customizing personalizing the language wording in the following screens, e.g. name vs "the user," "his" vs "her," etc.)


2. System Identification (assuming a female user named Maude)


(perhaps accompany the options with example tasks , but NOT computer-specific tasks, things like "use that avoid speculation about potential capabilities but rather focus on known capabilities. For example: if Maude has never used a computer, the person can't say whether or not she can use a keyboard. The examples could refer to similar tasks that can be known at this point, for example using the buttons on a push-button phone" rather than "type on a keyboard"phone.)
(this might want to be check boxes rather than radio buttons, depending on the choices)