Helping my customer understand Access 2007 screen possibilities

[Phred]

I am developing an Access 2007 SQL Server 2008 back end for a distributed application in a law firm. We are finished with the architectural design phase. I have presented two different approaches for screen prototypes to no avail. I am looking for some type of end user education on what the possibilities are so that they can be more self-proactive in pulling together screen designs. I figure if I can come up with something to guide them it will be better then developing prototypes for rejection until the cows come home. I am scouring the web and youtube for something appropriate for end users. I am not looking for GUI programming principles. I am looking for customer guidance in selecting the best front end for their business. Don't know if any such thing exists. I am looking for the view from 20,000 feet. I suppose I could show them some of the Access template databases. If anyone has any suggestions or can point me to a resource I would appreciate it. Asking them, "How would you like to see your data on the screen?" seems to be a real stumper. The answers I get are, "Does it have to be green?", or "Is it going to look like that?"



Phred

[June7]

The interface should reflect the business process. Should the db open with a 'main menu' with buttons for various modules - Client Intake, Hours Billing, etc.?

Every business is different. Understand the business process. Build a wireframe model of forms and how they connect.

Bing: database design user interface model

http://en.wikipedia.org/wiki/User_interface_design

[Dal Jeanis]

Read these two sentences in order.

"We are finished with the architectural design phase."

"I am looking for customer guidance in selecting the best front end for their business."

Red flag. Red flag. Red flag.

Database design is trivial if you can ignore the real-world usage of the database. I've never found that strategy to be viable, though.

You cannot be done with architectural design until you have compared each of your database design candidates against each of the customer use cases, and validated that the selected candidate design will painlessly support every use case.

If you haven't yet interviewed the users and determined what functions they need to support their workflow, then you aren't even finished with the business analysis, let alone with the architectural design.

Here's the kind of questions you need to ask for user case development.

A) What information do you need on a daily/weekly/monthly/adhoc basis? What questions do you often need answered? What information do other people ask you for? How do you get that information now? What does the current version (the report or paper form or electronic form) look like?

B) What information do you need to keep track of, to do your job (or to help others do their jobs)? When do you receive that information? Where does it come from? What order do you receive the information?

C) When process X gets done, how does it currently get logged? What do the log forms look like? Where are they kept?

D) When you make a document to file in a case, or to send to another lawyer, what are the steps that you go through? What legal word processing software do you use? what validation/revision/approval steps does the document go through to get approval? how do you know it's been approved? What happens next?

These are business questions, not technical questions. Get blank copies of all the forms that are regularly used in the office, and automate those forms with an Access form that generally follows the same guidelines. Then take a user, and walk them through the process with live data, and see where the glitches are. Most often, you'll find out that the programmatically correct order doesn't actually support the workflow, and you need to modify the screens slightly to make the workflow progress more efficiently and ergonomically.

While you're doing the user case analysis, you might verify

1) auditability requirements - how are you tracking updates, verifying accuracy, and preventing loss of data?

2) security requirements - how are you limiting database access to those who have a need/right to know a particular case or client?

3) disaster recovery requirements - how are you making sure the system data is retained in case of flood, fire, user error, system meltdown, hacker attack, an so on?

[orange]

Totally agree with Dal.

Have you identified a set of Business Rules that represent the Business? Have the users been involved in the process?
The processes involved? The outputs required and the frequency? The audiences?

We used to use "stub processing" which may be same as June's wire frame.

We'd build some forms and some buttons - when clicked all they did was put up a message verbiage of what would happen.
This required minimum code; showed the process flow; and the operation/message. This was reviewed/vetted with various clients/functions.
Changes/errors were identified and adjustments made before a lot of coding was done. Working with client reps was key. Client reps started to take ownership very early on in the development.

Hope this is helpful.

[ItsMe]

It is not going to build itself and you should not expect the client to offer design suggestions. I suggest you set aside a great deal of time to follow Dal's suggestions. Don't share what it is going to look like until after you have at least a beta version.

The best thing you can do is to design it so it is familiar to the user. So while you are researching the answers to the questions outlined here you can answer the GUI question by looking at how the users currently interface with their applications.

Then you can change the color from green to their company logo colors and impress the hell out of them.

[Dal Jeanis]

ItsMe - I find the user will offer lots of design suggestions, but they'll only start doing that when you're close to finished with the application.

Phred - I hope my suggestions didn't come across as snarky. There's a fine line between "helpful guru on a mountaintop" and "ranting crazy man in a loincloth", and the lack of vocal tones on the Internet makes it very easy to erase the distinction...

[ItsMe]

ItsMe - I find the user will offer lots of design suggestions, but they'll only start doing that when you're close to finished with the application. ...

I agree. I think that is the point I was trying to make. The user or client won't have an opinion until after you show them the product. Trying to convey an idea of what the product could be has never worked for me.

That reminds me of a common response to my offering of an incomplete app. Trying to show a user a small segment of their operations being managed by the app, the response from the user is often times, "That's great! Can you paste that into Excel?" Or another response, "Can you print that for me?"

To me it is simple. It is up to the developer to interview the users and understand the workflow. Then the developer can create a product that demonstrates an ROI. If you can demonstrate an ROI with sample DB's and GUI's, more power to you (the developer). Don't get me wrong, you need an aesthetically pleasing interface. You also need the information to be directly under the User's nose at all times. The User is not going to help the developer create those elements directly.

[Dal Jeanis]

Agreed. Usually, I think over the user's needs in the abstract before I ever interview them. I use common sense, an understanding of the general aspects of the industry, anything I've learned from watching TV or movies that related to the kind of business environment, and so on, to think about what *must* be the characteristics of the workflow... then come up with a list of either-or questions. Does your office work *this* way, or *this* way? Even if neither of the two is correct, the user will be able to give you a quicker, clearer answer to that type of question than to a question phrased "how does your office work?".