Podcast: Play in new window | Download (Duration: 13:46 — 18.1MB) | Embed
Intro
Talk Tech to Me is a series that explores the inside track of cutting-edge tech.
As consumers, we interact with software many times a day. It might be a mobile app, like Instagram, or a web app, like Gmail. And we don’t think a whole lot about the design, but design is an essential part of getting the user experience right. It’s the secret to a successful software solution.
Our guest is Peter Fleming – he’s the head of User Experience at Chariot Solutions. Today, Pete’s going to talk about user-centered software design. He aims to truly understand the user before developers write the first line of code. It’s how Chariot is able to unite business goals with user experience.
We’ll also find out how Pete helped a startup address a challenge that had a hybrid software/hardware solution using design principles.
Host: Sue Spolan
Producer: Becca Refford
Transcription
Sue Spolan: Hi, this is Talk Tech to Me. I’m Sue Spolan. As consumers we interact with software many times a day. It might be a mobile app like Instagram, or a web app like Gmail, and we don’t think a whole lot about the design, but design is an essential part of getting the user experience right. It’s the secret to a successful software solution.
My guest is Peter Fleming. He’s the head of user experience at Chariot Solutions. Today Pete’s going to talk about user centered software design. He aims to truly understand the user before developers, write the first line of code. It’s how Chariot is able to unite business goals with customer experience. We’ll also find out how Pete addressed a challenge for a startup that had a hybrid software/hardware solution using design principles.
Peter Fleming: I head up the discipline here at Chariot that deals with all things user experience. So, working with our clients to help them take a little bit more of a holistic approach to their projects. Whether that’s working with them early on to learn about their customers and how we can better serve them, through the phase of when our consultants are actually developing the software for our clients, I will work with them to sort of support them in what they need from a design standpoint.
Sue Spolan: So why is design so important to software development?
Peter Fleming: I mean, so the big thing is that the barrier to entry for creating software these days is much lower than it used to be. That is, anybody in their basement can spin up a piece of software, whereas it used to take tons and tons of people with tons and tons of expertise a really long time and a lot of money to develop something, whereas it’s a lot quicker and easier now, which means that the barrier to entry is lower. It means you get a lot more potential competition out there. So it’s becoming more and more important to make sure that the thing you build is the best thing for the user the first time out.
Sue Spolan: How does design play a role in software development?
Peter Fleming: Design is threaded throughout the entire project. It’s not research that you do at the beginning. It’s not the pretty sticker that you put on at the end. It’s not the wireframes that you build in the middle. It’s all of that and it’s working hand in hand with the product side of it, the business, and making sure that we’re keeping the business goals and objectives in mind as we’re doing our design. But it’s also working hand in hand with the developers, not just to give them what they need but also to draw them in to make sure that they have a voice in the product design overall. So it’s really about finding a way to weave all those disciplines together to throughout the process.
Sue Spolan: That weaving. That feels to me like an evolution of the practice. Would you agree with that?
Peter Fleming: A lot of organizations out there still think of design as, you know, even if they’ve matured past [thinking] design is just pretty pixels and they think a little bit deeper into interaction design and how the buttons work and even how to users flow from page to page. Think of it like a hierarchy of understanding and they’re getting layers and layers deeper, but haven’t really come to understand that the disciplines really need to work together throughout the entire thing.
Sue Spolan: And that would give a sort of the whole is greater than its parts results.
Peter Fleming: Absolutely. 100%.
Sue Spolan: Tell me about the company that you recently did a project for.
Peter Fleming: Yeah, so a startup recently came to us. They’re a young startup. They just secured some funding through a crowdfunding platform. They are a hardware as a service [business], so they have hardware out there, but then they have a platform that supports that hardware and allows their clients a window into this service. They had built an MVP, a minimum viable product, piece of software, to this end. And it was, it was good for what they needed at the time. It helped them sell this idea. But then they found that it wasn’t really, it wasn’t something that was gonna work going forward for the future. It wasn’t scalable and it wasn’t as customer friendly as they had hoped it would be. They had tried bringing in or working with another consultancy that was pretty much primarily a design consultancy that came in and they helped them figure out a little bit of the look and feel, but they weren’t really getting to the nuts and bolts of the wireframing and the interaction and the guts of it. And really doing the listening to the customer to see what they were looking for. So that was their sort of genesis that led them to shopping around a little bit more and ultimately finding Chariot.
Sue Spolan: So they came to Chariot?
Peter Fleming: Yes.
Sue Spolan: And what did they come with?
Peter Fleming: So they showed up with the MVP that they had developed to give us an idea of the types of things that we’re going for. Of course, we did a discovery session in the beginning so we could learn about their product and how it would work and we came with some pretty high level general objectives, business objectives about what they wanted to accomplish with their business as a whole. But specifically with this software, that we were meant to help build.
Sue Spolan: Walk me through how you worked with them. What was the initial step that you took with them?
Peter Fleming: Sure. The initial step with them, as with most of our clients, is to do a deep dive. I will sit with the client and, you know, whatever stakeholders are relevant for the project and we’ll just learn as much as we can and we’ll soak up as much as we can. And then we’ll typically develop a further discovery plan. In this case with this client, it meant doing interviews with their clients. They had a couple of pilot clients that have their hardware and this platform in place and that they’re using it. And they also have a very large pipeline of clients that are interested in it. So our first job was to talk to them and try to extract out what it was that they found valuable about this and what they wanted in this interface. In this piece of software.
Sue Spolan: Do you actually talk to the clients, and is that something that the previous company had done?
Peter Fleming: No, they hadn’t had any, I mean, the, of course this is a young startup, so they’re very scrappy and the CEO of course, and the other members of the executive team, are always talking to their clients, but not in a structured “discovery” type way. They’re trying to sell and they’re trying to figure out what matters to them, but it’s not really a structured, deliberate interview process and observation process that will help us tease out the things that we need to make sure we’re aware of as we’re designing.
Sue Spolan: So once you did the initial discovery, what did you glean from that process?
Peter Fleming: Yeah, so it was a great process. And you know, I’ll just throw in the note there too, that not only did we do the discovery, but we made sure to include our client, the stakeholders along the way in the process. They were in the interviews with us. They helped us parse the interviews into notes. We ran a very big affinity diagramming session where we had all the notes up on the wall and we were walking the wall and discussing it and teasing out themes and then teasing ideas from them. So we made sure that they were a part of the sausage making so that they understood the real value of anything that comes out of that. And we did glean some pretty big insights out of that and a lot of good ideas. And it really helped take us, you know, the initial hypothesis that we had about what the software should be. We wireframe that up and we did a lot of interviewing and discovery on having potential customers or real customers interact with the prototype. And then what we learned from that prototype we got a lot of things right and we got a few things wrong. And a few things that we hadn’t even thought about. So now we’re in a place where we’re much better equipped to do the next version of the designs, prototypes and visual designs that will really answer the user needs much better. So in a short period of time we were able to really glean a lot and make sure we’re on the right footing moving forward.
Sue Spolan: Did you wind up solving the problem that you were hired for?
Peter Fleming: Yes. I mean, the objective that we were really hired for. The project is ongoing, so the development of it, the building of the software obviously is a big piece of it. But as far as from a design point of view for that first phase, the discovery phase, it was very successful. We really heard, we really listened to the clients, we really gleaned some insights. We developed a really good roadmap or design plan to move forward to make sure that we’re, you know, we identified the desired outcomes for those users and the opportunities for how we can get there. And then all the tactical, ground level ideas, the features and functionalities that can be included to make sure we’re hitting all those objectives for the business.
Sue Spolan: So you did prototyping for this? Right?
Peter Fleming: Right.
Sue Spolan: Okay. so tell me some of the things that you automatically thought, ah, we gotta we gotta add this into the prototype.
Peter Fleming: So when we prototype, typically we’ll start with this process. We’ll start with, I like the Jobs To Be Done framework, which basically means that each screen of the prototype that you’re going to build or each feature in the screen, depending on what, how big of a prototype you’re building. First you decide, what’s the “job” of this? What does the user, when the user opens this application, what did they need it to do? Did they need it to give them awareness of the system? Do they need it to allow them to configure something? What is it that they needed to do? And then we designed the prototype. We come up with our own assumptions, our own hypothesis. In order for the user to do that job, we need to add this feature or this functionality or whatever. So that’s what goes into the prototype. We build that. And then when we test the prototype, we’re learning two things. Is thias really what the customer wanted or did we miss the mark and they actually want something else? And then for the ones that we did get right, if it is something they wanted is the way that we designed it intuitive for them. Did they figure out how to do X or do Y?
Sue Spolan: And then back. So it’s iterative. It goes back and forth and back and forth.
Peter Fleming: Right? So if we learned that we missed the mark on the job to be done, hopefully in the interview we learned what the job was, and then we can design something new. If we learned that we got the job right, but that the way that we designed it was unintuitive and they couldn’t figure it out, we confused them. Then we have to design a new, better way to do that.
Sue Spolan: I think, with a startup, you’ve got a whole different set of problems than you would have with an established company.
Peter Fleming: With a startup, especially if they’re early on in the process they’re worried about whether they’re even solving a problem that needs solving. Whereas in an established business, there is this problem and we are solving it. Now we just want to figure out how to solve it a little bit better. But with a startup, a lot of times you’re figuring out, well, is this really something that needs to be solved? Is this really something that can be monetized? Some people would find it daunting or intimidating. But I think startup world is exciting because there are so many unknowns because there are a million assumptions. So it’s about prioritizing those. What’s the biggest, meatiest core assumption that, if we’re wrong, this whole business doesn’t work, and let’s validate that as quickly and as efficiently as possible. And then we’ll move on to the next assumption.
Sue Spolan: We’ve been speaking with Peter Fleming, he’s the head of user experience at Chariot Solutions. He believes that design is threaded throughout the software development process. Stay tuned for the next episode of talk tech to me. Thanks for listening. I’m Sue Spolan. Take care.