The advice you'll get on design

Let me start by saying there are a lot of very smart experts out there on MS Access. But if there is one piece of advice that gets me going, it's the statement "newbies to Access like to start with what they can see (forms/reports) but this is the last thing you should consider." What I take issue with about statements like this is as follows: if you think like a developer, your application will be made for developers. That means your table structures, code modules, and queries will all be very efficient and (hopefully) architecturally sound. The flip side is, you aren't giving appropriate attention to the end product, and you're more likely to end up with a data-driven design. The end product isn't the tables, functions, and queries that make up your application. It's the menus, forms, reports, and other elements that will comprise the user experience. So what process would I advocate?

1) Determine your requirements. What is it that the end product needs to do to answer your particular problem or need? To help think through the process, you can either spend a lot of time pondering your requirements in your head, or you can whip up a few form/report prototypes and see if you've thought of everything you'll need to meet your needs.

2) Create your design. What is it that your application will need to do in the background to meet your requirements. If you've done a good enough job of thinking through what your requirements are to solve your problem, your design will show that. For example, if you know you'll need to be able to create an extensive number of reports based on dates or other data attributes, your design will be sure to take that into consideration. Similarly, if your requirement is that your application needs to be readily deployed to multiple users without a lot of time copying databases to each person's PC, you're probably going to design your application differently than if you just start creating tables and functions without a thought for the end product.

3) Start creating. Seems simple, but this is where you'll get the opportunity to test your commitment to some of the items you thought of in (1). That is, you may find that actually creating your solution to meet your requirements is harder than it seems, and you'd prefer to sacrifice a few of your requirements to make it easier to develop or maintain.

4) Test. Preferably use someone other than yourself, that may have familiarity with the problem space and desired solution, but hasn't been deeply involved in the development. Why? Because the second you started designing and creating your solution, you begin to think like a developer, not a user. You'll know intimate quirks and their workarounds, something an uninitiated user won't. Thorough testing, especially where your tester purposely tries to "break" things, will ensure you aren't inadvertently signed up to do a great deal of recurring training.

5) Repeat 1-4. The process never ends, does it!