While there are many obstacles to effective reporting, shadow systems are among the most fiendish. In case the term is unfamiliar, a shadow system is created when a user extracts or duplicates data from Argos so they can manipulate it elsewhere, thus uncoupling it from the central database. Things fall out of sync. Chaos descends. It’s a bad scene.
Sadly, this is a tricky problem to solve. Many users are more comfortable in Excel or Access and would rather stick to tools they know than struggle to learn a new one. That being the case, the best way to keep both your data and your users in Argos is to make Argos a friendly place to be. Making your DataBlocks more versatile, intuitive, and approachable can put your users at ease and keep them from taking their data to go.
In this post, we’ve collected a handful of design tips—some on the back-end and some on the front—for building a user friendlier DataBlock experience.
Back-End Design Tips
Manage user expectations. When you first begin to spec out a new DataBlock with the user, be as up front as possible. Will constructing the DataBlock be particularly time-consuming? Are there problems with data availability? Is the report query going to be a resource hog? Keep your users in the loop on any potential speed bumps.
Avoid building DataBlocks that only answer one question. In the specification process, it’s always worth taking the time to ask a few follow-ups. See if you can identify some other parameters that might be useful for the user, down the line. Digging that much deeper will help you build some beneficial flexibility into your DataBlock’s back end.
Modularize whenever possible. Be on the look out for DataBlock elements that can be saved and called upon in other scenarios. The Library of Objects feature lets you save groups of objects and use them in multiple DataBlocks. You can also save custom functions to the database, or use a tool like the Data Cookbook by iData to store term definitions.
Be prepared to iterate. Make sure everyone goes into the process expecting several cycles of feedback and revisions. This will take off the pressure to get it perfect the first time. Plus, your user(s) will be assured that their input is important to the process. Even once your DataBlock is considered complete, revisiting it periodically will ensure that it’s still meeting your users’ needs.
Front-end Design Tips
Don’t underestimate the value of aesthetics. Giving your DataBlocks a clean, consistent look can go a long way towards reassuring even your most techno-phobic end user. Use the same headers, navigation, fonts and colors on all of your DataBlocks. To keep things unified, write up a style guide that all of your institution’s developers can follow.
Make room for instructions. The more questions you can answer for the user, right when they have them, the fewer you’ll have to answer in person. If there is a progression users need to follow to use a particular dashboard, lay it out, step-by-step, right there on the form.
Keep an eye out for jargon. Make sure everything that displays on the dashboard is written with the user in mind. For example, if you’ve got a drop down for selecting terms, don’t just have the term code show. Take the time write an expression that will display a combination of the term code and the term description, to eliminate any confusion on the user’s part.
Practice restraint. Displaying results in a variety of formats—say a list plus some nice trend charts—can certainly improve the user’s experience. That said, you want to keep your dashboards focused. If the user is going to be overwhelmed by all of the bells and whistles, it’s best not to add them.
Special thanks to Zach Heath for contributing to this post.
How do you get your non-technical users comfortable using DataBlocks? Tell us your secrets, in the comments section below!