Learnability
On any of the add/edit pages, this design is quite learnable. It uses a form interface in a way that should be familiar to most internet users. All fields and buttons are clearly labeled with the information they contain or the function they perform. The only exception to this is the task lists, which add or remove items with a button containing + or -. The meanings of these symbols are relatively obvious in context, however. Furthermore, the use of + or - symbols to mean "add" or "remove" is consistent within our task editing pages, and is not uncommon in websites in general.
The main page is also highly learnable. Although the documents and companies boxes are not labelled, the add buttons under each effectively say what goes in the box. One possible difficulty is that these boxes might look like text areas to a new user, who might think that the "Add document/company" button works like a submit button. To improve learnability (as well as to prevent errors) we can remove affordances for typing in these boxes, perhaps by coloring the boxes and certainly by not allowing the user to visibly give them focus or see a blinking cursor.
Visibility
This design shows a lot of information on its main page - all of the documents, all of the companies, the categories of the companies, and the most pressing task for each company. Every task currently pending is visible a click away from the main page. Additionally, when the user adds a document, company, or task, any changes this makes to any display are visible upon submission of the form. The state of the information the user has added to JobTracker is therefore quite visible.
One thing that is invisible is history. The user can see what documents, companies, or tasks are currently in the system, but as soon as they are deleted, the user has nothing but her memory to tell her they were there. This is not particularly important, however, because the user is unlikely to care about her history of changes.
Affordances are appropriate to the function of the components (with the possible exception of the boxes, as described in Learnability). The design is not cluttered, but contains enough text that the user can easily understand what each component is supposed to do.
Perhaps the most problematic visibility aspect of this design is the location of the add buttons on the main page. The bottom of the page is not necessarily the first thing that will capture the user's attention. The design is so simple, however, that this is unlikely to represent any substantial difficulty.
Efficiency
This design is efficient through redundancy. For instance, it is possible to add a document at both places the user will probably want to - the main page and the "edit company" pages. The link to the main page on all pages but the main page means that one is never more than a click away from the main page, and two clicks away from the task list.
One area where efficiency is potentially low, however, is that the state of the documents list is not visible once one is within the add document page. For instance, the user might forget the names of her documents and accidentally try to give one of her documents a name she has already used. We can prevent overwriting by checking the documents list before adding any new document and returning an error for multiple entries (or renaming), but this requires the user to make an additional edit to change the document name. On the other hand, incorporating the list of all documents on the add documents page would clutter the page and possibly be confusing in its own right.
Error Prevention
Perhaps the most serious error a user could make is to set an appointment for the wrong day. This error is not preventable without the ability to read the user's mind, but the chance of it appearing can be reduced through visibility. Currently the user simply types in a date. That is efficient, but prone to error. One way we could make the date more visible is to show its position on a small calendar near the place it was entered.
In general, however, most errors possible with this interface are typos or accidental deletions. We can't prevent typos, but because the interface is so visible they are likely to be caught by the user. Since this design doesn't visibly keep track of deleted items, accidental deletions are difficult to recover from. We can make such deletions less likely by requiring the user to confirm deletions before they are carried out.