Drawing the data
Data Challenge Status
We’re still en-route to creating a new business application using our EVLVE Enterprise Data Fusion system. Follow the progress here.
The Strategic Vision of a Data Application
In our previous post, we walked through the process of examining the flat data model of a new external data set to assess the strategic possibilities and the potential limitations in the data. In this post, we’ll walk through the conceptual development and design of the final application.
Building a functional data application isn’t a linear process. It’s easy to fall into the misconception that you just look at the data for what’s possible and begin running calculations to produce analysis, before formatting that analysis into some kind of visualization or functionality. But that’s a little like writing an essay by looking through the dictionary for all the words you plan to use.
Instead, developing a data application is iterative and bi-directional, where the capabilities of the available data are compared against the strategic objectives of the organization to identify and flesh out both the format and function of the application.
So far, we’ve proceeded through the first iteration of this process. We identified a strategic objective with our initial survey of bank marketers, and then examined the available external data to identify the capabilities of the data.
We’re now moving back to the strategic side of the process to look at what an application would ideally deliver that would be valuable and useful to a bank.
There are several methodologies to organizing the needs and strategic requirements for an application, but as the saying goes, a picture is worth 1,000 words, and sometimes the most effective way to imagine what an application should be is to start by drawing it.
We love drawing at Datanova Scientific. Nearly every wall in our office has a white board on it, and dry erase markers are everywhere. Few meetings happen without someone leaping up and sketching something. It’s a fast, information-dense way to get everyone on the same page.
Sketching the Ideal Application
Since we already have a general idea about the capabilities of the external data source, we can go into application design phase with some strong guardrails. But from there, it’s all about making the data valuable and useful to the end user.
Below is a quick sketch that the team threw together when considering the strategic requirements and possibilities of the final application:
A few things to point out about this sketch:
Speed trumps style
Don’t worry about the art critics. The point of a sketch is to establish broad brush strokes for the wireframes to come later. The aesthetic only needs to be refined enough to be recognizable, and to drive agreement (or disagreement) on the primary features of the application. There’s even a benefit in “sketchiness”. When people see something that’s still rough, they feel more freedom to provide alternative ideas or changes than if they’re looking at something that feels more finished.
In the above sketch, the charts were clear enough in their format and content that our collaborative partners were able to provide input on various possible features. This sketch took less than 45 minutes to produce and it was immensely valuable in coordinating around the data composition and functionality features.
Find areas to be specific
As part of developing this application, we’ve been having conversation with several banks about the kinds of commercial services that they offer, and even the general popularity and use of each of these services. It’s useful to fold some of these specific factors (E.g., ACH, Checking, Payroll, etc.) into the sketch. This helps ground people in the possible uses of the data, and gets their minds considering additional possibilities.
Dare to dream
While it’s important to consider the limitations of the data when you’re sketching out an application, don’t be afraid of throwing out some “nice-to-haves” that aren’t currently in the data. These “stretch features” open up discussions about additional data sets that could be mined and may discover solutions that wouldn’t otherwise have been considered.
In the above sketch, we included a pie chart visualization with a breakdown of prospects by company size, even though that variable wasn’t in the data from Leadbird. The size of an organization was considered important enough that we put it in the sketch, even if we expected that it might have to be jettisoned because it couldn’t be supported from the data. There are ways to enrich data from additional sources, and if we saw a lot of demand for this feature from other collaborators, we might ultimately look at how we could add this data point.
Don’t be afraid to dream, just make sure people understand which elements are grounded in reality, and which are more hopeful.
Once the above sketch was finished, we showed it to our collaborative partners for feedback, and began looking at what could actually be produced from the data. Moving forward we’ll be using this sketch to produce a full proof of concept with real data.