Ivo Gasparatto: Thanks, everyone, for coming today. This is a great event. I'm really excited to be here.

As Jerry mentioned, I've been focused a lot on big data lately, and the work that we've been doing at GE Capital. I came across this really super-relevant quote by an information designer named Lloyd [undecipherable 00:16].

He says, "You'll often hear these days that data visualization is great for telling stories, making the complex simple, and even making boring facts exciting."

"While this is all true to some degree, it misses the greatest quality of data visualization today. It provides us with new kinds of glasses and a different way to see our world."

That's the lens that I want to look through today, when we talk about data and humans. We can leverage core UX and design principles to create environments for people to explore data and hopefully see their world in a different way.

As I thought about this, I realized that I've been doing this throughout my career. I started as a designer at an educational textbook company specifically working on biology textbooks.

What you're seeing is information graphic that talks about the life cycle of plants. Now, it's obviously not big data, but it's visualizing information to make it more understandable to students.

Hopefully, from something like this, the type of visualization, they are seeing their world and the world of biology in a new way. It's not that different than what I'm doing today at GE. We're leveraging data to help our customers see their business in a different way, an entirely different way.

Data, the collection and consumption of it is obviously changing our lives. It's changing our cities, our healthcare, the way we socialize, the way we communicate.

I think it's a huge opportunity for us as designers and UX professionals to make an impact on that. We should be at the forefront of this cultural shift and help people understand the data that they have in their lives.

Let me jump into a little bit about the application that we've been working on. It's called Fleet Optimizer. Just like any good project, you want to start with understanding who you're designing for.

We talked to fleet managers. They were our audience for this application. To get a better context of what fleet management is, let me break it down a little bit for you.

We have a hierarchy of humans starting with the drivers. They're out there on the road. Then we have our core audience for this application, the fleet managers. They're making decisions about the types of vehicles that these drivers are using.

If you think about a company like Coca-Cola, you have a sales force. They're out selling the Coca-Cola in a certain type of vehicle. You also have a service fleet, who are going out and servicing all the Coke machines in different locations. They have different tasks.

Part of the fleet manager's job is to make sure that they choose the right vehicles to meet the needs of the drivers in those specific tasks. They also have to report up to their executives about financials and performance of those vehicles.

When we talked to them, this was their current way of viewing this data, spreadsheets. A lot of spreadsheets, a lot of manual analysis, this was our starting point for the project.

What we found is that we needed to give these fleet managers a better understanding of their fleet and their drivers. Help them make more informed decisions about those vehicles in their fleet.

What we came to, this is the biggest question that we heard was, how to identify the biggest opportunities for improvement. Posing this question to ourselves, to the team, helped us stay focused on choosing the right visualization, choosing the right data to visualize.

It's one thing to have boatloads of data. You can visualize it all day in all kinds of different ways. If you don't have a goal and you don't have a core question that you're trying to answer, you end up without purpose.

Let me jump in and talk about Fleet Optimizer and try to hit on some of the ways that we try to answer that question. On the initial view, we worked through a lot of different visualizations. We came on this simple visualization that uses color and shape.

In this screen, the circles represent vehicles. Groups, clusters of vehicles. The color of those circles represents the performance of those vehicles within that area.

The size represents how much we're spending on fuel. I can immediately identify that the big red circles are not great. Those are my opportunities for improvement.

We also looked at using this map, this geography. Not just to plot our data, but also use it as a navigation system. I can hone in on an area using map controls, that we're all familiar with, something like Michigan. Then dive into vehicle data about vehicles in Detroit. Get a high-level view of what's going on.

If I want to get even deeper into this data, I can zoom in and get what we're calling a data view. Now, we couldn't show this data on the map. It was too granulated. There's too many different elements that we wanted to display, so we had to shift how we're visualizing it.

We have the table view. There's some time series and line graphs that run through. It gives a different view, a different perspective on the data.

What we also realized is that we developed this key design pattern of starting in a macro view, zooming in to a micro view, and coming back out. That was its mode of discovery that we could present to the audience.

Then once that understanding was...they're seeing what's going on with their fleet, we put some controls around the data for them to start manipulating it and forecasting for the future. What happens if fuel goes up by ₵10? What's that going to do to my financial outcome?

Those takeaways are what they could back to their executives and report out. Next quarter, our cost might be something like this.

This is what we've put into place. It's the outcome of this. I'm getting a little bit ahead of myself here. Let me back up and talk about the starting point.

Once we had an understanding of our users through research and interview, we have to look at researching the data that we had. I like to think of the data as the material that we have to design with. That material has intrinsic qualities about it.

With the vehicle data, as I had mentioned, it's a really large scale. So how do we deal with that scale? Those location aspects within it?

It's also different types of data. We have miles per gallon. We have fuel cost, types of vehicles. We have to take all these into consideration because these qualities inform the design decisions we make later on or the types of visualization we put in place.

Sketching is always my starting point with a lot of projects. But with data, you have to get to the real data as quickly as you can because we can sketch, and it's still part of the process.

It's great for ideation, conceptualizing things. It's great to take those sketches and start thinking about what you're going do. But, with data, we have to see it live to get a true understanding of it.

What I did was I brought some of these sketches and initial ideas very early in the process to the rest of the team. The team that we had working on the project is quite large. A lot of people on this project. I started to try and bring them into the sketching process.

This was essential for a lot of reasons. First of all, when you bring the whole team or even your users into your sketching process, it's going be an owned design. We had a common understanding of where we were going with the application.

But also, there's a deep level of expertise on this team. We leveraged that expertise to quickly get to prototyping, so we could actually see this data in real life.

I worked with our development team to create these quick applications, just really rough, just for us to be able to turn things on and off and look at how data could be displayed in different ways.

We worked with our data analyst and their business intelligence tools to actually see the real data and prove or disprove some of our initial concepts.

It wasn't always pretty, but it got us moving in the right direction. Again, we had the shared understanding. We are all going along together.

Now, I realized not everyone has access to a really large team, a lot of resources. There are some really great resources online to start prototyping and start designing with data.

Processing, for me, I'm starting to get into it because it's the languages designed for what's developed for designers in mind. There's a really low area of entry. You can get up and start it pretty quickly.

Then, D3 is something that's some of our developers are starting it get into because of the flexibility to be able to display visualized data in a lot of different ways. Both of these have really rich online communities that you can leverage, a lot of books, a lot of learning materials out there already.

Once we've gone through this process, we understand our users' goals. We have a better understanding of that data, and we got some prototypes and sketches to work from.

Go back here quickly to reference the qualities in our data. We're going to use these qualities to start making decisions about visualization and decisions about our design.

One of the things that we had to deal with was the scale of our data. What we decided was, we could start aggregating that data at a very high level, to make it easier to get into the application.

But we knew that we also had to represent that fine, granular view at the vehicle level. So, we put in place these methods, these interactions to quickly move through that.

I mentioned that earlier, when I was showing the Fleet Optimizer. Creating ways to move through these different layers and levels of data. Another way to deal with scale is, aggregation is not always the best way to deal with it.

It simplifies it, it makes it easy to approach, but you lose detail. So in the case of, when we're trying to show the performance of a vehicle at a vehicle level, a single vehicle, we don't want to aggregate that because we want to see that single orange dot in a sea of green.

By keeping a high density of data, it's a richer experience. Using geography and location, we can do that in a couple ways. I mentioned it first, as this type of navigation system.

Mapping and the UI that goes with mapping is very common now, right? We all use it constantly. It's a great way, again, to move through all layers of data and start honing in on different insights.

The other way we can use geography is as a canvas. We plot out data. In this example, we're looking at alternative fueling locations in proximity to our vehicles.

You can start coming up with insights like "Oh, these vehicles are really close to alternative fuels. Right now, they're gas guzzlers. Could I upgrade and end up saving myself some money in the long run by going with a CNG or electric vehicle?"

This is not that much different than a map on Yelp when you're looking for restaurants, something like that. But it's this idea of plotting out the data on a canvas.

We also had some design decisions to make around the UI. How do we allow these users to filter and change and manipulate the data? We just went with pretty basic UI controls.

People are familiar with this, but it allows them to change their perspective, manage different categories, and really explore the data in an environment.

Some other design decisions were around numeric formats. So, a lot of our data was coming back as a number. But numbers can be misleading, because if I see a number out of context, I don't really know if that's good or bad.

We can do things like show where it's trending, is it going up or going down? We can also abstract it and use metaphors like a rating. People understand rating. Again, it's common. It's what makes data more understandable.

We can use color to show scale and range. I want to know more about color and data visualization. I think Stephanie's graphics showed it really well, in that you can't just rely on color, because there's color blindness.

You have to test for color blindness, but also use color and labels to help with that. That's just a side note.

We can hone in on the qualities of the data to make these kinds of design decisions. We can build a nice application with good UI, but how do we move it to that next level of creating experiences?

With Fleet Optimizer, we tried to put all of these controls in place and make an exploratory experience. I love this quote by Richard Saul Wurman from "Information Anxiety." He talks about it in the way that, he calls the vantage points.

So, seeing information from different vantage points. He has a series of questions. How can I see this in context? How can I remove myself and see it from a distance?

These are the kinds of things that we can build into exploratory data experiences to make it engaging. But I think where I'm looking to take Fleet Optimizer and some other applications we're working with is more of a narrative structure.

Humans really understand stories. We're not there yet with Fleet Optimizer, but something that grabbed me recently was a visualization put out by Bloomberg.

It was a really great example of storytelling, in that it's a journalistic approach to talking about the jobs report and the current state of the economy. They overlaid this journalistic story on a data visualization.

I can move through the story, and it's constantly getting me a visual representation of that story. Even going so far as to pointing out certain aspects within the data. Data's really great for this because it has a historical perspective. It's just a recording of a signal.

We can play back that recording in a historical, linear structure. But there's also certain insights that we want to surface to the user, whoever is doing our data. It gets to the point where we want to present a point of view in certain instances.

I think this is another way that we can take data visualization and move it more towards an experience, and not just a UI. But we also have a responsibility as designers, UX professionals. We're advocates for our users.

There's a lot of conversation about data privacy right now, for good reason. It's probably a whole other talk, for sure it is. But I wanted to hit on a little bit here because the more I've been working with data, the more I'm seeing our role in this change as really important.

There's a story, some of you might be familiar with it, about predictive policing in Chicago. Chicago is really close to me, I've lived there for quite a long time. I have a lot of friends there. We're really concerned with the crime rate.

What the police force did was they identified locations in the city that were hotspots for crime. They looked at historical data of the people who were committing crime. They mapped those together.

But then they took a step further and started looking at the social network of those people, and identified roughly 400 people that they said were at high risk for violent crime. When I first read this I was like "Wow, they leveraged all that data to prevent crime. That's awesome."

But if you think of it from perspective of the 400 people that were on that list, they're targets now. I don't think the intent was to go out and start some surveillance on these people. It was to proactively reach out to them and say "Hey, you're at risk." But it's a fine line.

I think as designers and being in the UX community, this was a real opportunity for us. I want today to be about some of the stuff that I have done at work and what we're doing. It's exciting work.

But it's also a call to action for us to be more involved with shaping how data is changing our world, and looking for opportunities to harness this data for good in the work we're doing. Thanks.

[applause]

Facilitator: Wonderful. We're going to take some questions here.

I have a question for you which is, was there something in the fleet management project, as you were building it, that really provided a visualization challenge that stands out in your mind, that was more difficult than other things, and what did you to get past it?

Ivo: Yeah. It's interesting. We focus so much on geography in this application. But, what we found is that fleet managers don't necessarily look at their fleet from location to location to location. Some do. There's very different types of fleets.

There's a point where we needed to decide, should we even be plotting this on the map? We stuck with it because it was this different way, completely different way to look at the data.

That's why I talked a lot about how map became a way to navigate through the data, and it was less about location specific. It was a challenge. We talked about it a lot within the team. There are some people that, "No, we don't want the map." "Yes, we want the map." So, that was a challenge.

Facilitator: What questions do we have? Go back here.

Audience Member: During that conversation, what were some of the alternatives to the map interface?

Ivo: I think quite often, we go right back to table-based views, but that's not a real departure from Excel. I think a lot of times, we used table-based displays of data, and we're still doing it in Fleet Optimizer. It's fine.

But, it's really how computers like to look at data, because data is stored in computers in these tables, and we just take it from those tables and display it to humans in tables. But, it's not the best way for humans to view it.

We are exploring some other different charting around looking where I'm at currently, so take my miles per gallon performance, looking at that currently on the time series or a line graph. Then, marrying to what I did last year, the same time.

Then also, what are my peers doing. Other people like me. That's a huge part of visualizing data because not even just data. We're all going to make sure that we're doing OK.

Is everyone else doing what I'm doing? That's a huge part of it. I think a lot about bringing in peer data. That's about unique visualizations but more so unique pairings of types of data, I think, is what we're looking at. I hope that answers your question.

Audience Member: Hi.

Ivo: Hi.

Audience Member: Did you use or do you use the same or a similar UI to input the data? Where does all that data come from? Do individual drivers and managers input that in a similar UI?

Ivo: Yes. A lot of the data is coming fuel transactions. Drivers have fuel cards that they use to purchase fuel. We have, at that point, an odometer reading. We have the location of the fuel, how much fuel they consumed from the last time they did that transaction.

All that goes into a backend system. I hope that answers the question. It's not a driver input of data. It's coming from these fuel cards.

Audience Member: I had a question with the user interface experience. What did you find most challenging about using large data sets and trying to basically dumb it down to where it's human readable?

Ivo: I think going through that prototyping process that I talked about was really helpful to start understanding the real scale because we would visualize things like this heat map idea.

We were originally looking at almost like a weather map. There's less boundaries. It's not confined to circles.

But, you'd think with having an immense amount of data, you'd have such variation that it would be a great, awesome weather map. It's like hotspots all over. But, really when it comes down to it, without aggregating it a little bit more, you have just a sea of green.

Some fleets, they're doing OK. It's not as helpful to see just that homogenous view. That was one of the challenges.

Sometimes we expect because we have so much data that it's going to be this compelling visual. But sometimes, it's not. So we have to manipulate it, aggregate it, make it smaller to raise a lot of insights.

Audience Member: Hi. I really appreciate that you're sharing some of the UI patterns along with the examples of the visualization.

I was wondering, as you're working on these projects, are you getting more calls to do data visualization for mobile experiences, as well as desktop experiences, and if you've noticed any particular challenges or things that help out with that process?

Ivo: We've made very specific decisions about this application around mobile. We optimized the UI as much as we can for touch, because we knew it would be used on tablets primarily by sales folks.

They're coming out there with tablets to show things. But it was a true concern. We made a very distinct decision that if we were going to make this work on a phone, it would have to be an entirely different experience.

Some of the other applications that we're doing, we're using a responsive approach to that. But the visualizations are super simplified.

I think when you get into data visualization, you see all these really amazing, crazy new things that fly around in their circles, and there's things like interplanetary kind of stuff.

But truthfully, it's quite often better just to simplify and show it in ways that people can understand it. That's what I found. That approach makes it a little bit more applicable to a handheld device, I think.

Audience Member: When you mentioned that concept of peer comparisons, in that industry or whatever, is all that data publicly available or do you have to get a concept of buying in or opting in from different customers to allow them to see each other or...

Ivo: Yes, we do.

Audience Member: OK.

Ivo: I guess that's the simple answer, yes, for sure because that just goes back to that responsibility aspect. First of all, legally, you can't just use customer's data to show another customer. We're extremely conscious of that. But I think, again, you want to be transparent.

When we're talking about peers, it's abstracted to a point where there's no way that you can identify who that peer is.

If I have two fleets and they're in neighboring towns, we can't just look at this fleet next to you. We have to look at the broader spectrum and come back and say, "This is people like you." There's fine lines there and there's a lot of legal concerns that we work with.

Audience Member: That's probably similar, a different kind of area entirely but this has become an issue addressed...

Ivo: Yeah. It's, again, being transparent and being honest with what we're doing.

Facilitator: I'm curious about that because Facebook has 700,000 privacy controls to give the illusion of privacy.

Ivo: That's true.

Facilitator: Privacy theater, I guess, is the way you can think about it. Of course, there's a whole user experience problem that has to do specifically with how do you communicate what you're giving up when you say, "Yes, I'm OK to share this information."

Have you guys done any particular work around trying to figure out the way to communicate that effectively so people are not surprised down the road when there's like, "Wait a second. You mean you're telling other people about what we're doing?"

Ivo: I can't say that we have crossed that bridge yet because we're just starting to explore what we can do with peer data.

What we are doing in Fleet Optimizer is, vehicles in this location compared to the rest of your fleet in this way. But I think with a more public phasing application or approach, that's more of a concern. But we're dealing with more private scenario.

It's not open to the public, so it's different. On that topic, Mike Monteiro has a great talk called How Designers will...

Facilitator: Ruin the world, yes.

Ivo: ...will Ruin the World, and it's fantastic, gets into Facebook.

Facilitator: Yes. It's an award-winning talk, right? You can see it on the web. He gave it a WebSTAC, so Mike Monteiro's "How Designers Ruin the World" and he talks about the privacy applications. Ivo, thank you so much, that was awesome.

Ivo: Thanks.

[applause]