The process behind creating products with user-centered design

For this interview, we sit down with Ben Ihnchak from Fuzzy Math to learn about his design process, his favorite research method and why he believes spending a lot of time on wireframes is really important.

What’s your career background?

I'm a co-founder of Fuzzy Math. We're a user experience design, strategy, and innovation firm based out of Chicago. We have about 20 designers on staff. We've been around for a little over 10 years. When I was in high school in the late nineties, I was part of a startup and we sold things that we liked doing. So we sold skateboards, paintball guns and music. That was the dot-com boom. So, it was brand new. I did not know that you could work out of a basement, on a computer, and with your friends for a living. I got totally hooked. So I went to school for that. Specifically, I got a degree in Computer Science and eventually a Master's Degree in Human Computer Interaction, both from DePaul University here in Chicago. HCI or human computer interaction is a fancy word for UX. I really fell in love with it and started working with the guys that started Fuzzy Math right out of grad school and 10 years later, here I am.

What’s your design process?

I'm heavily influenced by DePaul and the process we learned there. At the end of the day, it's User-Centered Design. We really put the human beings that are consuming information (using the application we're designing for, using the website that we're designing) at the center of the process. We really want to learn about them.

What their process is. What the current state is. Where the pain points are, what's missing, where are the areas that they're really getting confused… and try to smooth things out for them. It's interesting because we're consultants, so we're external parties to everybody that we work with. And you know, the people writing the checks to us aren't necessarily the people that we care about the most. We really want to talk to the end user. And what their current experience looks like and why is it not working for them.

It all starts with research. I'm naturally curious. I like asking questions. I like seeing how people work. I like trying to figure out why they're doing things a certain way and how we can make it better.

What’s your favorite research method?

The best research method in my opinion, or my favorite and most useful to me, is contextual inquiry. Pretty much on every project that's a request. We want to sit next to people. I'm just going to observe them and say, “What are you doing? Can you speak out loud? Tell me what's going on.” Typically you hear things like, “and then I log into this and I do this 30 times a day and I hate it. And I wanna never log in again”. And we're furiously taking notes. It's something that you need to do in person. You learn so much outside of just what's going on on their screen.

Recently we were working with a large insurance company. We're sitting in a service center, and some of the most valuable information we learned was what was around their computer. Almost everybody had post-it notes, or handwritten notes with phone numbers, or a procedure for how to do a thing. And once you started asking somebody, I see a bunch of post-it notes. Can you explain what that is? You learn that it's actually really hard to find the help section or there's no contact information within the software. And so contextual inquiry really is this holistic view of everything going on.

What’s your next step after research?

You get your thoughts out of your head. Typically with some sticky notes. Write out the gist, what did we learn? What did we see? What did we hear? It could be in terms of, let's group some pain points together. Let's group some wishlist things that people just said. Or they use this other tool and it does these things and why can't it just work like Amazon? Amazon filters are great. I know how to search. I know how to use filters. We need to synthesize that research.

We need to take the knowledge out of our brains and get it down onto paper somehow. We typically use sticky notes and get a handful of people in the same room and say, “well, I heard all these things”. You try to get one thought per sticky note, and then you group them together into some themes. We take those and we put together a bullet point list of, “this is what we heard. Here's some problems. This is working really well, and here's some wishlist items”. Then we synthesize that into documentation, like personas or archetype users. If we're working with an application, typically it's going to be a brand new user versus an expert where experts do something this way, new people do it this way. Really trying to define who the right user groups are.

What are the different touchpoints? What are they looking for at different phases of the journey? We like goals. What are the goals of the user? We try to understand those as best we can and put it into documents to share with stakeholders. It's a document that I can give to anybody and they get the highlights of what we just did. Nobody wants to hear hundreds of hours of research. They want to see a story and they want to understand this is what's happening today, these are the problems, this is working really well, and here are some recommendations from us of where to go next.

What is your wireframing process?

We do a ton of education around this point because it is such a weird thing that designers do and we don't really think twice about it. Our process is: we get wireframes put in place by really leaning on all of that synthesis work that we already did coming out of research.

If I was presenting a wireframe to you right now, I don't want to be presenting to Billy Carlson. I want you to pretend that you're the persona that we care about for the project. I want you to think that you're somebody processing claims, sitting in a service center, and that you need to process x-amount of claims or else you're not getting that end-of-year bonus.

I need to build that story for you so that when you finally do see a design, you say, ah, okay, I get it. I understand. I don't want your personal opinion. I want your personal opinion based on the persona we created for you in the context we set up for you. When you finally see the screen, you’re looking at it to say, ah, yeah, it's a list view. I totally get it. A list view makes sense because the tasks that I would be doing if I was that person are X, Y, and Z.

A lot of what we do is education and a lot of that relies on some level of research and synthesis to explain who we are, what we're doing, what our tasks are, and then a lot of education around why wireframes are black and white, with maybe a little bit of color for links. It’s kind of ugly on purpose. It’s really to highlight the information hierarchy. The page priority, the navigation… And the easiest way to do that is to remove all colors, so we don't have people saying, well, I hate orange.

We’re not there yet. We're really trying to figure out if you can find that big button that says “next”? Can you figure out how to move from this page to the next page? And that's what wireframes are really, really good at. Really focusing on what's the most important thing on the page, purely based on information hierarchy.

We spend more time wireframing than on anything else because it is critically important. I want to get it right and I want to get it right early. Changing a wireframe is so much faster and cheaper than changing the visual design. An order of magnitude cheaper than changing code, especially front-end code. And then if, IF things get into production and you still have to change them, you're spending a lot of money and a lot of time you probably don't have as consultants. So wireframes are a great place to iterate. You can do it pretty quickly. Get it in front of people. Say, “Hey, we're thinking about doing this for the dashboard. What are you thinking?” And get some feedback and really quickly iterate on it.

What happens after you launch or finish a project?

The short version is the work is not done, it's just the beginning of a new phase. We're an external party. We're consultants, so we don't get to own any project that we design, ever. In some ways it's nice, in some ways it isn't. But, you know, we worked hard for probably a couple of months on this thing and we have this really nice package. At minimum visual design, typically some front-end code and we send it off to our clients. It kind of goes into a black hole, but at some point it becomes real, and then, you know, it's probably not us anymore, it's probably their internal team and the process basically starts over again. Now we have a new thing and something is going to change. If it's external competition that adds a new feature, we have to catch up or the market shifts. Whatever we’ve designed is kind of static, but it should be a living thing that should change. And the reasons for change should be more testing and more user research. This thing works so much better than what we had. Let's not wait 3 more years until it's terrible again. Let's make small incremental changes over time because that's a whole lot easier than letting it sit there and get old real fast.

I've never left a project thinking, Oh man, that thing is 100% perfect. There's always a wishlist of things you didn't have time for, or we didn't have a budget, or people just didn't think it was a good idea, which is probably right a lot of times. There's always a list of stuff, and I think it's just learning, let’s release this thing, track some metrics and check-in every, you know, every 3 months, every 6 weeks, whatever makes sense for the organization. But I think saying that we're done is incorrect. This phase is done and now we have this new thing out in the wild, but we still need to take care of it to make sure it's the best thing it can be.

---

Well that is it! I hope you all enjoyed learning from another talented product creator. Please reach out to us if you have any questions, and as always, Happy Designing.

---