Why Datalas?
We’ve done a lot of work with data, and there are a lot of great visualization tools on the market. However, as data becomes more of a requirement to validate a story that’s told, users are required to learn new systems and rethink their approaches when creating narratives.
Some tools introduce us to interesting new ways of approaching our processes, and others guide us to adopt a process that requires buy-in from a larger group of decision-makers. I believe we are at a very exciting point where technologists have laid the groundwork for best practices regarding the use of data, and storytellers are finding the tools that work best for their creative approach.
The Data Visualization Team
In our work, I’ve seen four distinct groups of users that make up the creation of new data visualizations. These might go by different labels in your organization, but I’m sure you’ll see some similarities.
Communications teams
These are the experts who oversee media relations. They write, schedule, and distribute news releases. Maintain the media assets and tone for "how" to talk about an organization. They publicly represent the organization and prepare content for every medium, from digital publications to executive speaking points at events and conferences.
Ultimately, these visionaries define the narratives we want data to support. With the inclusion of data, we are asking these experts to become educated on how an organization's goals relate to the plethora of data available for semination (or know how to collect it).
Data science teams
I love data scientists. Not only because these people are usually the smartest ones in the room, but you need a specific disposition to be a data scientist. Data scientists are so used to people not understanding the questions they are asking that I've found that most of them take it upon themselves to solve the data questions.
Often this process is simply listening to the data's communication goals, scouring data sources to find collections of data (that are both trustworthy and support the scope of dimensions that are needed), then creating processes to combine and format data for presentation. Often, I've seen this process run through many revisions before the data is aggregated in a way that meets the final objectives.
Design teams
Regardless of the organizational aspirations, the design team has one mission.
Make it beautiful!
I am impressed with data designers who step outside the traditional bar and line charts. People like Giorgia Lupi or Frederica Fragapane. However, I find that many amazing designers are put in a difficult position between creating something new and ensuring that data is legible.
There will always be a need in the industry to design charts that are "on brand" and create unique visual design experiences that compel users to interact with them. If we have to choose one or the other, I prefer to empower designers toward the latter. The only graph better than a beautiful graph is a graph that people want to interact with.
Development teams
With all the tools on the market, development teams usually must use a platform that someone else selected. For most developers, this is pretty normal, and I would argue that an essential skill that every developer should adopt is the ability to be flexible in their implementation approach.
This team is essential to how everything is glued together. They coordinate how the communications team will publish the data, assuring that the aesthetics represent the design team's vision, and work directly with the data science team to make sure the data structure makes sense and that the data the scientists have aggregated shows up as expected.
Time Loss
The coordination between these groups can be nebulous.
I've found that working through an Agile approach helps. We can build minor progressions that evolve to meet the larger narrative. This process requires the ability of every team to make changes to the narrative when the data is updated, assess the design needs to make the adjusted visual more legible, engineer enhancements to accommodate design/data updates, to be reviewed, and potentially begin again if the narrative requires it. I've seen this process take a week, and I've seen this process take six months. The differentiating factor is how fast each team can dramatically change their objectives. Little changes can require more rounds; big changes can require more time for each group.
The Datalas Mission
At its core, Datalas is a collaboration tool.
How do we let each team work in a way that allows them to spend less time between the steps required to publish a story supplemented with data? Better yet… How do we allow each of these teams to work in parallel so we can empower each team to iterate on their own, using the existing tools they already know how to use?
This is where Datalas wants to help.
Provide the publishing tool that communications needs, the design tool that encourages designers to explore data experiences, connects to whatever system the data science team uses, and provides developers a framework to build new components that already have the required configuration interfaces.
Datalas is currently running an active beta program, and many features are still being finished. Still, I believe the opportunity to create platforms that allow a variety of previously established processes is where we will see the most amazing products. It's time to let technology do the heavy lifting and require less adoption for the users who want to employ what systems offer.
If you're interested in applying for the Datalas beta program, you can launch the application from Datalas.io.
