When you start to practice an interface-first design approach, you'll start to discover all kinds of interesting things. Especially if you are working with clients that have not been big users of Notes before, you will find that your interface on paper may not look like a "typical" Notes application. This is a good thing because you want to design your interface to be useable, not necessarily to conform to standards.
Aside: If you have design standards at your work that specify that all databases must look the same, challenge the status quo. Standards for design are great if they are used as a guideline, but if they prevent you from creating the best interface for your users then you need to rethink your policies.
While I am working through the design process, I spend a lot of time thinking about the user's flow. What will they see when they enter the database? Will they have to search around through views to find the information they need or can I present it to them right up front? Heck...do they even need views? Depending on your scenario, you might be able to eliminate some of the interface stuff that's become a legacy in most Notes databases.
Here's an example that I think illustrates this point well. I was involved in the re-design of an existing Notes application that was used for tracking employes goals and competencies for HR. Its interface was a typical Notes database like I described above. The first thing I did during the design phase was to play with the existing application to see how everything was laid out. The next step was to perform some user interviews in order to get an idea of the different scenarios in which the database is used. Basically, I found that this application had three different user types: The end user, a team manager and an HR representative. Security was obviously an important aspect of this application, so all documents were secured with reader and author fields. As it turned out, the end user will only ever see three documents while working with this application. They would first create their "Person Profile" to capture metadata about them (location, education, training and certification, etc.). After this, they would create two other documents, their "Goals" for the year and their "Development Plan". Since these were the only documents they would ever even see in the database, I immediately starting thinking along the lines of a dashboard metaphor...a single screen that would give them an overall view of their documents without having to deal with different views. We worked out some prototypes on paper and ended up with the following UI:
When the user first enters the database, they see the three documents that they have to work with represented under the 'My Documents' section. The dots are used as an indicator to denote whether or not they have completed that particular document. In this example, the end user has created the "Person Profile" but has yet to add the "Goals" and "Development Plan". This layout worked well for two reasons...the users had a much easier way to get to their documents and they had a visual reminder of what they needed to do at a single glance. Since we were able to dispense with the views, we were also able to make good use of the extra screen real estate to include important news items and links to databases and websites of note.
This interface worked very well for the end users, but what about the their managers? As we learned from user interviews, one of the trouble points in the old application was that a manager did not know where employees stood in terms of completing their information. What they needed was a simple way to get an overall picture of their group and what still needed to be done. Since each manager had a handful of employees, a slight variation of the end user dashboard did the trick.
Here an embedded view provides an "at-a-glance" look into the state of each employee's documents. The documents in this embedded view just serve as a container to hold the UNIDs of the actual documents. In this way, we were able to provide the nice graphical feature in a very lightweight manner. If the manager wants to go to a certain document for an employee, they just click the employee's link in the embedded view and are prompted for the document to open.
In the end, this dashboard was found to serve its purpose in all scenarios. The HR representatives, having access to all documents, would use the manager dashboard, with the ability to select users by business division, country or manager.
In the event that a manager or HR representative (or even an end user) wanted to use a standard view, those options were presented as well, since this was simple to do. A section at the bottom of the dashboard can be opened and the user can pick from the list of available views. The selected view is then displayed within this area of the dashboard as an embedded view.
There were a lot of other aspects of this application that we touched while performing this overhaul, but rethinking the whole "navigation and view in a frame" concept was the biggest change. Not surprisingly, this was also the piece that the users found most appealing. The lesson learned from this application redesign was that by removing a lot of the UI stuff that wasn't providing value (such as the views), users were happier and acceptance of the application was much higher than the old database.
So...care to share unique interfaces that you have built?