Designing a data product from the ground up is a daunting task, and it is complicated further when you have several different user types who all have different expectations for the service. Whether an application offers a wealth of traditional historical analytics or leverages predictive capabilities using machine learning, for example, you may find that different users have different expectations. As a leader, you may be forced to make choices about how and what data youâll present, and how you will allow these different user types to interact with it. These choices can be difficult when domain knowledge, time availability, job responsibility, and a need for control vary greatly across these personas. So what should you do?
To answer that, today Iâm going solo on Experiencing Data to highlight some strategies I think about when designing multi-user enterprise data products so that in the end, something truly innovative, useful, and valuable emerges.
In total, I covered:
When redesigning enterprise software, teams really need to use research-driven design to understand customer types and behaviors. Otherwise, you risk building a new mess that nobody wants to use. If youâre putting ink on the screen â if youâre choosing what goes into the interface â then youâre a designer ⌠You can do damage if you come in and start just changing things up without really understanding the people that use the platform, how long theyâve been using it, and the habits that users have formed while using it. â Brian (4:52)
With any project, teams need to be able to define what successful outcomes look like and how those outcomes are going to be measured. This needs to be established early â it needs to be in writing; it needs to be a team sport; it needs to be done with the stakeholders on the project; it needs to be a living document â because, chances are, by the time you launch something, things are going to change. â Brian (8:39)
Execution without strategy is expensive and itâs time-consuming. Youâre likely just going to build up more technical debt, youâre going to lose the trust of your sponsors and customers, and youâre going to shorten the amount of time and resource you have to go back and actually design something thatâs going to produce value. â Brian (9:23)
You have to understand the last mile at the beginning of the project: Who is the one thatâs deciding what value is? How is that being measured? What are they comparing it against? Itâs not about the output, itâs always about the outcome. â Brian (28:56)
Design is the responsibility of the entire team and not just the designer. Designers are always going to favor the user experience piece, and engineers are going to always want to make sure that the platform is technically feasible as well as other considerations. These are really good natural tensions that happen. But the entire team, designers and technical people alike, need to think about, âWhat does value look like for the customer?â If a product doesnât do what a user wants it to do then nothing else matters. â Brian (40:12)
What does it mean to design and build something thatâs really successful for customers? As a team, you have to decide what that means upfront. If youâre talking about it in terms of technology, then somethingâs probably wrong. No customer cares about what technology or platform was used behind the scenes. If theyâre a business user or just a normal user, they just want it to work correctly. People care about themselves, and the more you can support what they care about â instead of what you care about â the better off your design is going to be. â Brian (51:11)
Â
Hey, everybody, itâs Brian here. And today, my guest is me. I hope you will sit through another solo episode of the show. Today, I wanted to chat with you guys about user experience strategies for designing successful enterprise data products with multiple user types. If youâre on the mailing list, you probably saw my question, and I actually sent out a little poll to see what you guys wanted to hear about next on the show, from me in a solo episode, and this was the one that got the most votes. It was. I donât know, it was probably 70/30, option one, option two. So, this one won.
Before we jump into the episode, just a couple notes and things. Iâm hoping this comes out by, I think, January 26. If you havenât noticed, the show drops every two weeks on a Tuesday. And so far, this is episode 57, and I havenât missed one since I started this show. This week, I did have a little hospital medical emergency with my family, with my wife. Luckily, everything is totally fine, but it was just very, a fluke scare, so we had to run to the hospital and kind of screwed up the schedule for the week.
But I am committed to trying to get this out on time. And I just wanted to thank the people at HumblePod, especially Chris. Chris runs a podcast company that does all the audio editing and he helps with the transcripts. And heâs been awesome, and heâs been with me for quite some time here. So, if youâre thinking about starting a podcast, and you donât want to deal with all the audio editing, and all the logistical part of running a podcast, I really do recommend HumblePod. So, check them out. Itâs been great to work with them.
So also, just so Iâm actually just getting ready to jump into some private seminar training with a data science and analytics group. And so, if youâre an executive or leader whoâs trying to get to your team of data professionals, engineers, and data scientists, and BI people, delivering more useful, usable, valuable solutions to your customers, if you feel like youâre not quite hitting the mark on usability and really generating that value. Learning how to design better solutions is something that anybody can do if theyâre willing to do the work.
And design is not art, itâs a skill that can be learned. And so feel free to contact me if youâre interested in private training. I do also offer this seminar twice a week, itâs called Designing Human-Centered Data Products. Not twice a week; twice a year. And this seminar will be running again beginning March 15th, 2021. So, if youâre interested, just head over to designingforanalytics.com/theseminar and you can actually get on the early bird mailing list there, and Iâll shoot you a link as soon as enrollment opens for that. So, keep that in mind if youâre looking for some help. Without further ado, though, letâs jump into todayâs topic. So again, weâre going to talk about designing successful large-scale enterprise data products with multiple user types.
Today, Iâm mostly going to focus on ground-up scenarios, like net new, greenfield, whatever we want to call it, versus the redesign of existing platforms. Also just for terminologies, and some of these words, even, like, âdata products,â the definitions of some of these things-you know âbig dataâ still doesnât even have a good definition. For this conversation, Iâm primarily talking about B2B software, probably for a large organization-not necessarily-but weâre really talking about a B2B software application. Iâm going to kind of orient this conversation at a team thatâs probably building an internal application for a large company. So, this isnât necessarily a commercial software application. But some of these things apply regardless.
As you know, most of the work that I do, and the people that I try to help kind of come from two camps, some of you are working internally, servicing your operations, and finance, and marketing and all your different departments, and youâre an internal group, probably belong to IT or something like that. And then we have our software companies whose business is selling software of some kind or producing some value. Thereâs some differences there, but a lot of this could apply to both of these camps.
So, one thing with enterprise software redesigns, before we dive into the net new application creation headspace, I wanted to make one note about redesigns here, and this is that you really need to use research-driven design to understand customer types and behaviors or else you risk building a new mess that nobody wants to use. So, users may have the jobs that the designers-and that means you-of the service donât fully understand. And when I say designers, again, if youâre putting ink on the screen, if youâre choosing what goes into the interface, youâre a designer. You just may not be a professional designer, and maybe you donât know all the tools that go into that, but somebodyâs making those choices.
So, when you start changing stuff, especially with enterprise software, Iâm always curious, when I see an application for the first time, why is it the way it is, and sometimes youâll see things that just seem-as an outsider, you just donât really understand how that decision was made to make the thing the way it is; it doesnât necessarily mean itâs wrong. My point is, you can do damage if you come in and start just changing things up without really understanding the people that use this, how long theyâve been using it, habits that have formed, the reason it is the way it is. This is why research is so important because you canât just look at the interface and make judgments about the quality. Now, there are heuristic best practices that somebody can evaluate in terms of a quality standpoint for design, but there may be things that you just simply donât understand because you donât understand the work of the customer; you donât know how they make decisions with data, you donât know their workflow very well.
And so, âOh, weâre going to apply this new standard style for every chart and change all of them globally.â And you have no idea that maybe some customization was done somewhere specifically to support some kind of esoteric use case for this department that you havenât really ever spent time with, and so you donât understand the change that youâre about to impose on them all for the sake of improving the engineering, or the platform, or some optimization reason, or whatever it may be. So, just keep that in mind for if you are in the redesign camp, there. And then the second comment I wanted to make before I kind of jump into the greenfield scenario is if you have an application already, and youâre struggling to get users to adopt it, I do have a guide for you. Itâs called the Designing for Analytics Self-Assessment Guide, and this will take you through-itâll provide a document that you can literally go through and, step-by-step, look at your application and go through it with my guide. And it will give you kind of some of the thinking process behind how I look at-when I do audits for customers, this is kind of how Iâm thinking about evaluating the quality of it.
So, I think there are about nine major chapters or sections in the guide-theyâre not really chapters-and youâll actually get a deep dive email each day if you download the guide. And itâs totally free. And hopefully, that will help you analyze your application and think about it differently than maybe you are today. Itâs not a data visualization guide. Itâs an altitude higher. As most of you know, I do think data visualization is important and the interface design specifics really do matter, but thereâs a strategic level at a different altitude thatâs a little bit higher that needs to be considered as well thatâs not really solved by simply re-inking the charts, and tables, and things like this. So, if you want that guy just head over to designingforanalytics.com/guide, and you can get that for free.
So letâs jump back to the greenfield scenario. So, some executive, it sounds like, gave you a bunch of money and said weâre going to fund this new project and we want to design this new data product or whatever it is. And with any project, enterprise or not, you need to be able to define what successful outcomes look like and how youâre going to measure those. This needs to be established early; it needs to be in writing; it needs to be a team sport; it needs to be done with the stakeholders on the project; it needs to be understood to be a living document because chances are, youâre not going to really know where you end up. By the time you launch something, things are going to change.
But you need to put a flag in the ground and head that direction. And if you donât have that, and you just start building stuff, and everyone has kind of a different idea of whatâs being built, thatâs not usually a recipe for success. So, execution without strategy is expensive and itâs time-consuming. Youâre likely just going to build up more technical debt, youâre going to lose the trust of your sponsors and customers, and youâre going to shorten the amount of time and resource you have to go back and actually design something thatâs going to produce value.
So, a lot of times when my phone rings and someone needs help, itâs because theyâve been swinging at it for quite some time. Often theyâre just using engineers or thereâs an imbalance of the technical talent on the team with the design talent on the team. And they wait until itâs tough to really rescue at that point. And itâs a big pill to swallow because you feel like you can kind of dig yourself out of that hole, but eventually, you get to a point where you realize, this is not working to produce the value that we want. And this oftentimes, this design brief, which is the artifact that I like to use to express the customer goals, the business goals, the success criteria, this is often missing; and when itâs missing, it tells me that this team does not have a common understanding of where theyâre going, and so there is risk in that project or application.
So, you need to do that, thatâs got to be there. And this is especially true when youâve got multiple user types because as soon as you have multiple different user types, thereâs just a lot of opinions about what everyth-itâs like, if you have three different kind of customer types there, youâve got everyoneâs opinion, not just about one user type-and I say opinion because so often, user experience research is missing-now, youâve got three times the number of opinions for all the people on the team. So, what does that do without data, and facts and information to back up the user scenarios and this kind of stuff? Itâs kind of like, the loudest voice wins, or whatever is quick to put out, whatever itâs easy to code starts to win.
it just you end up diluting the entire experience, and youâre probably going to put out a solution thatâs very mediocre for everybody instead of being really awesome for a smaller set of people. And maybe itâs going to be a little bit harder for the rest of them, but you made a conscious decision that Customer Type A or Persona A is really the one that we need to delight the most. And if we get that right, we can accept a great B experience for everybody else. So, with enterprise data products, this qualitative research, particularly, has to be integral especially if you really donât understand the customers and that the users.
And Iâm talking about the end-users: that people that log in and use the interfaces. And I make this point because sometimes with internal applications, the person paying for it, the business sponsor, is representing a group of users, but theyâre not actually the person logging in. And they may think that they understand the work that the people below them do, but they may or may not. They may have come up out of that role as an individual contributor, things may have changed in the time that theyâve been there; processes may have changed. Or they just-if you think about it, do you really know exactly how your counterpart does their job? Like if youâre a data scientist and VP of data science, do you really know exactly how every other VP of data science does their work? You probably donât. You probably share some broad thinking about how you approach things, but you probably canât model exactly how that work is done.
And itâs the same thing here, you got to be really careful with secondhand information. So, figure out a way and if youâre a leader, your job is really to remove these roadblocks and to get access between the people who are the designers-again, lowercase d-with the people who are going to use it; get the friction out of the way. And you may have a company culture that is not going to be easy. There could be third parties in between, process management groups, sales teams, there could be all kinds of hurdles to deal with. But if you donât, youâre spending a lot of money and youâre building and risk because you really donât understand what customers need and what theyâre going to value.
So thatâs the cost if youâre going to guess, then youâre accepting a level of risk, which may or may not be good. I tend to see it compound to the point where itâs just usually too late to do something significant. At best, you start putting Band-Aids on things, and the business isnât happy. And nobodyâs happy if youâve invested so much in something and customers arenât getting the value.
So anyhow, without diving into that, again, this short term learning is part of it: when weâre going out and talking to customers and these different customer types to see how they do their work today, how does this application fit into what their natural workflow is, or what they want to do. Thereâs, kind of, two kinds of research: thereâs that short term stuff, which is youâre doing some design work, possibly with them, or youâre doing low-fidelity prototyping, youâre showing it to them, youâre getting their feedback on it, youâre changing the design, youâre revisiting it for feedback, et cetera.
This is part of the research. The other kind of research Iâm talking about is the kind where youâre not under the gun. Youâre not writing code on this application. You have a constant steady-state where going and shadowing customers in the whatever department-the operations team, or the diagnostics group, or whatever the heck it is-your team, just you have everyone in the team spends one hour a week shadowing someone from that organization, and then the next week itâs someone in finance, and the next week, itâs someone in operations. Youâre constantly going out to learn how other people do their work and how you guys not only can design the applications and products and services that they asked you to do, but you also start to learn opportunities to start innovating to start producing value where it hasnât been asked for.
Wow, hereâs an opportunity. I watched five people do this last month. Why are they doing this by hand? Our team could provide data and enable them to stop doing all this manual Excel work, or whatever the heck it is. Youâre never going to be able to step into that role where youâre anticipating these needs instead of just waiting for another Jira ticket to come in and servicing that request and having a budget discussion, or whatever. To me, if you really want to have an impact, you need to get in front of that; you want to start anticipating; maybe you even know the problems before theyâve articulated it as a problem. And youâre only going to find that realization if youâre out there, understanding what itâs like to be those people, driven by empathy, and showing that you care by showing up.
Thatâs how it works. So thereâs that short term stuff, which is this application, getting feedback on these interfaces, right now for this sprint, or whatever it is. And thereâs that long term steady state kind of research weâre talking about here. Iâd say, for those of you working on internal applications, and again, we talked about the software companies doing this for commercial reasons, for money versus those of you working internally. If youâre working internally, you may have some culture things in the way, but you have it so much easier. Because you should be-these people are your colleagues and you donât have to pay them to participate in research. You just need to get through the cultural hurdles, which may be tough, but itâs relatively easier for you to get access to the customers and to talk to them, to interview them, to observe them, you have it easier. If youâre on the outside, and youâre a software company, when you try to research, it can be seen as trying to sell something, even when youâre genuinely not, this happens a lot. So, typically a software company actually will pay-just with market research-youâll actually pay an incentive to get somebody time. Thereâs often no-shows that happen. So, you usually need to plan for more customers than you even want to talk to because itâs a challenge sometime, especially with very esoteric business software where you need a very specific kind of person. And this gets harder as you go up the seniority chain. You have it easier. So, I just want you to know. If you feel like itâs hard, it could be a lot worse. So, for those of you, again, those internal data science analytics, BI groups working on custom application stuff, you have it easier, believe it or not. So, fewer excuses, I guess is what Iâm saying. And thereâs lots of different kinds of research when I talk about qualitative research. But thereâs surveys and some quantitative stuff as well.
But for internal stuff, weâre usually not talking about thousands, ten thousands, hundreds of thousands of people using these applications. Theyâre much smaller in scale. Even if theyâre enterprise-grade, the number of literal humans that are going to interface is much smaller. So, I really favor qualitative forms of research, primarily one-on-one interviews, doing ride-alongs where youâre simply observing how someone does their job, or, âShow me how you do this today. How do you go through this workflow? How do you make a decision aboutâ-I always talk about the grocery store: âHow many carrots should this region of grocers buy in the next quarter?â How do you do that today? How do you answer that question today? Are they just guessing? Probably not. But you need to have that exposure to how they do that stuff now.
And eventually, this quality of work can feed into a couple of my favorite tools, which are journey maps and/or service blueprints. In my seminar, we go deep into this, but a journey map really shows kind of a customer-facing movement through a service or application. And you can do that at different altitudes: it can be for an application; it could be at a much bigger scale like if someone has some touchpoints in the real world as well as some digital touchpoints, you can kind of decide the altitude you need. A service blueprint is very similar, except itâs showing the-sometimes called the backstage. Itâs showing the business processes behind the scenes from the customer. And so for those of you in internal roles, a service blueprint may be a better tool for this. But the point is, these are informed by the research that youâre doing and itâs probably going to be more relevant for those of you in those internal roles.
And eventually, I think affinity diagramming is another tool that will come into play here, and Iâll talk about that a little bit later today. But this segues into the number of users weâre talking about. So, I said this episode was going to be about designing for multiple different user types. And so sometimes these archetypes of customers are called personas, and some of you have probably heard of this. And personas are, theyâre a design tool that helps us make decisions about what should be in the interface, how it should work, the attitudes of a group of customers. And so if you think about it, like a famous one-theyâre not famous-the one that sticks to me in my head was like, we had a persona called, I think it was âOliver Options Traderâ when I used to work at a large bank, and we were redesigning an active trader platform. And so we had your average investor who likes to trade a little bit, you had a day trader, whoâs using high-frequency use of the software. Theyâre trading all the time, very different than a retirement-oriented investor whoâs not really a trader. And then you had the options people. So this-what we did is you go out and do a bunch of research, you talk to a lot of different options traders or just users in general. And so one of the buckets that emerged from that work was there were a lot of people that kind of fell into this bucket of options traders. And the mentality was different about those people and the way they wanted to do-the way they wanted to use the software, for example, was very unique.
And so we felt like that was a unique persona that needed to exist. And the persona literally is usually, it can be boiled down to a one-page PDF, and itâs just a tool that talks about what would Oliver want? How would Oliver think about this particular feature or thing that weâre doing? And so these tools can be really powerful. They are archetypes, so theyâre the summary of lots and lots of both quantitative and qualitative facts that youâve gone out and gathered, and youâre kind of boiling it up into a single person because we canât really think about designing for thousands of individuals, we need to boil that down, we just canât process things that way as designers. So, we boil them down into these buckets, these archetypes. So Iâve seen this work, okay, and I think personas and theory are an awesome tool.
However, in reality, I think thereâs a lot of problems with personas. And the problem is that most places donât have the resources or will not budget the time and money to actually go do the inputs, the required research to form the personas, and then actually go out and have the personas in use during the design process. Because they donât do any good if you just make the PDF and they go into a folder somewhere, or Dropbox and no one looks at them. They donât do any good.
So thereâs a two-fold problem there. So, I kind of consider them really valuable if youâre willing to do the work to actually form them with data and not to just make them up as a lot of people like to do. And you have a team that knows how to leverage them in design discussions, they can be powerful. But thatâs just not what I see happens a lot of the time. So, I almost hesitate to mention it because as much as I like them, I donât think itâs realistic for a lot of, especially, smaller teams. A lot of you that are probably listening are not trained designers and you may not have any designers on your team.
And so youâre talking about a fairly complex tool that requires a lot of input. Super powerful if you get it right because it will very much keep the application on track in terms of the design choices you make. Itâll help settle arguments about how things should work. Thatâs really what the power is, is that it reduces the risk of what youâre building. But I do think if you donât have thousands and thousands of customers or even millions of customers, then just may not be the right tool to be using for this. But I want to throw it out because some of you may be working on larger-scale applications.
So, if you do want to learn about how to do that, my friend Steve Mulder-Steven, I worked at Lycos way back, if you remember Yahoo and Lycos and the search engine race-he has a book called The User Is Always Right: A Practical Guide to Creating and Using Personas for the Web. That gives a very step-by-step process of both the qualitative and quantitative research and how to form them, and templates, and things like that. Thatâs where I would go if you do think youâre ready to bite off doing a persona exercise to build those tools out and leverage them in your design process.
So, moving on, letâs talk for a second about MVP thinking. So, when I talk about MVPs, itâs always minimum valuable product, not minimum viable product. Okay? So, who will you favor in the experience? Who is it for? Who are you going to delight? Who are you not going to serve?
In order to get to this point of being able to provide minimum value, we need to get that strategy document or design brief that I talked about. This is critical to that or else youâre never going to know if youâre actually doing a good job. And the last thing you want to do is wait until the end to get feedback from a sponsor or a customer, to tell you whether or not you did a great job. You want to be anticipating that so that youâre not getting surprises in the last hour. This design brief is subject to change, especially in enterprise-scale application. Youâre probably going to need to revisit this. The strategy may change as you start building and shipping stuff, getting feedback, you may take a different course. But you need to start somewhere and get the team aligned on that from the beginning.
Things Iâm thinking about here are, particularly, which type of users have the highest need from a usage perspective? So, this is high traffic usage of the application, Iâm always thinking about the amount of times theyâre logging in: is this something they use daily, weekly, monthly? Not all customers may touch the application with the same level, and typically, Iâd say you really want to design for the high traffic use as much as possible, which may mean that itâs a little harder for someone that only logs in once a month or something like that, but that might be a hit you take because itâs more important that the people using it all the time who may be responsible for the most value generation have a great experience with the solution that youâre coming up with. Another framing is, which customer types are likeliest to generate the most value from the product? So, maybe it is the people that only log in once a month or whatever, maybe theyâre the ones that can actually turn the information, the decision insights, and things like that in the application into real customer value, real business value, whatever that is. Thatâs a different framing. And you may decide that you know what? Thatâs actually the way we want to go. Iâm also thinking about how well has the decision making been modeled, such that your design naturally works with how users do their jobs today. So, that kind of refers back to the service blueprints, and journey maps, and things like that, that we talked about.
But decision modeling is a little bit different. It takes place largely in the head of the people, or in an organization. And the more we know about that, the easier it can be to design a solution that will feel natural and that will service the people the way we want it to. Iâd also be thinking about, in the spirit of moving fast and showing value quickly is, are there particular insights or decision support that you can provide that are not super complicated; that donât require tons of data; different types of data connecting up lots of different data sources?
Where can we get some base hits or some initial points on the ground? Thatâs a little bit different way of framing the problem, again, but Iâm always wondering, how do we-especially if the team hasnât done a great job in the past with the designâis how do we get some wins on the board so that we can continue to get the support we need, and also just feed our own feeling that we know what weâre doing, that weâre on the right track. Thereâs something, I think, thatâs powerful for the team to feel like, âHey, we bit off a small thing; we got it out; it worked; the customers liked it.â It feels good to work on that kind of stuff that builds morale and that kind of thing.
So, maybe it means not jumping into a machine learning solution right away. Maybe it means some traditional analytics, and some more eyeball analysis is required with the data, and eventually, maybe you can move to a prescriptive or predictive solution, but thatâs not the first step. Maybe thatâs something in phase two that you decide to do, but right now Persona A needs to be able to-weâd like to help them as soon as possible. So, we do a smaller thing before we jump into the long term value thing.
So, keep in mind, again, thereâs no executive leader-whoeverâs the sponsor of the project-really wants an enterprise data product. Theyâre all after something else. So, you got to understand the last mile at the beginning of the project: who is the one thatâs deciding what value is? How is that being measured? What are they comparing it against?
Itâs not about the output, itâs always about the outcome. So, try not to think so much about the thing. I always think of it as this concrete building. Itâs not really about the building. Itâs about the experience the people will have once theyâre in the building, or whatever it is that theyâre doing in there.
Okay. So, moving on, weâve kind of talked about some of the research and the design brief and that kind of thing. Thereâs lots of different details here. One that I did want to pull out is when you have these multiple user types, and youâve been interviewing them, and starting to form a design brief, you may realize that there could be some time well spent doing some-whatâs called affinity diagram. But itâs basically looking for common threads across all the different personas. And again, Iâm always trying to think, how do we move quickly and show some value soon?
And so you might find out that thereâs three kind major archetypal users: youâve got a developer who just wants an API, and youâve got a business sponsor doing something, and maybe you have an analyst who also needs to use the tool. But all of them need to do Task C, whatever that may be. Task C might be the place to start with your interface, your product, or your application, to get some value. But youâre not going to know that if you havenât gone out and actually talked to these customers to learn about the common threads and the different activities they do.
But the point there is to look for-using this affinity diagramming tool, or whatever tool you want-is to synthesize the research and figure out where those common threads are so that maybe you can bite off that stuff first, instead of doing lots of one-off features that only support a very narrow niche use case. There are times that makes sense, especially if the application needs to go end to end, if it needs to go A to Z and everyone needs to go through all the steps of every letter A to Z and you canât just skip K. There are arguments to be made for that sometimes, but I think itâs worth looking at whether or not thereâs some commonalities that you can combine, and then use that as a starting point for your application and the design.
I would be staying away from complicated use cases, edge-case stuff, worrying about all the different scenarios that are possible. And I understand from an engineering perspective, why sometimes those things matter; try to not get lost in those conversations because they can really derail the overall strategy, you can just end up spending all day on small tactical stuff that really does not move the needle. So somebody-and this is why product function matters-needs to be looking at this at an altitude that really focuses on the overall business value and user experience thatâs going to come out the other end of all this exercise. Okay?
So next, I want to give you some specific ideas around analytical applications and tools. But first, this.
Okay, so Iâm back, and letâs talk about, again, these specific ideas around enterprise data products that are analytical tools, decision support applications, this type of thing. Some of you probably have heard me talk about this before, or maybe youâve seen it in some articles, but understanding if you have an exploratory or a declarative solution. So, what do I mean by that? Well, most people want declarative solutions. This is why machine learning, and AI, and these predictive technologies are really appealing is they make a decision; they come up with a conclusion of sorts. One of my past podcast guests calls them âopinions.â
The point is, they donât require as much analysis and exploration of the data. So, you kind of have to understand, what kind of tool are we building here? Where are the opportunities for making declarations, or opinions, or whatever you want to call it, but those conclusions? I want you to be thinking about what kind of tool are we here to build? Theyâre very different. And analysts may be looking for a dataset, rough insights, and the like, but a business customer maybe doesnât want to be in that tool at all. And the developer, maybe they just want to integrate some data into their application and theyâre not looking for insights at this point because theyâre going to wire it up with some other tool that you donât even know about at this point. So, these are very different solutions. Choices need to be made. Thatâs the point.
And again, this is why the product function, even if youâre not necessarily a software company selling commercial software, the mentality and the ownership that comes with the product thinker whether itâs as a designer or a dedicated role. I donât know which person it is, but that function is important to have because these require choices. And we want the choices to be deliberate and not just happenstance. Like, the choice came as a result of just the fastest thing to build, or thatâs what we got for free from the framework, or whatever. Thatâs not what Iâm talking about. Iâm talking about designing with intention.
Thatâs the exploratory versus declarative analytics thing. You also may want to check out my CED Framework. If you just go to my website or Google âCED UX Framework Brianâ or something, Iâm sure youâll find the link to it. That may help some of you. Thatâs about conclusions, evidence, and data is kind of this trio perspective about how I tend to think about designing analytics solutions when Iâm doing it for customers.
So next, letâs talk about customization. So, customization is something that sounds great. Everybody will say, âYes, I would love it to be customized,â if you ask them. So thereâs very little purpose, usually, in asking customers about customization because it sounds like youâre giving them this ability to do whatever they want so of course, theyâre going to say yes because they probably donât imagine how you could possibly know exactly what they want. However, thereâs a cost with customization, not just the technical stuff, but youâre putting a lot of labor and work on the customer. Youâre turning the customer into the designer when you add customization, and youâre adding user experience friction, youâre adding usability friction, overall complexity is simply going up. So, there is a cost to providing customization. Iâm not saying itâs always wrong, Iâm just saying itâs something that you need to be aware of. And sometimes the easiest way to make something easier is to get your eraser out and start removing stuff thatâs not absolutely necessary and not just looking at it as what do we need to add to make the experience better for this new requirement, this new persona type, this new whatever that comes along? Itâs always additive.
So, you do have an eraser, not just a pencil. So, keep that in mind that thatâs also a tool. Another thing Iâm going to say about analytics applications is resisting the blank slate approach. So, this is the login, I get an empty screen. Itâs like if youâve ever opened-you know, opening Photoshop up for the first time, and you get all these tools and menus, and palettes and things, and itâs just a blank screen, itâs like, âWhere do I even start?â Itâs not a great experience. I can almost generalize this, that itâs probably not the right experience to have. So, this gets into onboarding user experience, and what I call the honeymoon phase, which is kind of that phase beyond the onboarding but before someone has gotten very comfortable with the application. Thinking about the design, and designing that experience with intent is really important.
But starting blank because you think that thereâs too many different needs and everyoneâs going to have a different need, et cetera, you may just be giving everybody a B-minus, C kind of experience. I would rather start with something that at least services a very specific group of people, even if itâs not the right starting point for the majority of them or whatever, but make an informed choice about it is my point, and just understand, itâs probably a little suspicious if itâs totally blank and youâre putting all the energy on that customer to go discover whatâs possible, what I need to do, all those kinds of things. Youâre really putting a tax on them. So, let the customers let the research you did drive this. There may be arguments to be made that that is the right thing to do. And I always double back on, what did we learn in the research that we have? What kind of information do we have to support this decision or not support this decision?
So, the next thing I wanted to talk about with designing enterprise data products: if youâve taken my seminar, or my course, or anything, you know that I think design is a team sport. The role of design, you may have professional designers, and they are faster and probably better at it than your untitled, non-professional designers are, but itâs usually still a team approach if youâre doing it right. The designer is not living in isolation by themselves. If they are, youâve probably got a problem, if youâre just throwing stuff over the wall, youâre never interacting as a group. Design is a team sport.
One of the spokes on the wheel-if the team is kind of this wheel-is the tech leads. Oftentimes, this might be a software architect, or some kind of engineering lead or something like that. I think thereâs a natural and positive yin and yang between the product owner; the engineering, technical lead-that could be an analytics professional, whatever it is-and design and user experience. These three things, itâs like yin and yang. Theyâre all tugging at each other, all in a common mission, but kind of balancing each other out. But if thereâs too much tech vibe in the room, youâre going to kind of relate back to these, well, itâs a platform and it has to scale. And theyâre thinking about system architecture. And we canât just design this for one person. And nobody really wants to think about the small stuff. We all want to think about scaling and making it infinitely flexible, and all this kind of stuff. Itâs a natural tendency to want to abstract things as much as possible so that youâre not having to, quote, âRevisit it.â But in reality, a lot of times you do need to revisit it because even with all that abstraction and stuff early on if you donât have a really great idea what someone needs to do with this thing at the beginning, youâre still going to revisit it anyways, or the project will not get funded, or youâll be out of business, whatever it may be.
So, this is why the design is the responsibility of the entire team and not just the designer. We want the technical people brought along with us, understanding that designers are always going to favor the user experience piece; engineers are going to always want to make sure that the platform is technically feasible, and itâs performant, and security, and integrity, and governance, and all those other kinds of things; the product personâs trying to make the business happy. These are really good natural tensions that happen. But the team needs to understand what does value look like for the customer because ultimately, if the user of this thing doesnât do what theyâre supposed to do, or doesnât get the thing they want out of it-the decision support, or whatever it is-it doesnât matter. All those other things are secondary; theyâre ancillary. It doesnât matter how scalable the platform is, it doesnât matter the governance. Weâre not here to make sure that our data is treated well, or whatever. That stuff doesnât matter if the data is never even getting in front of the people; there is no problem with the data because itâs not getting to the people that actually matter. Theyâre second-order goals. And Iâm not saying theyâre not important things.
Iâm just saying, the design piece is much grayer in nature and some of those things are much more black and white, and so theyâre easier to tackle and say, âCheck the box. We did this.â Itâs much harder to check the box on the design side of things. So, I want you to be thinking about the team making the design decisions, the team informing the technology piece from the design, not the design coming after all these decisions about technology have already been made. The best projects Iâve been on are when we have a strong software lead who has worked with design before, and they realize that itâs going to help them do their job. The architecture thatâs driven by known use cases, known behaviors, known user experiences that we want to support helps them plan what it needs to be, and it helps them not make a decision today that the business may need to live with for two, three, four, five years down the road. We want to de-risk that as much as possible.
So weâre really on the same team. And believe it or not, the design stuff can really help out with the technology planning. So, and this is really important at enterprise scale when weâre talking about this because big decisions are going to be made, and if the user is not part of that, youâre really just checking into work, punching your card, checking out, writing some code, whatever. It doesnât matter because if the customers donât get any value out of it, youâre really just checking in, checking out, and no oneâs getting a lot of value out of it. And I donât know about you, but itâs just more fun to work on stuff that matters, that customers really value. So, just understand this natural tug and perspective that the different team members are going to have, and that thereâs a tendency for tech to usually kind of rule the day and the tools off the shelf are theoretically a lot stronger today, and that tends to be the thing that wins these arguments. So, keep that in mind.
Get visual early, if youâre doing this stuff. I mean, this is a general design guideline, I would say anytime, but I think itâs even more important with enterprise software. Even when youâre talking about low-fidelity work. Itâs easier to have group conversations with a lot of different stakeholders when weâre looking at stuff and not just talking about things in words. So, try to get visual. Use those low-fidelity sketches, the whiteboards, whether itâs Miro, or whatever tool you may be using right now because a COVID if you donât have a whiteboard available to you right now, as I know many of us are struggling with that.
A couple other things here. The team and the leadership needs to swallow the pill that thereâs no one magic design to rule them all. There just isnât. Thereâs also-thereâs no such thing as no choice when youâre designing an application or experience for a customer. All choices, including the decision not to do anything is still a choice. So, you can play the middle and deliver what is probably going to be a mediocre solution at best that doesnât really delight anybody, but it kind of checks the box on all these requirements. But you may find out that no one really ends up using the tool, and so all that money that was spent building it just kind of goes out the door, and no oneâs really singing your praises and saying, âHey, this was awesome. Give me more of this. Can you help me with that?â Because it says, âI donât know what this is, but itâs not what we wanted, and itâs not helping us do our job.â So, the point of this, I thinkâyou know is? That you mayâhave to make some tough decisions where you say, âYou know what? This design is-yeah, itâs going to be really hard for-whatever person-a business person to come in and get the thing out of it, but the reason for that is because we have 100 different developers who need a great API, and they need a very different type of experience with this application than the person that comes in and looks at the GUI. And so weâve spent our user experience dollars making that work for them because the value is really going to happen when those developers are able to tap the information in our API and turn that data into their own applications, or whatever it may be.â The point here is that itâs not a little bit of spread the love around for everybody, itâs, this thing is really good for these people. It will really provide value on these tasks for these people. And weâve made a decision that itâs not going to be as easy for these other people over here. And we know what it is that they want to do, and maybe eventually we can come up with some other solution, or we can kind of improve things for them, but this kind of generic thing thatâs for everybody, it just rarely doesnât ever result in something that someone really finds super useful. Because different personas have different ways of working, different needs, they care about different stuff. Task frequency is a big deal. How often theyâre logging in such that theyâre actually familiar with the tool.
How much hand-holding do they need? Hand holding is not always good. Help documentation and wizards and stuff like that, some people hate those. If youâre using the application all the time, you donât want these tight linear workflows. You probably want some flexibility because you sit in this application all the time; every week, you spend time in this thing. So, those are all distinct choices that youâre making. So, you got to swallow the pill as a team that thereâs no one magic design to rule them all. Thereâs just lots of different possible solutions out there and they all are probably going to favor one group over another.
So, some kind of just random concluding ideas on this, itâs really, really hard to design a useful, usable, valuable large-scale enterprise application without skilled product designers, or user experience researchers, in-house. Thatâs just my experience, watching teams do this and being part of teams. I think itâs hard to get that right. Itâs not impossible, and you might get lucky sometimes, or you might just have a knack for it. And if so, that is awesome, and I think itâs great.
But this is difficult stuff. Just like WordPress and Salesforce are both-have code, and they both have JavaScript. But I think weâd say that those applications-Salesforce CRM, and WordPress-are very different beasts under the covers. And even though they share some common languages, probably, and stuff like that theyâre really in separate classes. So, I just want you to understand that itâs going to probably be hard if youâre really tasked with doing other types of work if youâre in management, or youâre spending your time, youâre really a data scientist, but youâre kind of running the overall application, or, you know-you got to accept that thatâs going to be that way, so my suggestion is to go and try to get some help with this, if youâre biting this off, especially for the first time on your own.
Iâd say the biggest thing you can do is probably to do enough research that you stop learning new stuff. And when you stop learning new stuff through the research part, thatâs when that you probably have a much better idea about what people actually need. At some point, you do need to put something out there because until you put something out there, the research is still just research; itâs theoretical. But it will help de-risk the project.
The business objectives, you got to have the business objectives in mind, not just the user experience ones. And Iâm kind of aiming that comment at the designers that may be out there. A lot of times, they only want to focus on the user experience piece. Theyâre not necessarily thinking about the business side of things. And sometimes those can actually be at odds with each other.
It needs to be feasible and realistic without being constrained early on by the technology. So, this means trying to spend enough time upfront on some design without being limited by the technology. And the more you can do this prior to making very large investments in certain technology, the better off youâre probably going to be. Because as soon as you get into bed with a particular vendor or tool, youâre going to see the world through that lens. And so early on, I like to try not to get too tied into that if possible. Itâs not always possible, but in the ideal scenario, you would be letting the technology decisions follow the design work that youâve done, and the user experience research that youâve done.
And then, you know, you can make progress if youâre willing to put aside the technical work and realize that real progress is not defined by how fast you ship code. If itâs technically right but effectively wrong, it doesnât do any good. So, what can happen on these projects with lots of different people building, and coding, and everyoneâs own in these tiny little port-âI just on this one little bridge between these two systems over here.â You really get lost in the day-to-day coding and building analysis or whatever it may be, and the big picture just gets lost. Itâs often not communicated well, and now youâre just shipping code, trying to hit the sprints, trying to say, âWe estimated the number of user stories, points and all this kind of stuff,â and the strategy is still lost, but youâre following the process, shipping stuff out the door. I often see that: thereâs rarely any customer real valid, true customer feedback. Rarely do they go back and change something. Instead what they do is, they take the feedback, but then they just go on to the next add; add the next thing; build the next part of the solution. Not go back and change it, even if we didnât get the feedback we wanted. Thatâs the fight that you always have to be kind of fighting that natural tendency to want to focus on staying on task with the sprints and shipping code. Quote, âWorking softwareâ-with a heavy quotes-is only working if it works for the customers. QA passing does not mean you did a good job. It just means thereâs no bugs, maybe thereâs no security issues, those kinds of things. But you can build a bug-free application with all the right data protection and governance and all that stuff and still have it completely not be useful to a customer. So, you got to evaluate, what does it mean to design and build something thatâs really successful for customers? You have to decide what that means upfront, and if youâre talking about it in terms of technology things, then somethingâs probably wrong. Because no customer cares about that stuff behind the scenes: what tech was used, what platform was used. They donât care. If theyâre a business user or just a normal user, they just want it-people care about themselves, and the more you can support what they care about, instead of what you care about, the better off your design is going to be.
So again, get some help if you donât have it, whether-thereâs lots of free-so much free information on the web, on how to do stuff, how to design better services, even if youâre not a designer. So, I really recommend spending some time on that before you embark on your next project.
And if youâd like some of my help with that, I have a bunch of free resources, just head to designingforanalytics.com/resources. Iâve got that self-assessment guide we talked about, thereâs lots of different articles, my mailing list, I have a self-guided video course; you can try the first module of that for free, and Iâll go into a lot of detail on step-by-step how I teach data teams how to leverage design. Just enough design to get going. Itâs really a primer: what are the best tools that I think are relevant to building data products out there.
So donât feel like you have to go at it alone there, there are resources out there to do this stuff. And just remember, you donât have to be a professional title designer to get better at designing good solutions. Design is something I think most technology people can learn if theyâre willing to do the work, theyâre willing to slow down slightly to take a much bigger win in the longer term. And especially for the analytics people out there, and the data scientists, and those who see DataVis as, kind of, this last thing that happens at the end, like the plots for my model or whatever. The kind of design Iâm talking about for these applications, it does not begin with data visualization. That lens is too narrow and the altitude is too low.
If youâre really going to do user experience work, you need to think beyond the data ink thatâs on the screen because youâre not going to answer all the quest-you can get the chart right, and you can still get the overall product or application wrong; you can still not get the impact that you want, even though the charting has been done correctly. So look, I believe in all you guys. If youâre listening this show, which youâve got half the battle because youâve decided that it matters. Your team is already doing design right now because if youâre putting out any type of software or solution to your customers, right now, someone is making those decisions about what they see, even if itâs in Excel, someone decided the columns, the sorting, the whatever it is. That is a design choice. So youâre already doing this design work; you are designers. And maybe youâre lowercase d designers, but you already are.
So, the next step is really to learn how to design with intention instead of just, kind of, letting it come out the other end, itâs just like when I write code. I kind of understand what good code is supposed to be, but I canât do it. But I can hack through my JavaScript, and I can build a simple little application, and I donât really understand what Iâm doing. So, am I an engineer, I donât even-it doesnât matter if Iâm an engineer or not. Iâm not an engineer. I have too much respect for really good engineers. But I know I can get something going. And it works the other way, too. You donât have to be a designer to leverage some of the values of this, just like I donât have to be a titled engineer to build a little application to help me get something done.
I want you to take those skills-itâs not a zero-sum game. If you learn some of the skills, you can get some of the value. And thatâs one of the nice things about this is that you could just learn how to run a usability study, and not actually learn anything about the design part of fixing the design, but simply learning how to evaluate whatâs wrong with this right now, that is something youâll get value out of.
Or you could just learn more about doing a journey map or a service blueprint or learning how to conduct a really good qualitative interview with a customer. Maybe you donât yet know how to synthesize that data and put it into a design, but youâve just informed yourself. Youâre starting to learn something about customers that you probably never learned before. So, you get some value out of that. So, thatâs the nice part here. You donât have to know all of it and do all of it on every project to get some value out of it. So youâre already doing it; go out and learn how to do it better. [laugh]. Good luck as you dive into 2021 with your design work. If you do have questions for me that youâd like me to answer on the show on a future solo episode, you can go to designingforanalytics.com/podcast, I do have a link on that page to go to a place to record a question right from your browser. It can be totally anonymous if you like; no software to install. Iâll get a link to your audio recording. And if you leave it there, I will try to answer your question on a future episode. So thanks, and again, good luck in 2021. And weâll be back in a couple of weeks.
Ahmer Inam considers himself an evangelist of data science whoâs been âdoing data science since before it was called data science. With more than...
Angela Bassa is the head of data science and machine learning and the director of data science at iRobot, a technology company focused on...
Angela Bassa is the director of data science and head of data science and machine learning at iRobot, a technology company focused on robotics...
