Project complexity has grown to be a constant challenge for knowledge workers. With entirely new vocabulary based on project management style, new software for every task, and an ever-increasing demand for domain knowledge, the onboarding flow can be daunting to say the least. In a vain attempt to combat this for new graduates or those entering a new career, our series will look to distill the lessons from each of Torq’s newest launches, be that product or program, into a series of easy-to-digest points with actionable insights. This flagship piece will be an interrogation of a recent dashboard launch led by Torq Insights for a large automotive finance company.
Language is Decentralized.
The meaning of any given word isn't static, and in fact, some scholars would argue they're constantly changing based on context, culture, and communication style. So, it makes sense that different teams can have different names for the same item or the same name for different items. Confusion between a legal entity and specific property, brand and model, or any other example can lead to errors in decision making or huge barriers to entry for new employees. This expands exponentially for any variety of object-based coding or similar development projects. From sales and marketing to finance, each audience will have different requirements and that will influence all parts of the process including seemingly minor things like the order of discussion items in a requirements gathering meeting. The way around this is equally simple—use a universal identifier. ID code is the best choice, but any unique ID would work. This might reduce personalization, but it eases your user adoption considerably. More importantly, it prevents potential confusion across the board. While it sounds obvious, it's important to note that even something like an entity's name might be different across different data sets, organizations, or departments.
Small Touches Mean the World.
Moving away from naming conventions, there’s a larger discussion around micro decisions across the board. When presenting information to a non-technical audience, choosing to use a more common language will empower the user to make decisions instead of googling every other word. For example, when building a graph, taking the time to rewrite tool tips into sentences, rewriting the title to share the conclusion, and removing visual clutter might seem redundant or needless, but it will have a massive impact on the audience who must use that analysis to make decisions. One of the best examples of this would be replacing KPI cards with a sentence. Having a static list of quarter, sales, and salesperson with a value beside them is a starting point but rewriting that as a dynamic sentence would make users' lives much easier. Humanizing data is the point of business intelligence, so a good analyst will make sure their numbers are correct and a great analyst will make sure their numbers are accessible.
There Isn’t an Intended Use Case.
On the topic of accessibility, the end user of analytics needs to be centered across the development process. Audiences tend to be wildly creative given enough time, be that a laundry list of enhancements or a whole new use case that could completely reshape the project for the better. For example, most business intelligence platforms allow users to view the underlying data. What isn’t as obvious is that filters are also applied to that data so users can be empowered to pull their own reports. Assuming a dashboard is solely for visualization can impose artificial limits needlessly. To mitigate this, involve teams in the development process and see what they prioritize. If it's a sales dashboard have the sales managers play with the alpha build before it's released to their teams. As analytics grows increasingly complex with black box algorithms, a nearly endless variety of charts, and constant validation, take a moment to remember to look at the problem from the user's perspective.
Comments