Listen to the podcast here:
Creating UX And Human-Centered Design with Mike Arney
I have a special guest, Mike Arney, the Founder of Halftone Digital joining me. Mike and his company have been working on the designs for Bella, specifically the UX designs. We’re going to talk about the importance of UX design and why a lot of emphases should be put on this as we build products. Mike, welcome to the show. Would you go ahead and introduce yourself and tell people about your background?
My name is Mike Arney. I’m the Founder of Halftone Digital in beautiful Minneapolis, Minnesota. We are a UX brand and user interface design company. We work on digital products from websites and with Adobe on one of their products that’s used by quite a few people. We have been working with Amber and other entrepreneurs and companies in town. We are a design-centric and a human-centered design first company.
That’s probably an important place to start, the fact that it’s human-centered design based, to bring everybody up to speed. When I first started in an early episode with Aaron Keller, I was talking about how they helped me understand the language around human-centered design and that I really wanted to make sure that I have a lot of people involved in this process. I didn’t want this to be an idea that came out of my head and that I went and said, “Would you use this thing?” Often founders can say, “I have this brilliant idea. I’m going to go disappear into my basement for a year, build it and I’m going to come out and voila to the world,” then you then discover that not everybody thinks the way you do or plans the way you do. As it came to building Bella, I knew it was important to bring the community along with me. In fact, it’s the design world that brought me the language that it was called human-centered design. I knew I had to build it with people. That’s where I started. Why don’t you talk a little bit about UX design and human-centered design and how these worlds all fit together as it relates to building software and products?
The best way to think about UX and human-centered design is situated around the word empathy. We’re taking things that have in the past traditionally been less than ideal to use. It’s been hard to use the software in the past and UX has grown as an industry as a reaction to the difficulties that many of us have experienced with software in general in the past. It’s starting to become a requirement. People don’t have the patience anymore to deal with poorly designed software. The way to create good software is to use empathy, to put yourself in the shoes of your users, to challenge your own biases and to understand that you as a designer don’t necessarily know all the answers and I know I don’t but I discovered that via testing with people who will or hopefully will use the product and then understanding that we’re not going to get it right the first time, too.The way to create good software is to use empathy and put yourself in the shoes of your users. Click To Tweet
The idea that we start with our best guess. We put it out there into the world. We ask, “What do you think?” We gather feedback and then we go back, we iterate, we polish a corner that was a little rough before. We chop off a limb that was deemed unnecessary that we thought everybody was going to use but turns out it’s not a feature that’s of importance to users. We don’t need to spend the money on developing it. It’s a long-winded answer but at its core, it’s empathy. It’s understanding how people are using products and how we can make those products accessible and inclusive for all different walks of life. That’s the part of challenging your own bias and understanding that I’m a pretty good designer but I know for a fact that my assumptions are rarely correct.
When we first started and iterating on it, we’re talking a little bit and I said, “By the time it hit the market, we’ll be on something like the fourth version of some of our designs.” When I built the very first part of the product that we later threw away because we switched programming languages and other things as well, we made a mistake and we didn’t spend enough time on the UX design. It was a little bit like designing a couple of screens, and it was more like what I come from in my SAP background.
In the traditional SAP world, I, as an analyst, was designing the screens. They’re nothing but ugly. When there was custom stuff involved, it was terrible. Lots of stick figures and buttons, and everyone always laughed at my little drawings. It’s effective but certainly not consumer grade and not pleasant to use. I can say that about myself because they were my designs with custom stuff but when we met and we’re talking about it about the whole concept of the UX communicates what you’re trying to accomplish. You have to see through a whole design and we spent two months after we had the initial pain point captured, on the UX itself before we did feedback. That to me was unusual in the amount of time we spent and that we weren’t coding at this point in time. Why don’t you talk a little bit about the natural tendencies that people have to want to go to the code and where UX fits in and helps in that process?
We use the analogy of building a home, an office building or a structure pretty often. The tendency to jump into code is the equivalent of somebody who wants to build their own custom house and wants to sleep in their own bed in their new house as fast as possible. We have constraints in the physical world where that can’t happen immediately, but in the digital world, if you decide that you want to move forward with something that you think is great, build it and pay somebody to build it. You better believe this. There are plenty of people out there that will build a subpar product if you pay them to do it and really who are we to say, “You shouldn’t be paying me to do this?” It’s natural human instinct to want to jump into the good part as quickly as possible but it’s rarely the right way to go when it’s a project as big as Bella, for example, that you’ve invested a lot of time, soul and money into. This is something that you should get it right and we plan properly but it’s a natural instinct in a lot of ways to want to jump right in.
Even as I started, one of my first stops with Bella was around the branding and the creative side and who am I going to be. If I jump into this whole and be a software company and it’s capsule dead and as we went forward with the product itself, starting to really realize the role of the UX. Instead of that development, how does a UX design process work?
The idea of divergence and convergence are the guiding principles of UX design. From a practical standpoint, UX design is doing as much as you possibly can to build and design a product and prototype while it’s cheap. There’s a lot that can be done in the early phases that can help you get as close as possible to getting something right without spending a lot of time and money with people writing code. A core tenet is to come up with a lot of ideas like volume is key. No matter what you’re talking about, whether you’re talking about a product idea as a whole or you’re talking about a feature within a product. If you’re talking about, “How can we video conference with somebody on a product or an idea for a new startup?” Volume is key. Coming together, collaborating and looking at all of those ideas and narrowing it down to a few that seem reasonable, this is the divergence portion, potentially either moving forward with multiples to test against or in more cases, a single idea that everybody agrees is a good place to go for testing purposes.
That’s the role of UX in general, is to get as close as you can to the real thing as quickly, efficiently and as cost-effectively as possible before you get into producing the item. Another building analogy that I use quite often is that before somebody starts pouring a concrete foundation for a building, analogous to before somebody starts writing a line of code, you want to make sure that you’ve got this as close to accurate and as close to real as possible. If it’s not and if you jump in too quickly and you start pouring concrete everywhere, the possibility that you’re going to have to bring in a bulldozer and rip that up is high.
To share a real-life example, since we’ve been at this for quite a while. One of the best examples I have, after we had done a couple of months of this UX design process, I went through and had a set of structured questions that I did. I reviewed those click-through prototypes with 30 people. I like to tell people, “If you ever want to check your bias at the door, show your design to 30 people.” You’re not really wedded to features anymore. You’re curious about what they think but they’ll beat that out of you once you start showing it to people. It’s the same for a designer. You can pour your heart and soul in design and they’re like, “I hate that. It doesn’t work.” We had to pull it out.A good designer challenges their own bias, understanding, and assumptions. Click To Tweet
One example we discovered when we first did the prototypes, we made a really classic mistake, we had red, yellow and green. I had a couple of people in my group that was colorblind and they’re like, “That’s a problem.” We had symbols as well as colors but we quickly realize like 11% or something of men is colorblind and we were all of a sudden not going to be inclusive of a chunk of our audience. We have other design components other than the color but we realized we had to relook at that. On a second example, when we did the reviews, we had a couple of situations in which we turned something to the color red. It was simply to indicate there was a problem but what we learned is when something went into the status of red, a certain percentage of people interpreted that as suggesting they were a failure. I remember going through that feedback process and being completely shocked because that was not our intention. We can design things in a certain way but that doesn’t mean that’s how the audience will perceive it when they see it.
It was a scarlet letter where ultimately it’s not something that we had considered that had we moved forward and implemented that. Color may have in hindsight an easy thing to switch but it could have been something much more serious that all of a sudden people start writing code. We get it into a product and we realize, “This is a huge deal. We need to do a lot of backtracking now,” which will give us something to do.
We’ve found some things that were serious problems or hadn’t been thought through well enough to include them. That to me was fascinating, and it keeps you from going into the ditch with your product right out of the gate in the marketplace. Another thing that we did, once we did the initial designs and the feedback, then we entered into this phase like you were talking about the divergence a little bit of actually starting to remeasure the designs. We created these click-through prototypes and heat maps. Why don’t you speak to a little bit of the technology behind some of that and what people can do to check their designs?
We used a program called Maze and the idea here is to evaluate user paths. We’ve got a lot of different goals and pathways within Bella Scena as a product. One example may be to create a new meeting and invite two people as a goal. This was a certain instance where we said, “This is something that people are going to want to do pretty frequently. How can we evaluate if the design that we’ve set up right now, these series of clicks that they will have to go through are valid, intuitive and easy to understand?” We don’t want anybody to feel like they need to google, “Bella Scena how to create a meeting and invite people.” They have instructions on how to do that. Through this program, Maze in particular, and there are a number of other programs that do similar things, we were able to lay out a series of pathways that we believed would perform well and to put that out in front of a series of users. To allow them to walk through these steps and to see via heat maps, via click percentages, via time on screens, if our designs were validated enough in order to move into production was the key.
What was really fun about that is as we were thinking through, because Maze has allowed us to measure how long did it take them to click on something. I’m a brain nerd and I think about neural pathways in your brain and the first time you do things. Often, we were so focused on the design about saying, “We want it to be intuitive.” If anybody’s read Daniel Kahneman’s Thinking, Fast and Slow, there’s the part of your brain that reacts, and then there’s the part of your brain that takes more thought is more deep thinking. We were looking at how long did it take people to click on things. What was second nature because either they’d seen it in many places or it was so intuitive to them or it took a little while or did they give up. I’m like, “I can’t figure it out from your design.” That was to see and to try to measure how long it took people to click it. Maze also gave us some valuable information about its intuitiveness because if they went there and they clicked it within a second or two, we knew we’re on the right track or it took fifteen seconds for some percent of users. Why is that?
Did they not find the button? Was it not labeled correctly? Were there impeding elements distracting them from finding the button? Was it gray when they expect it to be blue? For those hypotheses as to why somebody was not able to perform a task, was another iteration. Something that we’re able to redo, put back in and say, “How does this perform compared to the last generation?”
Another fun thing that we did as part of building out as we were doing the iterations around the design is having this whole human-centered design aspect to it. We let people name things in our product and this one for me was a fun example. The very last second as we were going to validate some of our designs, this idea had come up in my conversations with Ezra about, “What do you do for an on the fly meeting that wasn’t on the calendar?” I was like, “We call it an impromptu meeting.” We measured the whole concept of how often these happened, how valuable it would be to track it and it dusted off the charts. It’s like, “We’re already done with all the UX but they had the worst name for an impromptu meeting.”
We opened it as part of some of the testing we did. We did the Maze and then we did some feedback surveys. We let people name it. We had some funny names, drive-bys, on the flies. We get all sorts of really fun names that people came back with what do we call it and we had several people that named it instant meeting. That’s why it’s called Instant Meeting in the product. It means there’s no planning. It’s happening right now. That was the fun part of the feedback and the iteration because we can’t know how to label every single little thing.
Another really important thing around design, in general, is understanding that when you look at something for a long enough period of time, which doesn’t take very long, you get skewed very quickly. You see things in a different way that your users are not seeing them. You get in a bubble and that bubble forms itself around you very quickly. Knowing that that’s there and saying like, “I have no idea what to name this thing. It could mean all sorts of things for me and my viewpoints,” and what would you get us to do is oftentimes faster and more effective?
We touched about several pieces to our UX and we’re continuing to iterate on the UX even thirteen months later, which I suspect is a little atypical. We keep iterating and improving.It's natural human instinct to want to jump into the good part as quickly as possible. Click To Tweet
Not a lot of small companies or startups get to iterate but we have.
We did the initial UX and we did all of the Maze to iterate again. When I had some setbacks, we had to switch development companies and rip things out and redo things, then we iterated again. We took that as an opportunity to challenge ourselves this time with much more of a slant for digital overload and too much noise in the product. I started thinking about, “Are we overwhelming users with certain components to it?” We started trying to strip things down to their more base components. By the time the product hits beta, it’s been through a number of iterations and feedback loops with people that have made it a lot of fun and really rewarding to do it. Even once you get past that initial prototyping and it is in code land, the importance of running the alpha test that we are running now. That no product survives in the wild the same way it does in your prototype.
We’ve had features and things come back from people. You do your best to envision when you click-through something how you would use it but then when you try to incorporate it into your workflow, you see this whole new series of things for the UX. For us, that has proven to be an invaluable way to iterate again. What I can say about that process is that we’re on about the fourth iteration, the feedback that’s coming is not at the same order of magnitude. It’s what takes it to the next level of polish that makes it that much more useful. That’s what has been interesting. It’s not like they’re saying, “I don’t need a to-do list.” “No, I need that to-do list,” or maybe “How these two components relate doesn’t make sense to me.” The level of what type of feedback is more about, “How I adapt it now,” not “Can I use it?” which was the difference with the click-through prototype.
It’s less about, “Is it functional? Is this thing going to fall apart if I take it out for a test drive?” It’s more about, “How do I streamline my flow by creating a new task?” I’m sure people are starting to explore things like keyboard shortcuts. That level of polish is an indication that things are going in the right direction, too. If you’re not getting some of these foundational elements, going back to the building analogy, if people aren’t finding cracks in the foundation at this point, that’s a good thing.
It makes me that much more comfortable that when I hit the beta, we’re ready. You don’t have people that come up and be like, “That basic test didn’t work.” I like to tell people, “I don’t want this to be amateur hour.”
Nobody should abandon the product and the assignment. You take some time to nail it down as we found out. It should absolutely not be rearing their head once it’s released to a larger audience.
Thank you so much for joining me, Mike, on the show. How would people learn more about Halftone?
Our website’s Halftone.Digital and if anybody wants to check us out, you can do a simple Google search.
- Halftone Digital
- Aaron Keller – Past episode
- Thinking, Fast and Slow
- @BeingWonderly – Twitter
About Mike Arney
Mike Arney is a UX designer and technologist, as well as the founder of Halftone Digital.