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.
When it comes to telling stories with data, Cole Knaflic is ahead of the curve. In October 2010, she wrote a best-selling book called...
On this solo episode of Experiencing Data, I discussed eight design strategies that will help your data product team create immensely valuable IOT monitoring...
50 episodes! I can’t believe it. Since it’s somewhat of a milestone for the show, I decided to do another solo round of Experiencing...