Our Symphony Platform

013 - GAT Podcast: Force Multiplier - Our Symphony Platform

MJ 00:01 Welcome to Force Multiplier, the official podcast of BRG's Global Applied Technology team. The GAT team, as we call ourselves, is a globally distributed team of software engineers, data scientists, graphic designers, and industry experts who serve clients through our BRG DRIVE analytics platform. We're helping some of the world's largest and most innovative companies and governments transform data into actionable insights.

I'm Michael Jelen, and in these conversations, we speak with people both internal and external to BRG to discuss how technology and specifically software acts as a force multiplier to extend the impact of people across any kind of professional organization.

Today, I'll be speaking with Luke Sparrow about our Symphony product. Luke is one of our software developers here at GAT, working on integrating new technologies seamlessly into our Symphony platform. Symphony enables the visualization of data and the ability for team members to collaborate, discuss, and interact with that data. Join me today as I speak with Luke. Hey, Luke, how's it going?

LS 00:56 Hi, I'm doing well. How are you doing?

MJ 00:58 Doing great. Thanks so much for taking the time to speak to me today about some design principles. But before we get into that, I'd love to hear a little bit about you, and I'm sure everyone on the line would as well.

LS 01:09 Yeah, of course. First of all, thank you for taking the time to chat with me. Selfishly, I always love to get to talk a little bit about the path that I've taken and [am] excited to get to talk about Symphony a little bit, which is what I'm currently working on. So, to start, I have been working in tech startups for about the last decade or so. I love working to build up new teams. I love working in tech to help customers solve problems. That's essentially what gets me out of bed in the morning. I was working for a company that did case management software for law firms. From there, I went to a company that was doing payroll and HR benefits software for small businesses.

And now I get to work as a part of the Global Applied Technology team, primarily working on Symphony, which, as I'm sure you know, but our listeners might not know, is essentially a collection of tools that our customers can use to analyze their data, regardless of the source of that data. So, if they're keeping it in something like Tableau, Power BI, Click, etc., we can combine those different sources all into our platform. And then there are some additional lifesaving tools on top of that, where you can collaborate really quickly and efficiently with your team and create these insights or little snapshots of the data so that you can better tell stories with that data and make decisions about how you want to approach your business, whether that's something in the healthcare industry, whether that is something more traditional business, whether that's consulting, etc. it's just a really effective toolbox.

MJ 02:47 Awesome. Thank you so much. It sounds like, at a high level, Symphony, the way you described it, is a bit more of a collection of tools rather than a specific product. Can you talk a little bit about that distinction between those two and maybe why we decided to build Symphony as a collection of tools?

LS 03:06 Yeah, that's exactly right. The simplest way that I choose to talk about it is essentially a tool solves an individual problem, right? So, a screwdriver solves the problem of, I need to get a screw into a piece of wood or into the wall, and that's an incredibly useful tool. It serves a very useful purpose. But when you have a nail, you can't use a screwdriver, or at least it won't be very effective. Same if you need to draw a straight line, you know that's what a ruler's for, not a screwdriver. So that's a little bit of an oversimplification, perhaps. But when it comes to Symphony, we really took the approach of, there are tools out there that exist, that people are already using, and we want to make sure that those tools are just within easy reach for our clients.

LS 04:01 So instead of needing to head out to the garage to get your screwdriver, and then when you bring it back in to your project, you have to head into the other room to get the actual screws, and then maybe in your kitchen, you have your ruler. I don't know why someone would have it there, but it's in a different spot, and we wanted to create something where, without getting up from your workstation, right, you had access to all those tools that you needed. And then we wanted to make sure that we threw on some additional tools or additional usability, additional features that helped to bring those all together, right? A good toolbox that not only has just an open space where you can throw in your screwdriver and your hammer, etc., it has nice organizers for those. Maybe it has a clasp that locks so that no one can just get in and access your tools without your permission. Things like that, that we wanted to include in there to make sure that people had access to all the tools that they needed.

MJ 05:02 Cool. And I know from our time in Lisbon together, as you were developing new versions and putting different tools or different functionality in different areas of the screen, one of the things that we ended up doing was an exercise where you would ask each person in the team to go up in front of the room and try to execute a certain task or do a certain thing. And then you would watch us do it to see where our eyes went, where the mouse went, and whether or not we were intuitively finding the things that we needed. It was such an interesting and, in some ways, very humbling experience. But could you talk a little bit about the way that you understand your customer base and how you gather that information to make decisions about how best to present these tools to people?

LS 05:45 Yeah, of course. And if I remember correctly, you were doing very well at those tasks. So, I know you said it was a humbling experience, but it was good to see that some of the design principles that we went with weren't in vain, and you were able to kind of follow those breadcrumbs and signposting that we put in there. But essentially what you're talking about, I like to think of as really just listening to our users. We have ideas in our head about what we think users will want from a platform, what we think will be intuitive, what we think will be easy for a new user. But ultimately, if we're not in conversation with our users, if we are not testing things out, if we're not getting feedback from them, then we're just sending this off into the ether and hoping that it's going to come back with positive results, which can sometimes work. Sometimes if you put a blindfold on and throw a dart at a dartboard, you're going to hit the bullseye. But more often than not, you're going to hit the wall or your friend that's standing next to you.

So that was an exercise for us in making some changes, but not committing so far as to make these permanent or push it all the way out to all of our users. We wanted to make some changes that we thought were going to help our users navigate through the platform more easily. And then just seeing if that were true and in Lisbon, as you were talking about, we found several decisions that we made that weren't very intuitive, and we took a lot of notes from that exercise and then came back, added that into our design process, tweaks and things, took that feedback, and I think overall, because of that, we ended up with a much more intuitive product, because we learned about the things that our users were seeing that seemed intuitive to us, but really weren't on the other end. And so that's something that we need to pay attention to and make sure that we're addressing.

MJ 07:48 Great. And I think one thing that strikes me as challenging would be trying to present a unified user experience to whoever the end user is, while using a number of different technologies that make up our stack.

One example, I guess, would be our visualization tools. As you mentioned, we try to stay as technology agnostic as possible. You never know which a client may be using, but the tools and features and look and feel of Tableau [are] very different than that of Power BI, which is also very different than Click. And when someone uses our platform or the Symphony product, we want them to experience the same sort of tools, functionality, etc., across those different underlying technologies, and also not only just within the Symphony product, but across all of the different tools that are inside of our platform.

Can you talk a little bit about some of the design decisions and perhaps even challenges that you come into when trying to integrate a bunch of very different technologies while not letting the user understand how complicated it is behind the scenes? [laughter]

LS 08:50 Yeah, of course. And really what you're describing is at the heart of what our design process is trying to solve, right? So, we want to make sure that when our clients come in with their data setup that they've been using for a while, that they feel comfortable in where they have their experience. We want that to be a pretty seamless transition into a toolbox, into a product that just makes that process faster and gives them more insight into their data instead of making their life more difficult.

So, as you mentioned—let's take just bookmarking data for a quick example. Pretty much all of these tools where you're going to be able to visualize your data allow you to take a snapshot of current filters and selections that you've made so that you can bring it up later to talk to your boss or talk to your own customers about and say, "Hey, here's the data that we're seeing." Now, as you mentioned, Tableau does this in a different way than Click does it, and Power BI does it in yet another way. And in a world where a client is large enough where maybe one team uses Power BI and another team is really invested in Tableau, if we have both of those systems in our toolbox, the disparity between the two of them is something that can end up being really jarring.

LS 10:16 And so, a large focus for us is designing a lot of our components that we're using to make up our product in a really dynamic way and in a modular way, so that no matter what technology we end up slotting in there, it essentially has this wrapper around it where we can control the look and feel of it. We can control the functionality behind it so that they still have access to all of the powerful features of these tools, but in a more cohesive way. And so that bookmark—for example, Tableau—might allow you to save five different types of data, and that might be with a couple of clicks; it might be with one click. And what we have chosen to do is say, "Hey, something we think would be really intuitive is that no matter what technology our customers are using, we're going to give them a button that says, 'Hey, save this current selection state as a bookmark so that you can apply it later.'"

And then we do the sort of development magic behind the scenes to say, "Oh, when they click that button and we know that the technology is Tableau, that means that we need to do these eight processes, or what have you. And when that technology is Click, we need to do these five processes"; but to the user, that's going to feel cohesive across the platform, because they know, "Oh, whenever I see this button that says that I can save this data as a bookmark, I know that I can just click that and then Global Applied Technology and their Symphony product [are] going to handle that behind the scenes."

MJ 11:51 Gotcha. Gotcha. So, speaking of that design magic and how the back end magically does and transforms the information into what the user is expecting, what are some of the roadblocks that you experienced during this design process, and what are some creative ways that you end up overcoming them?

LS 12:09 One of the roadblocks that we hit is just that not every tool is built the same, and one tool might have all of these nice and fun and useful bells and whistles that we would love to incorporate across the platform. But focusing on the parity between different tools and different fields for the platform is really important to us. So, making sure that it's cohesive, even if one tool has access to things that our clients might use one day and that we think could be useful to bring into the platform—it's more important for the purposes of our design philosophy to make sure that we are essentially bringing things in batches, right? Making sure that all of the technology types that we allow into our toolbox have the same functionality and that we have parity there.

Another roadblock that we run into is, you know, we have some unique offerings that we're adding to our toolbox, right, like security features and the ability to communicate and collaborate across different technology types, things like that. Sometimes that's not always easy to add on to a specific tool. There might be a tool where we can add it into our components that we're making really efficiently and really quickly. And there are other tools where adding some of those features becomes a real design challenge, and we have to get creative with how we're solving the problem of accessing the data behind the scenes and making sure that what you're seeing as a user on your end is something that feels exactly the same, no matter which tool you're pulling out of the toolbox.

MJ 13:47 One thing that's always kind of struck me as a massive design challenge, and I'm not sure how anyone resolves this, is that you have a user base that's often extremely diverse. In some cases, you may have someone who is on the older side who doesn't have a lot of technology experience, and when they arrive at a site that has a lot of information or buttons to click on it, it could certainly be overwhelming. Whereas other people, perhaps on our team or other technical users that may be from our clients, might be used to coding and the power users in many different ways. How do you sort of thread the needle between these two very different user styles to present something that is beneficial to both of them?

LS 14:31 Yeah, that's an excellent question. And really, where we try and focus a lot of our efforts is not limiting the power user, but not focusing on the power user. And I think that distinction is pretty important, right? We want the power users to still have access to as many of those bells and whistles that I mentioned before as possible. But we want to make sure that all of our users have a coherent experience and what feels like an intuitive experience. So, when it comes to how we signpost users in the direction of the most important features, when it comes to the tooltips that we add to some of our menus or to the screen itself when a user hovers over a button where they say, "I'm not exactly sure what this is"—giving that information to a user in a way that doesn't overwhelm the user, but still allows them to, in some ways, self-serve and find out the answers for themselves.

And again, I'm using this word a lot, but it's a focus for us, a way that I hope is intuitive. Now, there's still more work that we're doing there. We haven't completely cracked this problem of power users have everything they want, and users who struggle a little more are never falling off the path, and they think it's the most intuitive thing in the world. It is a very fine line to walk, but where we're doing a lot to add in tooltips, tutorials, etc.

And another thing on top of that is the ability for users to, essentially, set up the layouts and the density of information that makes sense for them, so that again, a power user can see a lot of info on the screen at one time, but another user might pare some of that back so that they have an experience that doesn't feel overwhelming, and they use this tool from the toolbox every day. We want to make sure that's front and center for them, and then they can still access the other things that they need when they become more comfortable with the platform.

MJ 16:34 Cool. And it's interesting to see the different kinds of approaches that other companies take. I think a wonderful thing about working in software development, in general, is that there are a lot of examples out there, and you can easily go take a look at what other people are doing to solve different kinds of problems that you may encounter yourself. And I always think about the design philosophy spectrum and how wide it can be in some cases. On one end, you have Apple, which generally decides what the optimal configuration of everything is and then presents that to the user pretty much as is, thinking that that will be the best outcome. Whereas other firms go a more customizable route. And it sounds like what you're saying: we have the ability to increase, decrease that information density and change things around based on what the user wants. I think that's super interesting.

I was wondering if there was any sort of place that you drew inspiration from as you were making some of these decisions or what your thought process was?

LS 17:30 Yeah. So, I think Apple is a great example of that. One of the famous stories that comes to mind is the story where Steve Jobs was wanting a very specific size of font, I think in the calculator app on one of the early Macs—I could be mistaken on that, but the story still tracks, so bear with me—and the development team, they would change the size of the font, and they'd bring it back to him, and he would say, "It's not quite right; it needs to be bigger." And then they would take it back and they would increase the font size slightly and take it back. And he'd say, "No, that doesn't look quite right; it needs to be a little smaller." And then finally, the development team frankly got a little fed up and created the ability for the user to self-select the size of that. They added kind of a slider that the user could move along the spectrum to increase or decrease the size at will, and that was when Steve Jobs said, "Yes, this is exactly what I'm looking for," and that's not exactly what we're doing. We're not adding sliders to every single part of the platform so that the user can create their own designs and things like that. That's a little hyperbolic, but that sort of philosophy of where it makes sense getting the user the ability to make their own decisions can be really powerful, because the user knows what they want more than we do.

And especially since our users are living, breathing human beings, they might change their mind on any given day or in any given scenario for the amount of content that they want to see, what they want to have access to, which visualizations in the Symphony product they want to highlight and have at the top of their list, etc. And so, giving them the ability to do that is really important.

And when it comes to the fact that other people have been solving these problems, I think that there is definitely something to that. However, a lot of some of those solutions are focused on the tool itself. So, taking Tableau as an example, there's a really robust community of people who have been working in Tableau for many years and who have solved a lot of problems for Tableau. They have formulas set up, they have templates for visualizations, etc.

It's really, like I said, robust. However, when it comes to adding that tool into a new toolbox and saying, "Hey, how do I change the way that the bookmark functions when I'm accessing Tableau through their API, instead of through Tableau's desktop itself?"—there's not a lot of content out there about that. There's not a lot of people who are trying to put Tableau as a tool in a toolbox, right? And so, we have had to get really creative and solve a lot of problems just by huddling together as a development team and trying to figure out how to make some of this work, and we've been very successful at that. It's been a great process to be a part of. I mean, like I said earlier in the call, I love being a part of small teams, and I love working with tech to make life easier. And so, getting to be a part of this team and solve interesting problems every day and collaborate on that is in some ways a microcosm of the platform that we're trying to build. Something that brings disparate pieces together to solve unique problems.

MJ 20:50 Yeah. And I think that's a great example and a great point to keep in mind is that a lot of these tools are being used in methods that perhaps weren't intended by the original creators. And I do find that one thing that we've always been very, very good at is when approaching a new problem, trying to look at the tools that we have in our toolbox and perhaps use them in interesting or novel ways to get to that conclusion in order to provide the best outcome for the client. Cool.

And I wonder from your perspective, since we have so many different tools and often, as you mentioned, you are trying to perhaps use them in a different method than they were intended, cobbling things together, breaking things, and coming up with a solution that is truly cutting edge: How do you evaluate when a tool can be used off the shelf, or how do you dig a little bit deeper to come up with methodologies that you might be able to—I don't think this term is widespread, but you know, off-label usage of certain kinds of software packages? What would be the methodology that you and the development team take in that regard?

LS 21:53 Yeah, it's a great question, and it really is the first step of our design process. So, the old adage, right, of in order to break the rules, you have to know what the rules are in the first place. We take the approach of, whenever we are coming up against a new technology, a new problem that we're trying to solve. Let's say we wanted to—there was a time when we were wanting to add additional functionality to what Click can bring to our platform, and that design process started with, "Okay, well, I need to become an expert in Click. I need to know what it can and can't do. I need to know how developers who have worked with Click in the past have interacted with some of the features we're trying to bring onto the platform, so that I know what its limitations are and what it can offer, what it can bring that can get us to feature parity with the rest of the tools in our toolbox."

And then from there, once we have a really thorough understanding of the tool itself and how it might fit into the platform, that's when we get started on splitting up the larger task of, "Let's add X and Y and Z feature from Click into Symphony into those smaller tasks and smaller components of, okay, let's make sure that we are getting the data that we need accurately for saving a bookmark. Let's make sure that we are displaying that correctly to the user. Let's make sure that we're handling the authorization and commissioning for different users that might have access to this visualization correctly." So, it really comes down to: We have to essentially do a lot of learning. We take several weeks throughout the year to—at the start of some of these processes—really dive into tutorials and other learning materials for each of these tools that we're going to be diving into. And then from there, we use that as the springboard to say, "All right, here's how I think we will be able to design it to fit within Symphony."

MJ 24:02 Love that. Yeah. So, taking the time to learn the tools before you start to use them. Definitely a great move. And certainly, the only way that you'd be able to understand the flexibility that you'd have in creatively combining those tools together.

LS 24:17 Yeah, absolutely.

MJ 24:18 Yeah. Well, Luke, it's been super great chatting with you. I want to ask if you have any final thoughts to sort of wrap up and encapsulate the things that we've talked about today. It's been such an awesome journey learning more about the design process. And from my perspective, not being super involved in some of these decisions, it's fascinating to see how much thought goes into each and every step. But what else do you think our listeners might want to know as we conclude and wrap up this topic?

LS 24:43 Yeah, definitely. I think that for me, something that I have learned through the experience of working as a part of this team and working on this product is really that what you want to do when you're building a product is you want to give the users the tools that they need, but not always in the way that they have thought that they always needed them, right? There's a reason that these tools are really popular. There are a lot of people who instantly recognize the name Tableau and Power BI, etc. And it's because they're tools. They're really powerful, and they work. But when we were listening to our clients and listening to our users for what they were needing, they were needing a way to utilize those tools in a new way that gave them insights into their data and the ability to make decisions that they didn't feel they were able to make with just the tool alone.

And so that started us down this path of saying, "If we are just in conversation with our users regularly, we can get an insight into the problems that they're trying to solve and make sure that our platform is addressing those problems." So, a similar philosophy to the "tools fix specific problems" approach, but acknowledging that our client base has some really complex problems that can't always be solved by a singular tool, and giving our clients the ability to pick and choose from a toolbox full of tools for whatever their project might need can sometimes be the better approach. Instead of trying to expand a single tool more and more indefinitely to try and handle every edge case, find tools that really work for a specific problem and then bring those together for your users.

MJ 26:32 I love it. Well, thank you so much, Luke. This has been a huge learning experience for me, and I hope everyone else takes as much from this conversation as I have. So really, it's been a pleasure. I can't wait till the next time, and thank you so much.

LS 26:44 Thank you. It's been a pleasure and hopefully, we'll get to chat again soon.

MJ 26:48 Sounds great. Have a great rest of your day.

LS 26:49 You as well.

MJ 26:50 Bye.