As a designer, you're always thinking about the users for the products you're designing. Some sort of empathy not just for the end user, but for the guy who's making it, and for the guy who's transporting it, all the stakeholders, its key. We don't want to look at our users as just users behind a screen, but we think of them as real people with feelings and things that they need to get done, and we make sure that we help them get those things done. We leverage the kind of processes of human-centered design which start with the people and ultimately revolve around people as their central kind of element, to make sure that we are answering their needs and we are closing that loop between the research and the design. So, part of the human-centered design is understanding the experience and being part of insights. So, insights is actually using them and then trying to find pain-points and then in understanding the pain-points, you can create a better experience. We start off with research going out to companies and understanding how they work. So, it's not companies that use our products, it's just learning about how companies work day to day, how many screens have they got open? How many tabs? What does that look like? To design a range of pruners, we got several competitor products and we went out and we cut branches and we continue to cut and we found the real pain-point. It was the sap coming around the jaws and getting into the pivot. So, you're cutting away and then the next thing you'll use your little finger to open it and you do this for a while because the jaws are all gunked up and then you get a sore arm. So, we use that information as a source to come up with a new concept for the pruners and that was, a centralized hub which prevented the ingress of the sap, which integrated the spring, and which gave us a basis for anaesthetic which was totally different to anybody else. We've been involved with designing EFTPOS terminals and payment terminals for as long as this company's been around. You think about the user all the time; it comes naturally. You think about the weight of the product, you think about where the balance point is, you think about security, getting the receipt, where the cables are. Are those cables in the road? Batteries, replacement, servicing. Every one of those users we have to consider. When we come to start a new project, we first of all re-frame the problem into something that's manageable. We go through a discovery phase, where we try and get a really deep understanding of what the problem is or where the specific market is or the users. Quite often, the problem that the client brings to you isn't actually the problem that they're trying to achieve or it's a symptom of the actual problem. A designer at Atlassian will work very closely with their PM and the development team lead to make sure that we understand exactly what problem is it that we're trying to solve. So, we find that just asking for a feature isn't always giving us the full story. So, that's why we start off very strongly on research and customer interviews and try to understand the underlying need behind what our users are asking for. So, it's all about research, it's all about observations to get a better understanding of what's required for that product. When you're looking at a design problem obviously customer-centric is the first thing. You look and see what the pain-points that customer's having. But in addition to that, you also want to look at the technical debt that you're going to go into making these type of things. You really don't want to take a risky bet on something if it's going to be a year of development work without actually proving beforehand that that particular implementation is the correct one to go with. We found a good way to analyze problem is to define what's in scope and what's out of scope. As a designer, it's very easy to run off and come up with all this blue-sky thinking and fantastic solutions which actually your client or customer can't action; too expensive, too difficult etc. So, breaking down the problem into what you can and what you can't change, is a great way of making that process happen a lot faster and making sure that that's agreed upfront. So we get that agreed with the client. We identify stakeholders I guess based on, what's the product? Who is it going to be used by? Who's going to have contact with it? The best way to kind of uncover some of these stakeholders that you might not have thought about, is through customer experience journey mapping. So, through this process, we start to determine the key kind of user touch points throughout a customer's journey, touching both your solution or your experience as well as the brand as a larger whole. Using those touch points, you can identify those key people who what you're doing is going to affect. Stakeholders are involved at the beginning. So, you get the complete understanding before you take the journey developing a product. I would definitely want to have a variety of people who would be involved. Somebody from a design background, somebody from UX background, somebody from an account management. So, you have kind of everyone's perspective and idea of what the project should be. After we've engaged our stakeholders, we've got all the stuff we need, we know who they are, we've identified them, it's time to basically download everything they know, so there are a lot of questions. Identifying knowledge gaps is a critical part of what we do, observational research. Say for medical product, it might be a device used by a surgeon. We'll gown up, and go into the surgery and we just observe. Then we talked to them after the surgery and ask them questions, "Do you realize that it took you six steps to do this one action?" That will be a pain- point or that will be an insight that we can then improve on and create a new solution. We try to live the journey, so live the product and live the customer as much as we can. We did a project for CHEP which was looking at palettes, the pallet. So, we did a story of the milk crate. We mapped that journey from the day it was injection molded in the factory, as it was being used by all the different supermarkets, and the guy at the back of the supermarket and the truck guy driving it backwards and forwards to all the different refilling stations and all the way through its end of life. It's not a story that I would read, but we got a lot of information out of it. Obviously there's times when you need to validate and verify that your solutions are satisfying the needs. You might bring them in, in user groups or one-on-ones to have a look at a prototype or sketches or mock-ups, just to get some feedback and make sure you're on the right path. So, when you're doing customer research, a thing that's very important is making sure you don't bias the answer of a user. If you're asking user about a feature and you're saying, "Oh, my God! I really made this myself. Do you like this? Do you enjoy this?" They're going to respond with a positive answer because they want to make you feel better. But if you approach it in a more neutral way, you're getting more honest answer out of the user themselves. So, just as important as having a good idea to research, is actually knowing the psychology of how to research as well. So, if you don't have both those together, you're going to get responses that just aren't valid. Data is truth. Essentially, if it's well analyzed, it's going to tell you exactly what it needs to tell you. These crucial little data points that we can gather and we can put in front of, start to work together with our analytic thinkers and start to uncover some real truths. A user or a customer might tell you one thing, but in the end they might do another. So, we want to work out what they're actually doing and then we want to start asking the questions as to why they're doing it. So, once we've gathered all of the information and brought it back into the studio, we start brainstorming, work-shopping type sessions, dragging in as many designers who are relevant to the project as possible. Mapping out different solutions scenarios on a whiteboard. We got go through a process of prioritizing and you learn that through your research. What's important, not just for users but also for your client and their market. That's when you get into brainstorming, you've got problems that you need to solve and you come up with solutions and then you check them back to those priorities and make sure that you are satisfying the requirements.
