Access JumpStart 2.0 | Blog

A Rapid Development Framework for Microsoft Access

When I get to work on other people’s databases (or my own for that matter) I have a couple of main principles I use to test my solution. I don’t consider it done until it passes these 2 tests:

  1. My first principle is to simplify the users’ job.
  2. The second is to streamline their workflow.

I guess I must first say that I judge the change before I even start working on it with these principle in mind. I make sure I walk through the user with their thought process as to WHY they are asking me to make a change in the first place. I want to understand how this is simplifying or how it is adding value to their workflow. It may be a direct simplification, like pressing a button to automate 10 tasks down to one button press, or it could be a new report to help them understand and measure a new metric to help them optimize their workflow and make better decisions from a broader perspective.

Whatever these things are, I am measuring the completed solution by these factors and determining, does it really ultimately do what the customer wants it to do, as well as does it break any existing workflow. If it takes longer to do something they did before, this has become a bitter-sweet solution. Like if adding a logging system to their order entry form noticeably increases the time it takes to enter or look up an order, I try to do whatever I can to reduce that time by as much as possible, ideally making it even faster than when I started if I can.

In doing this, I’m focusing ahead of time on what the customer is expecting and smoothing out unexpected friction points.

What kind of guiding principles do you use?

Sign up For a Daily Email Adventure in Microsoft Access

Every business day (typically M-F), I'll send you an email with information about my ongoing journey as an advanced Access application developer. It will be loaded with my tips and musings.

    We won't send you spam. Unsubscribe at any time.