Designing with Data
This article has had an interesting genesis. It was one of the topics I had on my list to eventually tackle, but recently one of my good friends specifically reached out wanting to get more information on the topic of Designing with Data, and what that actually implies. I decided to share a Keynote I have created specifically addressing this topic, and this article is going to compliment much of that document with practical examples and additional context. The information on the Keynote is also capture in the body of the article itself, and not just on the image provided.
Designing with Data, Hunches and establishing Credibility. Some time ago, there was an article from an author on Medium, generally stating that the value of Data is overrated, and that at times, hunches stemming from Design professionals, are the most ingenious device and effective path when it comes to crafting product solutions. In the same vein, I’ve been asked quite a few times before in the past, particularly in the context of interviews, what do I do when I don’t have much data or insights available. In this particular situation, how do I build or craft a solution, based on a limited amount of information. There’s quite a few elements to address in these assumptions and questions. Firstly, Data is not overrated in any capacity, shape or form. Used effectively and synthesized properly, it enables Designers and their teams to truly understand the problems they’re trying to solve, their users (and their journeys), and how accurately the proposed solutions are addressing the pain points.
Data in itself, is only as useful as what you make of it, and that typically entails synthesizing the information, on topics including behaviors, trends, among many other nuggets of information, and allowing for these nuggets to permeate across the solution being devised. These are nuggets that can also be found as teams go through different layers of research, which ties itself with the question pertaining to the lack of data or insights. The data or insights are always available, sometimes insufficient in terms of volume as one may want or need, but Designers and their teams can and should be agile enough to seek information from whatever sources they can devise. This includes Market research (competitive analysis for instance), internal (and external) surveys, or capturing data from FAST UX exercises, anything that will enable and substantiate the journeys they’re trying to build.
As tempting as it may be to drive solutions based on hunches, Designers are not typically the ultimate users of the solutions they are crafting. Neither are their peers involved in the Product Design journey. And as experienced as a Design Professional may be, particularly seasoned professionals who have accrued insight, process establishment, pattern recognition, documentation and deployment experiences, ultimately one has to realize that solutions, while hopefully built with a Long Lasting perspective in mind, they are also built in a specific moment in time (solutions crafted in the early 80s for instance, such as the IBM First generation released in 1981, while relevant in certain aspects, in many others it is not, the context itself of utilization of that machine has changed). Solutions, while ingenious and long lasting, also solve problems at times very specific for a certain timeline, for the social-economical needs of people of that time. As Society, Economy, Technology shifts, so do user behaviors. Hunches or self proclaimed opinions that something worked in a certain context with certain users, may no longer be relevant in a different context, since users expectations have changed, times have changed, society itself has evolved (or devolved). One thing is analyzing and recognizing trends, leveraging trend forecasting, analyzing data and making informed decisions on which direction to go, based on research that substantiates that decision. Making decisions based on hunches, particularly when it comes to Product Design, can be a costly endeavor, one that teams have to be ready to account for, particularly if those hunches don’t produce worthwhile results.
Another aspect of working with data lies in the establishment of credibility. Design has had a lengthy journey of establishing itself as a discipline that goes far beyond the definition of a visual language. It actually involves a process anchored in research, data, iterations, psychology, and indeed the establishment of an aesthetically relevant solution, but this last component is merely a part of that larger journey. Data substantiates decisions, and just as importantly, informs the path that the Product Design teams embark. The issue with the topic of Data is that at times, professionals equate this term with validation efforts coming from users, and seem to forget that Data is harnessed from many different sources, and not solely from Usability Testing sessions. Below are some of the sources and how those sources can empower the Design process itself.
Data Analytics. Using tools such as Full Story, Pendo, Google Analytics, we get an understanding of how users are going through flows, but just as importantly where errors, friction and opportunities lie. These metrics aid us with Onboarding strategies, Conversion processes, finessing overall flows, ultimately enabling us to build long lasting relationships with our client base.
As an example to this point, I recently had the opportunity of tackling the onboarding journey for a Fintech company. This journey which had been already iterated upon frequently, was still a topic of discussion. The contention around the topic was made the more apparent through Analytics, Metrics and observing users behavior in the product itself. Understanding where users drop off, where they spend the most time in a particular flow, identifying if there is clarity or not to what they’re doing, is fundamental to not only diminish friction and increase value (heuristic analysis looks at: value, clarity, friction, distraction and relevancy), but also and just as importantly, to perpetuate engagement. The wealth of knowledge one gets from Data Analytics is priceless.
User Reviews & Ratings. Compiling, documenting and synthesizing reviews from our applications on app stores, not only provides a clear understanding of the footprint of the applications themselves, but from a qualitative perspective, enables the capture of insights, pain points and opportunities.
In the past I had the opportunity to test this for a fact when I worked on an Event Conferencing application, which had its own IOS, Android, Blackberry, Desktop and Web experiences. Compiling the ratings and the reviews/comments from the different stores in which this product existed, allowed to surface the disconnect that existed across the product experience itself. Features that existed in a certain platform, versus non existent in others, with no apparent explanation as to why, coupled with performance issues, all of of these points of data surfaced by reviews and ratings, served to illustrate the point that a holistic approach to Product Design was imperative. And that a closer relationship between teams was fundamental, if indeed the product was to survive and craft a distinctive voice in the market.
Customer Support. The Customer Support teams interact with clients & users on a constant basis. They are able to document requests, but also identify persistent issues, aspirations and therefore opportunities to be pursued (or at least investigated). Their contributions are documented across the shaping of Personas/Characters, but also during definition of Empathy Maps, and User Journeys themselves.
Customer Support teams are one of the most important partners during the Product Design journey. As the statement clearly establishes it, they, alongside Sales teams (even if these later ones interact with clients on a different journey), have the supple opportunity to interact with clients/users, therefore understand their expectations, behaviors, friction points and ultimately frustrations. Their contributions, in the shape of interviews, surveys, data they can provide, both qualitative (insights) and quantitative (metrics) is fundamental. I’ve recently been able to collaborate closely with a Customer Support team in defining an Enterprise level application. Their insight into client’s behaviors, repetitive patterns, and predicting paths moving forward was instrumental in both Product and Feature Design Strategy.
Market Research. Market Research, which includes Competitive Analysis, Direct and Indirect, allows us to understand the principles of Jakob’s Law (what are users expecting from other product usage), but also identify patterns, behaviors and gaps in product usage (and user flows/expectations).
Market Research is frequently reduced to competitive analysis. And quite frequently I’ve witnessed teams where once the competitive analysis is done, that’s all the research that is done on the market itself. While this direct competitor analysis is fundamental, one must never forget what drives users behaviors and expectations. It’s at times presumptuous to assume that users solely expect some behaviors and features from a competing product to be replicated in one’s own. The lesson here is: do look at the immediate market, key players, but also understand behaviors, journeys, since they inform other products that are in the periphery, which inform how users go about consuming information that is at times fundamental for what they do in your own product. This is something that I once again experienced recently, and that should never be discarded, since it has impacts on performance, task management and ultimately quality of output.
Usability Testing. Usability Testing, through moderated and unmoderated testing sessions, but also through an array of methods which include AB Testing, Clustering Qualitative Comments, Surveys and Questionnaires, Eyetracking Studies, Desirability Studies, Card Sorting, to name but a few, allow for data to surface and impact decisions when it comes to Product Journeys (and understanding our users themselves).
Testing, testing and more testing. Without testing, solutions are really nothing but a very good intention that may or may not pierce through the core of a problem statement. It’s a phase that, no matter where in the process one finds themselves in, it always informs if the direction that is taking shape is sensical or not. All these techniques & methods, should empower the teams to understand the journeys they’re asking their users to embark on, and their level of receptivity. Usability Testing is a colossal element of value, but when used with other sources, such as the ones described above, it’s a Herculean device which can potentiate the rendering of a solution that is truly impactful, but also educate the organization itself, on the process that is taking place.
Reality Check. Data for some reason has created these factions, where on one hand there’s a group of voices which claim that it powers sound solutions, that address and solve actual problems. There’s however another faction which claims that Data reduces the capacity for inventiveness or more ingenious ventures. I disagree with this later assessment. Data, much like I wrote above, is but what we make of it. I don’t mean its manipulation, I mean how it gets consumed, utilized and prioritized. Understanding its place, marrying it with points of view, also with different layers of research, which are themselves more data, all serves the purpose of enabling Design Teams and their Cohorts with the essential tools to fabricate solutions which abide to Dieter Rams’s principles of Design, and just as importantly, delight the users they’re intending to capture. And that alone is priceless.
I’ll conclude this article with a quote on the topic of data from Sir Arthur Conan Doyle:
“It is a capital mistake to theorize before one has data. Insensibly one begins to twist facts to suit theories, instead of theories to suit facts.”
