No one's gonna read a few-hundred-page research documentation. What can we do about it?
Introduction
Mobility is perhaps one of the most rapidly evolving industry with changes driven by latest technologies, new services and cultural shift of transportation.
To further understand the latest trends, a mixed team from Fjord, Accenture and Volkswagen has done a series of global research from both market and human points of view, from which merged view analysis was also derived.
While the result was successfully compiled into a book, the team was not fully satisfied with the format due to the vast amount of information. Thus, the team challenged themselves to make the research more accessible.
Um... what do you mean by visualising qualitative data?
Challenges
When the team reached me out for the first time, the above was obviously my first response. I was not fully convinced with the term data visualisation
they used, so I had to make sure we were speaking the same language. We started our discussion by asking below questions to align our requirements.
Definition of visualisation
What exactly do we want to produce? Are we sure we are not talking about another infographic and not trying to make things unnecessarily complicated? Since the term visualisation is so broad, we needed to understand what it means in our context, and what we were trying to achieve by making it.
We need the logic
In order to generate a visualisation, it is obvious that we need to have a logic behind it. How are we going to parameterise qualitative research data? The team already had a good understanding of the requirement, so our discussion was more about in what format we are going to parameterise the data.
Feeding the data
Qualitative data usually requires more complex input than numbers. Also, the team was in the process of iterating their research, so I needed to come up with a solution in which the team can directly input the data while I develop the application. This also meant potential risks of changes in data structure.
Approach
Once above questions were derived, we went through them one by one to align ourselves. This process helped us greatly to kickstart our collaboration.
Interactive and navigable data visualisation
The main benefit of a digital application is in its interactivity to enable users to navigate through relevant information. Unlike quantitative data, our research data could not be displayed in numbers, so it was crucial to sort it by relevance to maximise accessibility.
Thus, we defined our data visualisation as an interactive visual representation that allows users to easily navigate through the data. Furthermore, it should encourage users to learn new information by intuitively showing related data.
Keywords- and sentence-based parameters
In order to build our logics for the visualisation, keywords were suggested as the parameter. The team was already well-aware of the necessity and were ready for extracting those. Indeed, such process is already common in design research analysis.
To save their time, I suggested them to use natural words or sentences as keywords rather than spending time to come up with a single word. This allowed them to use, for example, representative user quotes selected from affinity diagrams as parameters.
Making use of online spreadsheet
The team was already collaborating with an online spreadsheet, which could be exported into xlsx format. I had a quick discussion with another back-end developer to check if it can be directly imported by writing a server-side script and confirmed it possible with SheetJS.
As the result, we agreed to onboard another back-end developer to program xlsx importing script to save our time and effort in filling in the data, and the team was able to continue working with their spreadsheet.
To best avoid the risk of structural and logical changes to the data, I carefully prioritised my tasks to give the team as much time as possible to digest their research.
Process
After spending some time to align ourselves, it was time to bring the concept into life. I took the lead developer role and onboarded a back-end developer to support me with processing xlsx data while I develop the main application.
Data-driven visual design
The collaboration with designers was very unique and interesting as many elements were generated from data. I mostly worked together with a visual designer to build our logics for visual elements, just as shown in below animation.
As our concept continued to develop, we needed to design new logics to match our desired visuals, so I also joined ideation sessions to share my knowledge and design together.
Technical setup
In order to make a highly interactive data visualisation, I needed to find out the best options to generate and animate interactive elements.
During my research, I learnt SVG works very efficiently with CSS animations, and more importantly, React library could handle generating SVG nodes through JSX. Using React would enable me to implement more seamless interactions and animations by making it as a single-page application.
Our data was fairly small, although complex, but I nevertheless decided to save our data into a database rather than hard-coding into JavaScript as JSON. This was mainly to save development time by working with a back-end developer in parallel.
We can always add more data, but not OTHER data...
Coping with the uncertainty
In spite of our effort, we could not avoid critical changes in data structure. I tried my best to prioritise works that had less dependencies on data, but as the core logics changed, there was no other option but to restart from scratch.
To make things worse, a manager from Volkswagen requested not to use GPL licensed software. We were using MongoDB for storing our data, and all of sudden we were forced to seek for an alternative.
Fortunate for us, these two issues came up at the same time, so we could deal with them simultaneously. While I was re-working on front-end with visual designer, back-end developer worked on with structuring PostgreSQL database and new data importing scripts.
Outcome
After a month delay due to changes in structure, we were finally able to deliver the final application. Also, based on the internal tool we made, a public website was also designed and developed within a short period.
Controlling SVG
As a technical note, I preferred to use CSS transforms rather than inline SVG transformations to fully utilise CSS animations. It significantly saved my development time, but with one downside of not being able export the generated visual into an SVG file. I later wrote a dedicated script with inline styles to share generated assets for designers to use in their documentation.
I utilised Redux state management to animate SVG, combined with React Router. This combination allowed sharing the desired visualisation through URLs, just like any other website.
Real-time coding
The public website development followed immediately after the visualisation project, with a very tight timeline. Although we already had all assets ready, me and visual designer had to progress very quickly to meet the deadline. Thus, we decided to design and develop in parallel, sitting next to each other.
For example, the visual designer would suggest visual and interaction ideas like the one above, and once I confirm it, I would develop it quickly to grasp the look and feel. As it was a simple static website, this method worked very well to utilise both of our skills quickly.
Delivery
As there was no other developer from Volkswagen involved in the project, I had to think about how to deliver our application via a non-developer with minimum instructions. The team also did not know about their internal platforms for hosting applications, so I had to think of a universal method.
As the result, we agreed to package the application with Docker. This greatly simplified configuration process of PostgreSQL and Node server – not only for them but also for ourselves to share our outcome internally.
Learnings
This was one of the most difficult development projects I have had so far, with challenges coming from various aspects – from coding itself to corporate setup. This process gave me valuable lessons, with some remaining open questions.
Modes of collaboration
Collaboration process with designers was the core challenge, as the application concept was continuously evolving in parallel with development. I had to quickly figure out which parts could be done independently or had to be done together with designers, just as mentioned earlier.
Especially during the public website production, there was absolutely no time for me to wait for the design confirmation. I and the visual designer agreed to sit together and design and develop at the same time. I literally implemented the design in real-time and this actually worked out great.
Obviously, this was possible as the design direction was already defined from internal prototype, however, such mode of collaboration would be very useful in many situations in which quick – but fully working – prototypes are needed.
Double check client's requirements
We were lucky (and unlucky) to have two game-over situations happening exactly at the same time, saving us from restarting for another round. While changes in data structure might have been extremely difficult to predict, the license issue could have been definitely avoided.
I learnt that use of open source solutions needs to be discussed thoroughly as a part of technical requirements upon planning. As the use of freely available dependencies are almost non-avoidable in modern web development, developers including me often neglect the importance of licenses associated with them. I took this experience to add such factor into my pre-development checklist for my next projects.
How to best avoid structural changes in data?
As a Creative Technologist, I often face situations in which prototypes are urgently needed but ideas are not finalised. This always comes with risks of losing all my work due to the last-minute changes. This is usually manageable as they don't always require complex data structure.
However, in this project, such change was critical and in spite of my effort, I could not avoid starting all over again. As a non-expert in data architecture, it was very difficult for me to predict every scenario and make my code expandable enough to cope with such situations.
Later, I shared my experience with other developers and Creative Technologists, but we all agreed that in such project setup, the risk cannot be completely removed, and thus it remains an open challenge for all of us.