Scott Ryan-Hart Hi, my name is Scott Ryan-Hart and I am a user experience designer at Nationwide Insurance headquartered in Columbus, Ohio. And this is my IA 20 talk, the reemergence of the Rolodex in digital form. Thanks for viewing. Scott Ryan-Hart Before we get moving, I feel like I need to mention that there's a pandemic going on. Because that seems to be how most people in the work world are couching most things at the beginning. Most of the emails I get for work right now are in this in these chaotic times. You know, all those things, and it I mean, I'm kind of making fun of it. But on top of making fun of it, it is a terrible thing. And it is a hard thing. And people are in very stressful situations right now and some people are doing very poorly because of the actual virus but also because of what's going on in the world associated with the virus. The second day. trauma that's associated with being cooped up in the house for a very long time. So not to make like a light of any of that right now. But actually just acknowledge that that exists. And it's hard. I would much rather be meeting with all of you in person face to face, I'd much rather be giving this talk in front of a room of people, assuming I would have gotten a room of people. And I missed the fact that we're not meeting together and having an actual face to face interaction. My actual job title at Nationwide is interaction designer, and I really do like interactions. So without further ado, here's my talk. So back in 2016, one of my business partners for a group called promise 2020 came to the US Department and asked for help with their life insurance pending Business Report. Life Insurance is a bit of a process to get in If you are wanting to get life insurance, and I suggest most people do as an agent, you will as a person who wants it, you will go to an agent and say, Hey, I would like to buy some life insurance. And that agent would be like, great, I would love to sell you some life insurance. And you'd sign some papers and it would go into the insurance company. And once it went into the insurance company's hands, it goes through this process called underwriting. underwriting is basically just where the company that is going to insure you make sure that you're worth ensuring that you're not a high risk or if you are a high risk that your premium that the amount that you pay us to insure you is make sense. So that underwriting process is actually a bit of a process. There's going to be potentially some interviews, there's going to be maybe a medical exam. There's going to be records, medical records, depositions, and those kinds of things. And It takes time. I think the fastest I've heard of a life insurance policy going through from being requested to actually being fulfilled and signed was, I think, maybe like seven days, which is super, super crazy rare. Scott Ryan-Hart Most of them take around 38 days, maybe a little bit less, maybe 33 to 38 days somewhere in that range. And ones that take a long time end up taking, you know, at most 90 days, tends to only end at 90 days, because at 90 days, with the way that some of the commissioning scheme goes, those agents lose the commission that they made on that if it's not done in 90 days. So a little bit more about the report. The report is for agents, it's for their managers, and it is for like regional managers as well. So there's three levels that are associated with it and an agent may have you know, none Or maybe up to five or, like if they're really go getters, eight different life insurance policies going on at the same time. Through the underwriting process, they have a much larger book of business. But this is their new business that they're dealing with. A managers have to look at the book of business for all of those agents. So it kind of goes up. And then when you go up to regional people, it goes even more. So there, those regional people end up getting 400, 500 cases that they kind of have to, they have to be able to look at it all the time. It doesn't mean that they are going to look at the details associated with each one every time but they have to have the ability to view into them. So each one of these cases that come in that need to be represented in life insurance. Pending Business Report, has 20 to 40 different data points pending on what kind of insurance policy the person is going after. Things like the day that the insurance policy was submitted. The beneficiary's name, the actual the agents name, the person that the insurance name, just things like that how much the premium is going to be on the insurance. So just all of those data points are associated with each one of those entries. And there's around 20 to 40 different data points associated with them. And so that table gets really robust, very quick. Currently, at the time, current current state at the time, the data needs, the data was not real time with the current at the time life insurance pending Business Report. And they really needed that data to be real time. So that was one of the assets associated with it. The other piece that they brought to us is that this data needs to be presented mobile first. 20% of all the traffic to the surfacing site is on mobile platforms. That number is only going to go up because more and more mobile platforms are coming on, and people are using their phone, and they're actually using tablets more and work environments than they ever have. So making sure that this report is mobile friendly, is really paramount. So the problem is that the current version of the of the report at that time was a weekly spreadsheet that was sent out every morning at 730. In the morning, I mean, every Monday morning, sent out at 730 in the morning, so if a potential client came in and asked you what was going on with their particular life insurance case on a Thursday, your data's already four days old. So you end up having to call our VA nationwide call center to find out what's going on with the case. You as an agent don't have view visibility into the details of what's going on in that pending business. The technical problem that's associated with it is that because life insurance is, is so cumbersome, there are four different databases that don't talk to each other. So the technical behind the behind the scenes architecture was to create a fifth database that those databases poured into temporarily. That so that that data can be pulled from the temporary database. It's a it actually worked out really well. And they were getting good feedback on how that database was working. And they were just ready to start giving the information to the agents so they could keep up. Scott Ryan-Hart But what was really the problem? The real problem is that there was an extreme short time horizon. I believe everyone who's ever worked on anything knows that there is always the ask is always that time is going to be a factor and this one was no difference. The other issue that really came up that was surprising is that the user base for the life insurance pending Business Report is transient. They, there's a huge turnover rate associated with with the lowest rung of the ladder. Because these are the people who are the very bottom of the life insurance game are people who are also Uber drivers, or are other aspects of the gig, the gig economy like doordash or TaskRabbit. So when they're not driving for those gigs, they were selling life insurance to their friends and family. And what a lot of these people find out after doing for about a month or two is that they don't like selling life insurance to their friends and family. And that the benefit of doing that is not does not outlay outweigh the the pain points of actually going through the process. So there's not much expertise in the actual user base. Because the user base, the user base turns over so quickly. So the other big problem was that tables are easy to develop. And our business partners, were already ready to use a table. So what did the existing report look like? It was horrible. So this is the information that they could actually dig to in our servicing Center. This is not a picture of the the spreadsheet that is sent out, I never was able to get a good copy of the spreadsheet. And when I did, I had so much like personally identifiable information that it could never be shown in public, really. So the existing report, as you looked into the servicing center would do is on the left of the report, you know, the left the left side of this image is basically what the overview looked like it showed what how many cases a person had. where, you know, Scott Ryan-Hart What the total amount of premium was? And then on the right, we get into a little bit more detail of who's the person working on it? What's the contract number associated with it with it, who's it assigned to that kind of information. But it was presented terribly, and it was hard to read. The business partners wanted a table. So why do we use tables now? Scott Ryan-Hart You know, how did tables come about to actually be a thing? The big reason is that tables are simple and easy to understand. You have a you have rows of entities in rows, and then aspects of those entities or attributes of those entities in the columns and you just match up the entity with the attribute and you know what you're talking about. So it's, it's intuitive, it makes sense. Who doesn't, You know, who doesn't understand an x y thing? Or if you're a programmer i j, because it's basically tables are two dimensional arrays. Scott Ryan-Hart So where'd they come about from? Well, the history of the tables super long. Scott Ryan-Hart Tables came about in the Middle Ages, with the office of the x checker. The the actual reason it's called a table is that the x checker actually worked at a table with a checkerboard that was drawn on it. And the x checker would use markers on these tables to indicate who owed what to whom. So the table actually became a data table. What was interesting is that then they would take the information that they encoded in the data table, and then they would, they would translate that into a ledger book. And that ledger book is basically a pivot table of the physical table of information that they put together. Scott Ryan-Hart It's so really when when you're talking about the Office of the Ex cheker being the origin of the table of information, it goes back a long time. So we as people in our society understand tables almost intrinsically. So why don't tables work for mobile? Scott Ryan-Hart Well, I mean, it's pretty easy, why they don't work, scrolling, scrolling and scrolling, teeny, tiny font size. And the cells of the table usually cause text wrapping, because if it's if there's a large bit of information in the cell, and the cell is not the right size, or you can't read it, it's going to wrap and it's going to become even more cumbersome within the space. So here's kind of why they don't work. You know, why don't tables work in, in a space? Well, because if you're living Looking at a website that has a table in it, and you're on a phone, you have to scroll, you have to scroll along to get to the all the information. This, what I'm showing here is a mock up of the amount of information that is associated with the pending Business Report. The the number of columns that you see is basically the number of columns of data that we had to encode into our pending Business Report. So as you can see, it's super cumbersome and you can't read it, it's hard to follow. So that's kind of why tables don't work for mobile. Scott Ryan-Hart So how do we start breaking the information apart? Well, we had to determine kind of what information was absolutely necessary. There was a little bit of user testing associated with that where we kind of asked agents you know, hey, what do you look at when you need to find out what's going on with your tables. With your information and so we kind of found what the the basic information was to be able to differentiate from case to case to case. And then how should that information be grouped? Should it be grouped just by the most important information or should similar information be grouped together and you know, kind of packets of information. So, our solution was to explode the table the table into a non tabular format, but to keep the data searchable and sortable. So we basically removed the structure of the table to work differently. So our solution was to take that table of information and we put the summary table up at the top. So this is all the summary information right here. And then you can Sort, and you can filter and then you have each case of the pending Business Report. Now those of you paying attention will see that these are the names of people in Street Fighter. Scott Ryan-Hart Because why not? But this was basically our, our, the way that we solved the problem is we made everything to be cards of information with the information organized where you could actually read it relatively easily. So that was what we did is we exploded the table into basically a deconstructed table. Hey, wait a second. That's a Rolodex or a card catalog. But Rolodex is a more fun thing to play. With so but our version is digital and it's sortable. And it's searchable because the intrinsic nature of the data behind the scenes is actually a table. And it's taking that information and exploding it from that database onto the cards to not be presented as a table of information. So when should you use this? Because it's not a panacea, it shouldn't be used for everything. Basically, when space and screen real estate is at a premium, so you don't have much space and you have lots of data, you probably have to break that data up into even more easily chewable spots. Scott Ryan-Hart When you're not comparing records with other records. You can't necessarily compare card to card because the cards are separated. Scott Ryan-Hart So really, the what works best is if you're working with normative information, information that just kind of describes what's going on for that record. But you're not comparing it. So it has to be this this, this demographic almost level of information associated with the the record that you're interested in. And the when you get done that record needs to be scannable. You need to have a you need to be able to at a glance to understand what's going on, or you kind of didn't, it didn't work. So when should you not use them? So when should you not use this kind of data presentation? Well, when there's enough screen real estate and your user base is based in tabular information, also when your datasets are so large that it really can't be broken apart. You also when you are comparing one record against another and need to compare those similar attributes, you need to be able to look at them all at the same time. Scott Ryan-Hart That's basically when you're not supposed to use it. Scott Ryan-Hart So in conclusion, it can work in many instances, it can be very elegant and easy to read scannable and easily digestible. It's not absolutely necessary when the datasets are so small that you can actually view them all in one glance. And it's not good when data has to be compared. So use it use it when it's supposed to be used. But when you have the opportunity to explode a table in a mobile space, I'm going to suggest it because it just makes the information easier to read. So thank you very much. I really enjoyed doing this and I hope to see some of you in person. Thank you. Transcribed by https://otter.ai