Registration Closes Oct. 3rd for My Final 10-Week Training Seminar of 2021
Designing Human-Centered Data Products is back, but space is limited. Work with me and a small group of data product leaders who want to learn to build more useful, usable, and indispensable analytics and ML solutions. Live sessions begin Oct. 4, 2021. Details/register

073 – Addressing the Functional and Emotional Needs of Users When Designing Data Products with Param Venkataraman

Experiencing Data with Brian T. O'Neill
Experiencing Data with Brian T. O'Neill
073 - Addressing the Functional and Emotional Needs of Users When Designing Data Products with Param Venkataraman
/

Episode Description

Simply put, data products help users make better decisions and solve problems with information. But how effective can data products be if designers don’t take the time to explore the complete needs of users?

To Param Venkataraman, Chief Design Officer at Fractal Analytics, having an understanding of the “human dimension” of a problem is crucial to creating data solutions that create impact.

On this episode of Experiencing Data, Param and I talk more about his concept of ‘attractive non-conscious design,’ the core skills of a professional designer, and why Fractal has a c-suite design officer and is making large investments in UX.

In our chat, we covered:

  • Param's role as Chief Design Officer at Fractal Analytics, and the company's sharp focus on the 'human dimension' of enterprise data products. (2:04)
  • 'Attractive non-conscious design': Creating easy-to-use, 'delightful' data products that help end-users make better decisions by focusing on their needs. (5:32)
  • The importance of understanding the 'emotional need' of users when designing enterprise data products. (9:07)
  • Why designers as well as data science and analytics teams should focus more on the emotional and human element when building data products. (16:15)
  • 'The next version of design': Why and how Param believes the classic design thinking model must adapt to the 'post-data science world.' (21:39)
  • The core competencies of a professional designer and how it relates to data products. (25:59)
  • Why non-designers should learn the principles of good design — and how Fractal’s internal Phi Design System helps frame problems from the perspective of a data product's end-user, leading to better solutions. (27:51)
  • Why Param believes the coming together of design and data still needs time to mature. (33:40)

Quotes from Today’s Episode

“When you look at analytics and the AI space … there is so much that is about how do you use ... machine learning … [or] any other analytics technology or solutions — and how do you make better effective decisions? That’s at the heart of it, which is how do we make better decisions?” - Param Venkataraman (@onwardparam) (6:23)

“[When it comes to business software,] most of it should be invisible; you shouldn’t really notice it. And if you’re starting to notice it, you’re probably drawing attention to the wrong thing because you’re taking people out of flow.” - Brian O’Neill (@rhythmspice) (8:57)

“Design is kind of messy … there’s sort of a process ... but it’s not always linear, and we don’t always start at step zero. … You might come into something that’s halfway done and the first thing we do is run a usability study on a competitor’s thing, or on what we have now, and then we go back to step two, and then we go to five. It’s not serial, and it’s kind of messy, and that’s normal.” - Brian O’Neill (@rhythmspice) (16:18)

“Just like design is iterative, data science also is very iterative. There’s the idea of hypothesis, and there’s an idea of building and experimenting, and then you sort of learn and your algorithm learns, and then you get better and better at it.” - Param Venkataraman (@onwardparam) (18:05)

“The world of data science is not used to thinking in terms of emotion, experience, and the so-called softer aspects of things, which in my opinion, is not actually the softer; it’s actually the hardest part. It’s harder to dimensionalize emotion, experience, and behavior, which is … extremely complex, extremely layered, [and] extremely unpredictable. … I think the more we can bring those two worlds together, the world of evidence, the world of data, the world of quantitative information with the qualitative, emotional, and experiential, I think that’s where the magic is.” - Param Venkataraman (@onwardparam) (21:02)

“I think the coming together of design and data is... a new thing. It’s unprecedented. It’s a bit like how the internet was a new thing back in the mid ’90s. We were all astounded by it, we didn’t know what to do with it, and everybody was just fascinated with it. And we just knew that it’s going to change the world in some way. … Design and data will take some time to mature, and what’s more important is to go into it with an open mind and experiment. And I’m saying this for both designers as well as data scientists, to try and see how the right model might evolve as we experiment and learn.” - Param Venkataraman (@onwardparam) (33:58)

Links

Transcript

Brian: Welcome back to Experiencing Data. This is Brian T. O’Neill. Today we’re going to talk about fractals. Actually, we’re not going to talk about fractals, but I am going to talk to my friend—I hope I can call him a friend—Param Venkataraman. He is the Chief Design Officer of Fractal Analytics, a services company that works on analytics, data science, AI, machine learning types of products and solutions for their clients. So Param, welcome to the show.

Param: Thank you, Brian. Thank you for inviting me, this is absolutely exciting because you’re one of those rare species who’s working on the intersection of design and analytics—

Brian: Yeah.

Param: —just like we are. So, I mean, it’s super exciting, and I’m really happy and humbled to be here invited on the show. Thank you.

Brian: Good, good. Yeah. Well, we have lots to talk about here. I wanted to first talk a little bit, just address the audience here—I guess the whole show, I’m supposed to be addressing the audience—but why do we have a chief design officer on the show today? Obviously the show, I have a lot of guests from data science and analytics leaders, and I’m always interested when I find a design leader who’s focused in the analytics and data product space because it says something about the culture is changing.

Why is this company doing it this way? Why is design important at this place? And that’s what I wanted to dig into today because I think, as you were saying, design is still a fairly new thing, especially in some enterprise companies where there may be a little bit behind on digital design, especially in machine learning, AI, and analytics space is still fairly new. And so that’s why I wanted to have is to get your perspective on that. You come out of IDEO, you’ve had a lot of great experience here, and now you’re running a team.

So, my first question is, why did the CEO decide to hire—like, what happens that a CEO of a services company—which is what Fractal Analytics is—how does he just wake up and decide that I need a chief design officer? Most people think CDO and they’re thinking chief data officer on this show, but can you tell us about why he felt like I need to have a leader, I need to have this be an executive-level title at my org? What happened, and how did you come there?

Param: Yeah. Sure. Great question and I’d love to see my boss answer that question, but let me take a crack at that. So, I think in the journey of Fractal over the last 20 years, I mean, I’ve been here for the last two years, but from what I’ve heard about the history of the company and how it’s grown, there’s been a revolution of analytics over these 20 years—as an industry and also Fractal—learning to get better and better, and constantly look at what’s the next, what’s the next, what’s the next. The genesis of Fractal was always this idea of powering every human decision in the enterprise.

That’s been one of the ideals that the founding members of Fractal thought about when they started Fractal. And as they’ve grown, it has always been about seeing how can analytics and data science power that decision, every decision. And so I think at some point of time, there was this realization, or a feeling, or sort of idea that if you have to power every human decision, not just with data science and algorithms, but also how do you think about the human dimension in a much more sharper and much more specific way? So, powering every human division in the enterprise can’t be fulfilled if you really don’t go sharply focused on human decision. That is setting the genesis of it many, many years back.

Our group’s CEO, Srikanth, he’s always been passionate about psychology, human behavior, understanding why people do what they do, and all those themes have been there, I think, in his mind for a long time. And so I think a few years back when Fractal found this company called Final Mile—which was founded about, I think, 12 or 13 years back—a few years back, Fractal acquired Final Mile. And Final Mile is a behavioral science—and it is a company that’s been founded on very, very cutting edge behavioral science principles. And behavioral science, as I’m sure you understand, is really about understanding why people do what they do and really getting to the heart of the explainability of that. So, that was the first concrete step in that direction in terms of building a capability with design expertise in Fractal.

And even before that, there was a realization that you have to really look at AI not just from the lens of AI, but it’s about bringing AI, engineering, and design together. And that is when AI is truly effective; it truly does what it’s meant to do and not just a good algorithm that technically does the job but doesn’t create impact or doesn’t create an outcome that we want. So, I think that was the genesis, and then with the acquisition of Final Mile he started bringing in behavioral science into AI, and engineering, and design. And then I joined about a couple of years back to strengthen that expertise and that capability, and we started building out a bigger team with behavioral science, and human-centered design, user experience design, interaction design, all the different sort of design specializations. And so now we’ve grown to a team of about 50-plus people as we speak, with expertise in all these different design disciplines. So, that’s the genesis and that’s why, I guess, I have the job that I have.

Brian: Got it, got it. Can you explain, in simple terms—I think for some of the data leaders were listening to, they’re probably thinking, “Oh, well, we might have designers, but they work in marketing, or they work on the apps that—you know, the digital side of our company.” And they’re probably design curious. [laugh].

Param: Yeah.

Brian: Could you explain in, kind of, simple words, what is design in the context of these analytics, and data products, and AI, beyond user interfaces and data visualization, which is where most people’s minds immediately jump, is that it means graphs and charts and that part of it? What’s the business value? If I went out and hired a design leader like you and came in, what would I get for that? What would be the change that I would get? Can you talk about that a little bit, the business impact that design has?

Param: Sure. Great question. The idea was that, so when you look at analytics and the AI space—and it’s really growing like crazy—there is so much that is about how do you use—whether it’s machine learning, whether it’s any other analytics technology or solutions—and how do you make better effective decisions? That’s at the heart of it, which is how do we make better decisions? That decision might be, let’s say, a consumer who’s using an Apple Watch and it’s time to make better health decisions.

It could be some kind of a data science algorithm that’s running inside an enterprise, helping make marketing decisions, let’s say, looking at demand generation for the next quarter, or for the next year, and so on? And of course, I mean, that’s just a few of them, but there could be so many other varieties. When we talk about design here, what we mean is two parts of it: one is, how do you frame the problem that you’re framing? When you frame the objective of any analytical solution, or a project, or a product, what problem are you solving?

And you can look at it through the lens of data, which is what data do I have, and therefore, what kind of an algorithm or what kind of an analytical solution can I create, or you can look at it from the vantage point of who am I making this for? What do they actually need? Why do they need it? And trying to get to the heart of the user need. The end-user need, not the stakeholders’ need.

Traditionally, I think analytics, especially enterprise-focused analytics was very—and I think still is—is very skewed towards stakeholder needs. I think now it’s beginning to mature and go to that point where we are starting to think about the actual end-user, the business user—or even the consumer, in many cases—and trying to think of how do they think about it? Why should they be using this product, or this solution, or this dashboard, or app, or whatever it is that you’re creating? So, the first part of it is about framing the problem from an end-user’s perspective, or from a human being’s perspective. And the second part of it is, how do you create the right solution which is, A, it’s easy to use, it doesn’t need a manual or a training, B, it should be delightful, it should do the job in the simplest and the most delightful way.

I mean, to the extent that we call it an attractive non-conscious design, which is that it should be almost invisible. In some cases, completely invisible, and in some cases, the user doesn’t even realize that he or she is doing what they’re doing. That’s the Holy Grail. Of course, you can’t achieve that all the time, but the idea is to try and achieve make it as simple and effective as possible.

Brian: There’s an echo here happening on the show right now. They’ve heard me talk about this as well, I think, especially in the business context, in business software. Most of it should be invisible; you shouldn’t really notice it. And if you’re starting to notice it, you’re probably drawing attention to the wrong thing because you’re taking people out of flow. I do want to go back to the part one of what you said about the framing and making it for the stakeholder versus the user.

So, in the enterprise space, sometimes our stakeholders are the users, but I think there’s a really important distinction here, which is—and maybe you can correct me if you have a different experience, but the distinction here that matters is, let’s take for example you’re building something for, I don’t know, a purchasing department or procurement, some kind of tool for them, and you’re dealing with the head of procurement who’s telling the analytics group about here’s all the numbers I need so that my staff can better decide how much should we buy printer paper for or whatever. And the difference here is that the head of the department may know the best theoretical way to do that—like, you should be pricing with the following data points, like, we know what we think we want. The actual person who decides how much to buy paper for in procurement may have their own idea about how to do that. And so this is the interesting difference is, what does the person want to do? What is the change they’re willing to make with data?

How much decision support will they take from a piece of software versus what quote, “They should be doing?” That’s the distinction is helping unpack that, and sometimes it does mean you got to bring the manager together—who may not ever touch this interface—and the actual user and they need to get on the same page about, “Hey, that’s not really how we buy paper. We actually buy paper like this, and I would never look at last year’s cost because whatever.” Is that kind of what you’re talking about here when—

Param: Absolutely.

Brian: —you talk about—

Param: Absolutely.

Brian: Yeah.

Param: Absolutely. So, I think they are—you know, to kind of unpack that even further, right, I mean, there is a decision-maker kind of a stakeholder, and I think there are some stakeholders who are sometimes wearing that hat, but at some times, they’re also wearing the hat of the end-user or one of the end-users. So, I think, if you think about it only from the vantage point of the stakeholder as a decision-maker, then of course, he or she has a bunch of biases because he or she is signing the check and saying, “Go do this project,” or that I think we need to build a solution in that company. And of course, I mean, there is an important business need that stakeholder is trying to define. And that’s important to understand, but it’s not enough to—it’s important to not get limited by that or get biased by that and to start looking at, “Okay, what is the business need, but also what is the end-user need? And what are the stakeholders as users, and what do they need?”

And think about that whole thing as an ecosystem of people who need a bunch of things. And the unpacking even further is, every one of those people has a set of functional needs, and every one of those people has emotional needs. What are the things that we focus a lot on is trying to think about the fact that every human decision is actually made with emotion; it is based on emotion. It is not based on rational facts, and evidence, and all of that stuff. We use rationale or evidence to justify why we did what we did.

That’s post-facto. But when we’re actually in the so-called ‘hot state’ of decision making, we’re actually making the decision from an emotional standpoint much more than functional. So, that’s why we try and look at—we do look at both, and then we see what drivers can we influence or what can we work on, which is much more aligned to their functional and emotional needs? The more we can land in that emotional space, the chances of adoption, the chances of acceptance and engagement is going to be higher.

Brian: Yeah, yeah. I can’t agree with that more. And I think that this is where a lot of teams that have a homogenous makeup, some of these enterprise data teams that have a very one-world view on things: it’s analytical, it’s data-driven, and the promise of all this stuff that sounds very utopian, almost. And you’re very right that you wonder if teams listening to the show are wondering why some—like, “It’s so obvious. The data says we should do this, and yet why did the CEO go this way?”

It’s like, what’s in it for the CEO? What’s the personal risk to him or her? What are the other downstream impacts that could happen there? How’s it going to make him feel if he looks bad? There’s all these other considerations that may have gone into that, which maybe you could have answered with the solution, maybe you can’t.

The point there is, have you even tried to tease them out and address them in the way you presented your evidence or your decision-support information? This is all part of it. So, I’m a hundred percent with you on that.

Param: You know, I thought it might good to give an example of this. So, if you look at the world of sales reps, sales reps are in the front line, they’re going and meeting the actual customers, whether it’s in the pharma industry, or whether it’s in automobile, or any other industries, I mean, they are bunch of people who are really keeping the business running on the ground. And they’re mostly on in the field, on the—at least pre-COVID, I guess, that was a reality at most [unintelligible 00:14:01]—but yeah, the point is, they’re in the front line. Back in the headquarters or back in the manager’s office, the managers want to know what’s going on with the sales rep and they want to be giving sort of top-down directions in terms of what do we want to focus on this quarter? Or this week? Or this day? What kind of customers do you want to be focusing on? What should you tell them? What should be the messaging? What should be the prioritization? What is the relationship information that you have about this customer, and therefore, how can you engage them better and so on and so forth?

And then you also want the sales rep to give you feedback about what do they do. And did they actually do what they were supposed to do, or whatever, whatever, and how did that go? Now, it might seem like the best thing to do is give them a digital device and ask them to track some data, feedback, some of the things that happened after that meeting. It makes a lot of business sense to do that, but from the sales reps standpoint, he or she is feeling like, “You know what? My boss is now monitoring everything that I’m doing.”

That’s the emotional need, which is getting created because of this new tool in their hands, which is now suddenly feeling like a big brother. And so how do you deal with that emotional need and emotional state? And therefore, how do you think about the digital solution that you’re making? Because if you don’t solve for that, guess what’s going to happen? He or she is going to start gaming it, he or she is going to start figuring out workarounds, he or she is going to start—not because they want to lie or because they’re bad people, it’s just because it’s just fear. I mean, that fear makes you do certain things that you otherwise would not do. And so, how do you design something that takes into account that kind of fear and that kind of emotional need?

Brian: I’m with you there. And I think if you’re not out there, regularly interfacing and getting that customer exposure to the people that are—in customer here, I’m really talking about a user here; in this case, it could be these internal sales reps—if you don’t know what it’s like to be them, it’s really hard to routinely produce solutions that are going to be used. You might get lucky occasionally, where especially when the risk is super low, and maybe nobody cares, but something like this, if you’re paid on performance and all this, every phone call is going to sound like it went great. And like, “Yep, still considering purchasing.” They’re not actually logging the stuff that you may want to use to make better decisions. And so I’m with you there.

Let’s talk a little bit though about where things go wrong here. So, design is kind of messy, and when I do my training seminar, one of the first things I talk about is like, there’s sort of a process here, but it’s not always linear, and we don’t always start at step zero, and you might come into something that’s halfway done and the first thing we do is run a usability study on a competitor’s thing, or on what we have now, and then we go back to step two, and then we go to five. It’s not serial, and it’s kind of messy, and that’s normal. It’s messy if you’re used to things being very procedural. It’s normal for design, but I usually frame it as messy because if you’re coming from the data perspective or the engineering perspective, it kind of has a messy feel to it.

So, I want to hear from you, where do you think data science and analytics teams need to adjust their thinking to accommodate design? But I also want to hear, where do the designers need to make some changes about working with data? What do they need to know that’s different? So, I don’t know if you have opinions on both of those sides, but I think we all could probably work towards the middle a little bit more. What’s your take on this?

Param: Absolutely. I think the end sentence that you said was absolutely spot on. We do need to both try and figure out what’s the way in which we can understand and work much closer to the so-called other side in a better way. So, a couple of learnings. One is whatever little—and a few years back, more than two years back, I had no clue about data science and analytics; it was a new world for me.

I’d worked in technology before, but data science is a whole different ballgame. So, as I’ve now got acquainted with it—and I’m still learning a lot as we speak—one of the things that I’ve learned is actually that data science itself is very iterative, and is very—it’s not a linear thing, just like design isn’t. Just like design is iterative, data science also is very iterative. So, there’s the idea of hypothesis, and there’s an idea of building and experimenting, and then you sort of learn and your algorithm learns, and then you get better and better at it. It’s exactly what we talk about in rapid prototyping with design.

It’s also about how we frame problems from a—and then there’s an iteration and understanding and framing those problems as well, and reframing them. So, there’s a lot of parallels that I think there are—therefore, I think that the design world is not that different from the data science world from that perspective.

Brian: That’s a really good observation. And I agree with it if you’re talking about the work that I do… that I do—when I’m saying, ‘myself’ as a data scientist, which I’m not—yes, even building models, I got to—I remember when one of my students one time framed this is cakes, it’s like, I got to build 20 cakes before I can figure out if there’s actually a workable model here. And so there’s a lot of experimentation going on, which is the design part. But when you go up the level to, okay, I built the thing, I built the model, I got it right. Now, I give it to somebody, they use it, and then I go on to the next project.

At that point, there’s this very analytical perspective on how it’s supposed to be used. So, there’s two framings there. There’s the individual, kind of, data science work, the really technical part of it, and then there’s the delivery to the customer part, which to me is not–and I want you to challenge me on this—my general perception is that the thinking is, “Duh, the data is so obvious; why would someone not use this?” It’s very just like, “How could you not want this? How could you not use it? What do you mean, it’s not easy to use? Look at the screen. It’s obvious.”

Param: I was actually going to come to that, which is that I think at one level, it looks like it’s very similar, and there are some there are similarities, and—I think it’s a—as you were speaking, I was realizing that there is a process aspect to it or principles or aspect to it, there are a lot of common principles like iteration, experimentation, prototyping, whatever you want to use the word, or framing-reframing—hypothesis-building and framing and reframing, whatever that be. So, these are principles that I think are similar. I think where it differs is in probably the mindset piece, which is that how design comes at it is from fundamentally the human angle, which is, “How do we think about the human dimension of that problem?” It’s almost consciously saying, “Let’s hold on, let’s not think about the business perspective, or the technology perspective, or the operational perspective as yet.” When you’re starting to frame the problem, you start with, “Okay, let me put all of those aside, those are important, too, but for a moment let’s think about it from the human dimension.”

And once you understood that and reframed it from that vantage point, then you start thinking about, “Okay, if this is what the end-user cares about, what’s the business potential here, or the viability here? And what’s the technology and the operational feasibility here?” So, it’s a question of sequencing, I guess, at some level. So, I think that’s the big difference, which is that I think the world of data science is not used to thinking in terms of emotion, experience, and the so-called softer aspects of things, which in my opinion, is not actually the softer; it’s actually the hardest part. [laugh].

It’s harder to dimensionalize emotion, experience, and behavior, which is, you know, extremely complex, extremely layered, extremely unpredictable. So, I think the more we can bring those two worlds together, the world of evidence, the world of data, the world of quantitative information with the qualitative, emotional, and experiential, I think that’s where the magic is.

Brian: Talk to me about the design shift here. You even mentioned on our call, you said, “I’m not”—I don’t know if you said, “I’m not convinced,” but you said something along the lines of, “I’m not convinced that traditional design methods are necessarily the right way to approach designing for analytics and data science.” Can you dig into that a little bit? What did designers need to change? And if there’s something about the design process itself that needs to change to get us better outcomes with data products? What were you thinking there when you said that?

Param: Yeah, absolutely. I think the world of design is definitely going through a shift in many ways, even outside of the context of this conversation, in terms of how design applies in the data science world. Design has started maturing over the last ten, twenty, thirty years. Especially in the last ten years, there’s been a humongous amount of adoption of design in different industries. In the data science and analytics world, of course, it’s very, very nascent.

But with that evolution, I think a bunch of people like us who’ve been doing this for some time have started thinking about what’s the next version of design at a meta-level. And that’s one of the reasons why I actually joined Fractal and I was super excited about what we’re doing here, which is thinking about can we reimagine design in a post-data science world or in a post-data world? So, that’s something that I think is just scratching the surface; I can’t say that we’re completely cracked it. But there are a few things that we’re realizing: one is that traditional design process, the classic design thinking model—which is empathy, then reframing, then synthesis—synthesis and then reframing and then ideation, and prototyping, and detailed design, whatever—that sort of classic process, it doesn’t necessarily have the same steps in that chronology in the post-data science world. If you have a lot of data about what your customers or what your users are doing and how they’re behaving, whether it’s episodic data, transactional data, longitudinal data, whatever it might be, then you can actually start doing a lot of stuff upfront.

You can actually maybe even start building some prototypes based on some hypothesis right at the beginning. And you can use that to actually start framing some of the needs and looking at what empathy means, with some actual real-life data, I mean, as opposed to traditionally, how we might have done it in a qualitative way, the pure qualitative way, which is going out and meeting people and understanding why they’re doing what they’re doing. But again, I think the answer is not this or that. I think the answer is somewhere, it’s about mixing mixed methods. I think, for me, that’s really the best. It’s about trying to find out what’s the best of this, what’s the best of that, in context to whatever [unintelligible 00:24:16] you’re trying to solve.

So, that’s one example. The other example is, of course, also about how you have the ability to iterate and go through different sort of experiments and be able to use that in the real world and learn from those experiments, and then be able to continue to inform your training or your solution design as you might move forward. So, a lot of these things are changing because of this possibility of data science which wasn’t there before, maybe ten years back or more. So, I think as designers, it’s a whole different new dimension that we could not think of earlier. And then of course, there’s the aspect of technology and experience also, which is especially in enterprise context.

I mean, the design for enterprise is a relatively new thing, and we’re trying to think about how does human decision-making happen in the enterprise context which is different from the world of consumer context. And I often hear that in the enterprise world decisions are much more rational and much more logical, and so on. And again, I sort of will challenge that because it’s ultimately human beings who are making decisions. It doesn’t matter whether it’s an enterprise context or a consumer context. But all the changes is about those underlying—I mean, mental models are different, of course, [unintelligible 00:25:28] world versus an enterprise world.

And the context is different, so here, the context is maybe a boss that could evaluate your work or some performance that you’re answerable to your shareholders, or to someone else, and that drives some of your decisions. But the point is, I think the fact that we are looking at the enterprise world and looking at how does design play a role there as opposed to designing a consumer product, that also has some interesting opportunities for the way we think about our design process. So, those are some early realizations that we’ve been having so far.

Brian: I don’t want to get too deep into this particular topic, but when you’re hiring designers, are you starting to look for a different skill set? Or are you like, “No, I’m still looking for a classically good designer. The data domain we can teach and nurture that within our thing?” Or, “No, I actually need a different kind of designer. We really want a culture that looks like these people, not like those people.” What are you looking for there? Or is nothing, nothing different?

Param: I mean, I guess at the heart of it, the core skills that are critical, or the competencies would be empathy, curiosity, the ability to understand the emotional aspects of why people do what they do, thinking about experience, and being able to imagine experiences and design for that. So, those core, core skills will not change, I think, over a longer period of time. But that being said, in the context of your applying design, as I said, in enterprise and analytics and AI context, there are a few things that I’m realizing are interesting opportunities. So, for example, recently we’ve just about hired someone who used to work in the area of tax consulting for five years, and then she’s made a career shift into design by going to design school after that. And the moment I met her and saw that resume, I was excited because here’s something that’s out of the ordinary, here’s something—it’s a classic sort of T-shaped skills are we looking for, at the intersection of two very, very, usually unlikely disciplines.

So, I mean, I think we’ve been a bit lucky in finding some of these interesting mixtures of disciplines. And the more we find that the more we gravitate towards that. But of course, there are also a lot of people like me who’ve come from a more traditional design background and have had to adjust and learn the world of analytics and enterprise as we go.

Brian: Got it. Got it. Let’s talk about scaling design as a practice. So, I think you’re said you’re growing from about 50 staff to about 80. Does Fractal see design growth as something happens through the hiring of people only, or is it the hiring of people and it’s also training our non-designers to use design in their work? Is it both of those, or is it really more about hiring staff, and we really want specialists on every produ—you know, quote, “Specialists,” meaning designers on these data products, and it’s really their job to own that. How do you guys frame that? Or is it a bad question?

Param: No, great question, and it’s spot-on in terms of how we are thinking about it, which is, what we realized early on is that our mission is to bring design and behavioral science into every problem that we solve at Fractal. That’s the reason why this department exists. It is not to just, let’s say—I mean, we of course, want to ship a bunch of projects, or products, or whatever it is—applications—and that’s the means to that vision, but the point is, that larger vision is that every problem that we solve, every conversation that we have at Fractal will have that aspect of human dimension in. So, that’s the long-term goal, but the moment we state that long-term vision, what’s very clear in that is that even if you were to grow a large experience team, even if you were to grow to 500 people, which is fairly unprecedented in the design world, then it is still not going to be enough because Fractal would have grown to, let’s say, 10,000 people. I don’t know.

So, what we realize is it’s not enough if the designers and the behavioral science experts are doing this; it’s important that we also have non-designers learn this way of thinking or doing, to some extent, I mean, at least to a minimum. Just like I think it’s important for me to understand or to be able to learn and apply AI and analytics in the world as we go forward. And so democratization is one of the key pillars for how they’re building the practice and the scalability in practice. In fact, there’s a huge focus on it. In fact, last year, we started working on a design system which, from what I have heard, is probably the first design system that is exclusively made for data science and analytics.

Most of the other design systems that we’ve seen in the world out there are either for consumer products, there are a bunch of design systems that are for enterprise also, but still in a more broader sense for software. But we are the first design system is called the Phi Design System—P-H-I—Phi Design System for specifically and exclusively designed for analytics and the data science context.

Brian: I don’t think a lot of our audience probably knows what a design system is. Can you just explain that first and then continue.

Param: So, a design system traditionally is, think of it as patterns and frameworks that allow you to create repeatable solutions that are of higher quality. That’s the traditional notion of a design system. So, for example, Google has something called Google Material Design, which is essentially a system that helps all the Android mobile applications have a similar user experience, and user interface, and a similar sort of approach in terms of interaction design. And therefore, the users, irrespective of what app you use, or who has made that app, the user has a similar experience, and also the developers who made that application also will be able to—they don’t have to reinvent the wheel; they can start with something that’s already thought through, and of a higher quality, and that is faster to develop as well. So, that’s the traditional notion of a design system, which is essentially patterns, repeatability, and faster problem-solving at the heart of it.

What we are doing is actually, there are two dimensions to our design system. One is the problem framing of it which is, how do you think about democratizing the way we frame the problems that you’re solving that I spoke about earlier? If you don’t frame the problem in the right way, you might have the best solution, it’s not going to matter because it won’t be solving the real problem. So, what we realized is that the design system needs to have two parts. First part is the, how do you frame the problem from an end-user perspective?

And therefore we’ve built a system or toolkit for non-designers to learn how to understand easily, how to frame problems from an end-user perspective and not just from a data or from a business, or from a domain, or a data context. So, that’s the first part of the design system.

The second part of the design system is the solution part, which is similar to the more of the traditional design system, which is patterns, component libraries, reusable libraries, and components, which will help you build analytical solutions with much higher quality of user-centricity, user experience, simplicity, ease of use, all that stuff, but specifically for data science and analytics. Then of course, it’s still early days. As you know, it takes many years to build a robust, scalable, solid design system. Google Material probably evolved over four to five years; we’ve been barely one year into that journey. We are still in a MVP beta stage. But I’m happy to report that we’ve had two Forrester Reports cover the Phi Design System, mention it, and we’ve been able to put it out there and start piloting some of those in some of the projects that we’re doing.

Brian: That’s awesome. Yeah, I look forward to watching that evolve. So please—oh, by the way, is it public? Is it something we can all see, or is that an internal tool, an internal system for your work?

Param: At this point, it’s an internal system for powering the work that we’re doing for all our clients, but as we evolve this, there will be versions of this that we will democratize and put it out there in the more public domain. And so happy to share that at that point of time, yeah.

Brian: Awesome, cool. This has been great. I know, we could go on for, [laugh] probably, a long time here to nerd out on this stuff, but I was curious if you had any closing thoughts? Or is there a question I didn’t ask you that you would like to get out to our listeners, people that are leading data product initiatives? What else do they need to hear from you and any closing thoughts?

Param: I would say this, which is that I think the coming together of design and data is very, very—it’s a new thing. It’s unprecedented. It’s a bit like how the internet was a new thing back in the mid ’90s. And it reminds me of that time because when the internet first came out in the public domain outside the military and the government, we were all astounded by it, we didn’t know what to do with it, and everybody was just fascinated with it. And we just knew that it’s going to change the world in some way.

I think data science, AI, this whole space is in a very similar space, in a very—I see a lot of [unintelligible 00:34:31]. And so I think the way to think about it is that design and data will take some time to mature, and what’s more important is to go into it with an open mind and experiment. And I’m saying this for both designers as well as data scientists, to try and see how the right model might evolve as we experiment and learn. So, I guess that’s the biggest message if I had to, sort of, pick one which is to experiment, be patient, and learn, and see where this goes.

Brian: Yeah, yeah. And just to take the idea just one step further, if I’m the head of BI or I’m the head of data science at an enterprise, this sounds interesting, I get the behavioral science thing, I can understand the promise of this. I don’t have a designer on my team. What should I do now? How do I take the first step with the resources I have now? Do you have a piece of advice about just to take the first step? What should they do?

Param: So, I would say two things: one, get everyone in your team to start going and meeting real users—the end-users that I was speaking about—and asking them a lot of qualitative question, which is open-ended questions around what they do, not what product you’re building for them. If you try and understand what their average day in the life is, or what goes on in their workflow, or whatever in that process, and try and think about more divergent questions and open-ended questions; you might start discovering things that you might not have otherwise encountered. So, that’s one specific action that I think everyone can take and it’s pretty straightforward. Just get out of your office space, or cubicle, or whatever it is, or your laptop, and just go and meet real people, real users.

The second recommendation would be to try and maybe sign up for a course online. There are a whole bunch of open online courseware on human-centered design, behavioral science, any of these sort of disciplines, and that also might open up your mind. And of course, books on these topics will also help. So, I think that might also give you a starting point for how to start thinking about this.

Brian: Awesome, awesome. Thank you for the advice. And where can people follow you? Do you have a website, or a LinkedIn or—

Param: Yeah, I guess I mean, LinkedIn is where I’m relatively active. I have a Twitter handle, which I’m not that active on, but it has been around for a long time. It’s called @onwardparam, O-N-W-A-R-D-P-A-R-A-M.

Brian: Got it.

Param: And I do hope to have a renewed website. At some point in time, I will publish that.

Brian: Awesome, awesome. Well, I will definitely link up your LinkedIn and the Twitter there. And Param, it’s been really fun to connect with you, and I look forward to hearing more about what’s cruising over its Fractal in the years to come. So.

Param: Thank you. Thank you, Brian, this has been a lot of fun, and I look forward to learning from you as well. Thank you.

Brian: All right. Take care.

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Subscribe for Podcast Updates

Join my DFA Insights mailing list to get weekly insights on creating human-centered data products, special offers on my training courses and seminars, and one-page briefs about each new episode of #ExperiencingData.