This post is part of an ongoing series of posts about my final project. This time I'll be addressing the design process of the project from "ideation" to prototyping to final proposals in a more technical fashion. The first part of this series can be viewed here.
The design process for information architecture can be addressed in many different ways. One of my favorite is found in the book Knowledge is Beautiful by the incredibly talented David McCandless that consists of 6 steps: Data visualization, Structured data, Information Design, Linked Information, Knowledge Mapping and Inter-connected knowledge. I believe these steps are based on the DIKW theory (Data, Information, Knowledge, and Wisdom) coined by Richard Saul Wurman. In a nutshell, as designers/data scientists, we must take unstructured data and turn it into structured information capable of creating new knowledge through insight finding and pattern recognition.
As mostly any other design task. The creation process began by sketching on paper (like the example picture on the header of this post). This allowed a quick and easy way to develop our ideas from both a visual and a usability standpoint.
We then reviewed the proposals and by iteration started to refine the best ideas. This is a back-and-forth process that allows the designers to evaluate proposals against user needs, project requirements and project constraints.
After this, we designed three static visualization prototypes whose functionality we would eventually evaluate with the experts. I must say that it is difficult to cram down so much complexity into one visualization. We were contemplating a mathematical mean of about 1500 data nodes, with a system that should work for as little as 200 nodes and as much as 4000. This enormous capacity for adaptability had to be designed in advance in terms of the User Interface and especially in terms of the User Interaction. With complexity and large amounts of nodes, data dosage and detail layers are key for a successful visualization. That is why static/printed visualizations for bioinformatics oftentimes serve more as beautiful posters than as real research tools. Let me be clear: I'm by no means disregarding the use of static or printed data visualizations as useful assets, but when you add user interaction, the results are many times more powerful.
When we prototype for a tool such as this one, we must design not only the UI, the UX and the tool's behavior (this is, the tool itself) but also scenarios of use. This is because assessment from the final user is paramount for the success of the final product and this can not be achieved without guided "use situations" in which the user will provide spoken and gestural feedback.
We also evaluated the prototypes using a simplified version of a tool used in Quality Deployment Functions in which we quantify desirable functions of the product for each proposal. This left us with two different results for decision making (one more user-centered and the other more technical). Luckily they both pointed in the direction of the same prototype:
We also designed an alternative view or "dimension" that worked well with every proposal. When designing tools that handle a lot of correlated information, sometimes it's a good idea to have several "vantage points" on the same data, so as to have more chances of finding new insights.
I mention this alternative dimension because I've had the chance to present my project several times across very different audiences and they all seem to suggest that this would have been an extremely desirable feature. In the end we could not implement this because of technical and time constraints that I will explain in another post, but I would like to say that even if the working beta tool doesn't have it, this additional visualization was designed and tested and -is- part of the design process. Sometimes one can go back into the design and planning stage and recover valuable ideas that can be used for further project developments.