Steven Striegel is sole product designer at San Francisco-based Mux, a video analytics platform with clients like PBS and Funny or Die.

We had Steven on to share his career journey so far: from college in Fargo, North Dakota, making the West move to join tech-based startups in the software-as-a-service economy.

Topics include:

  • what the “product designer” job title entails
  • how to work efficiently with a team of engineers
  • which feedback loops Steven endorses for soliciting customer feedback and quickly iterating product designs

For the full text transcript see below the fold:

Audio:

Play in new window || Download

Video:

Play in new window || Download

Max: Welcome, all! Max of the Accidental Engineer here.

Today we’re joined by Steven Striegel. Steven, do you mind introducing yourself for those of us who might not know who you are?

Steven: Sure. My name’s Steven Striegel. I’m a product designer at a company called Mux here in the Bay Area.

Max: For our audience, what does Mux do?

Steven: Mux is in the video technology space, so what we do is help companies stream video online.

Specifically, our product is an analytics tool, so helping show all this data to engineers and managers about how their videos are actually performing so they can make better video online. Because, let’s be honest, a lot of streaming platforms are garbage and they need to be improved. So yeah, it’s a fun space.

Max: For our audience that doesn’t know your background, I know that you grew up in North Dakota nearby Fargo and went to college around there, and you spent about 3-4 years after college as a designer in marketing and product.

What made you decide to move out San Francisco, Bay Area?

Steven: The burritos. I like the burritos. You just can’t get good burritos in North Dakota.

Max: That’s fair, okay.

Steven: I’ve been all over the map, I guess. I started out more on the marketing side and had a business degree, but I always kind of took design classes on the side and had an interest for it, but I didn’t really know it was a thing.

In the Midwest five, six years ago, it was, like, designer, like, “what is that? Is that actually a role? Or is that just this side thing people do?”

So I slowly worked my way into the graphic design side and would just do marketing brochures and stuff like that, and turned that into more of a actual design role on the marketing side and then slowly got more into products and doing product design.

Which I really loved, I was excited about and then realized there’s a lot more of that happening out in the Bay Area.

Design is leading more in companies–it just seemed like the place to be for technology and design, and I can meet other designers and learn from people and all that. So, yeah, I was just excited to dive into all that goodness.

Max: I realize you worked a little bit less on the product side of things when you were in Fargo.

What was the name of the company you worked for? And what was their product?

Steven: Yeah. It was Intelligent InSites. It was in healthcare tech, actually, which was really interesting. It was rewarding because we were helping hospitals and clinics improve their workflows and stuff like that.

It was kind of a cool space that I was brand new to and had to dive in and learn a lot about the healthcare industry and how screwed up that is in that industry.

Like I said, started in the marketing side and was actually a product marketing manager for a little bit but still doing design work. And yeah, doing a lot of different things as you do with startups.

Max: For sure. Moving out to San Francisco and joining tech company LeadGenius and then now Mux, what were some of the contrasts as you started working more and more on software products?

I guess the company you worked for in Fargo also did software, but what were some of the contrasts?

Steven: Oh, yeah, that’s interesting. I think there’s a lot.

I think, back in Fargo, it was more traditional software companies around there for the most part. We were progressive on some of our product development and were changing a lot as I was there. But yeah, moving out to the Bay Area, everyone’s definitely more progressive and continuous deployment and working really collaboratively with engineers was a new experience for me but really great.

Max: Does continuous deployment mean that–in contrast to previous companies you worked for—companies here in the Bay Area are faster in developing and iterating their products?

Steven: Yeah, definitely, just putting stuff out there a lot faster and I think more respect for design. I think early on, well, and design was just newer in software in general and it wasn’t taken quite as…it was taken seriously, but it wasn’t as much of a priority.

Whereas out here you have to have a designer on the team, right? Design has a seat at the table if you want to say that.

Max: For our audience that are engineers, what have been some of the experiences you’ve noticed about working directly with software engineers on the product side of things at Mux?

Steven: Things I’ve noticed? What do you mean?

Max: Processes that may or may not work, or feedback mechanisms for you to successfully hand off designs that you want implemented or tested out?

Steven: I don’t know how to describe this.

Max: It’s okay—is there a regular periodicity, a daily meeting that you guys have that has an effective practice?

Steven: Oh, actual process. Yeah, we do all the standard startup things, like stand-ups and…

Max: A lot of our audience may not be in startups, they may be in larger companies and may not even know what a “stand-up” is!

Steven: Let’s see. All right, well, a stand-up we do once every day in the mornings and everyone stands up.

The idea is that it’s supposed to be a short meeting so you don’t want people sitting down. You share what you’re working on that day and what you hope to complete by the end of that day and if you have any “blockers,” and it creates more transparency. Everyone knows what everyone’s working on…

Max: A “blocker” is what?

Steven: A blocker, design is an example. If I don’t have a user flow or a mock-up finished for some aspect of the product or this feature, the developer can’t work on it yet.

Or they can work on it, but they’re not gonna have designs, and it’s gonna be slower and maybe not come out right or something like that. So that would be a blocker, if they’re waiting for me to finish a mock-up.

Max: Are there improved processes around handing off from design to implementation on the engineering side?

Probably, back when you were in Fargo, it was as simple as emailing a person, right? Like, “here’s a PNG file or a JPEG or whatever”, but in the Bay Area, people have a way of making things extraordinarily complex. So what are your guys’ toolkit for handing off and iterating on design engineering workflow?

Steven: We use a lot of different tools, but people get hung up on tools a lot of times.

Like, “Oh, what tools does a designer use? What does the engineer use? How do you hand off…”

I don’t know. I’ve always been using different stuff, and there’s always new stuff coming out. It’s actually a fun time period to be working in design and front-end stuff because there are so many tools. Everyone’s trying to figure out how to make that a better process of handing off between a front-end engineering team and design.

Max: On the product side of Mux you guys have a pretty data-intensive product in that you are surfacing data back to video publishers who have videos that are streaming on their web pages or in their native mobile apps.

And you guys are trying to provide feedback and visibility of some kind to these video publishers about how the end user is experiencing the videos. Like, “are they getting the high-resolution version of the video?”

Am I doing a good job of explaining it?

Steven: Yeah, no, you’re right on, actually.

Max: Okay, so what are the design and engineering roadblocks that you guys are circumventing at this point?

Steven: Roadblocks or problems that we’re trying to solve?

Max: Problems you guys are trying to solve.

Steven: Yeah. I think it’s interesting just because, in general, companies don’t have awareness to that.

You would think, when you’re watching something, whether it’s on your smart TV or your phone, and you’re waiting for buffering and playback fails. You can’t even watch the video, and you get super frustrated and annoyed, and you’re like, “How’s this company so shitty at doing this still?”

And it’s because a lot of companies just don’t even know. Sometimes they’ll get failures or errors at least, so they’ll know if videos are completely failing.

But some companies just don’t even have any visibility into that. So I think, first and foremost, it’s interesting to surface what’s actually happening for the users that are trying to watch videos for these companies.

Especially a lot of startups just create a mobile app. You’re worried about just getting a video out there and if it’s actually performing. Things like that become secondary sometimes, and there’s so many other things to be solving.

So I think it’s important that we surface some of these things in general and give you a place to see, “Hey, how are my videos actually performing? Are people actually able to watch them? If they are buffering or failing, where’s that happening then? Which titles are the worst?”

Max: I guess your guys’ product isn’t oriented towards a consumer like me who’s publishing to YouTube but rather someone who might be using a non-YouTube hosting service?

Steven: Yeah. You know, we can do things with YouTube and stuff too. But mainly helping companies that are trying to create their own streaming product or doing streaming on their own platform.

Max: So in 2D data visualization land, what are the problems you guys are working on? I know you did a blog post not so long ago about your design process for data visualization.

For our sake, do you mind rehashing a little bit about what you’ve been working on in your time at Mux so far?

Steven: Yeah, I’ve worked on a lot of different stuff. That was a fun one though. What you’re referring to is that we redid all of our charts in our product, which sounds like not that big of a thing, right? Like, “oh, you pick a new charting library” or something like that, and you implemented it, and all your charts change.

But it’s definitely a big thing, especially when your product is an analytics tool, right? The way you’re visualizing data is the main thing you do. So we wanted to take a really deep dive at that and make sure we were thoughtful about it. And what I wrote up is our process and how I went about approaching this.

You’ll hear things internally sometimes like, “Oh, I wish our charts did this.” Or you hear something from a user, like, “Oh, this was confusing.” Or they find out they weren’t using it the right way.

So my process was gathering lots of feedback, whether it’s internal or users saying different things, and using different data that we have and measuring how these charts were being used. Aggregating all that and figuring out, “Okay, these are definitely problem areas.” Like, “We could really improve this,” and clarifying that with the team.

Then we can sketch out a bunch of different solutions of how we can improve those issues with our charts and went through mocking up and prototyping different types of charts and testing them out and getting feedback on them form the users and, yeah, then we built them and put them out there. That’s a really quick summary of it.

Max: Where did you learn about how the best practices of data visualization work? And how did you inform yourself before going to the drawing board and trying to communicate with internal and external stakeholders about what “works” in data visualization?

Steven: The dos and don’ts–I wouldn’t call myself an expert on it. Actually, if you look at most of my jobs, they’ve all been with data-heavy tools. So I’ve worked with data for a while, but it’s such an interesting area because it encompasses a lot.

It combines these different worlds of data visualization as aesthetics and visual communication and how something looks and how you’re perceiving it.

But at the same time, it’s using all these calculations and all this aggregation–things that are happening on the backend. But, no, my background is that I read a lot of Edward Tufte books.

Max: As opposed to your undergraduate degree? Did you find that you learned a lot more about what you’re doing now post-college graduation? Or did your college degree have much in the way of preparing you for the data-visualization-specific type of stuff you’re doing now?

Steven: Yeah. College didn’t really do much. That was all on my own.

Max: This is common among our guests so far.

Steven: Yeah. Well, I think, especially with designers and product designers it’s such a new field. I think now it’s becoming more popular obviously, and you have more people graduating with actual design degrees and stuff like that. But the majority of people I meet that are really talented product designers, they’ve taken it on their own and found their own path into it and come from all sorts of different backgrounds.

Luckily, the good part is that a lot of people create great resources and tools and stuff out there to, you know, help educate yourself and figure out what product design is and learn about things like data visualization.

But yeah, it was more me just finding out what are some good books on the subject and reading those. And then a lot of trial and error. I designed some shitty data products in my past, learning how those didn’t work, and what best practices are and why those didn’t work and then read something, like, “Oh, yeah. Why did I display that table when I should have had this type of visualization?”

Max: A lot of our audience–being engineers–don’t have as much responsibility to go out and seek feedback or elicit feedback from paying customers.

We’ve talked previously, before this recording, about how you guys at Mux solicit feedback from your customers. For our audience that doesn’t have a career yet in doing the type of work you do that’s customer-facing, how do you solicit feedback from customers around informing your product design?

Steven: Yeah. This isn’t called the Accidental Designer! It’s the Accidental Engineer. Is that what you’re trying to remind me of?

Max: Yeah, go figure :)

Steven: Yeah, we’ve done a lot of different processes at the companies I’ve worked at, and in general it’s a good rule of thumb to get your engineers in front of customers and see how people are using a product and not just having data for that.

People say have analytics set up and know how much people are clicking on this and all that. And that’s great, but there’s no substitute for having an engineer sit behind someone using the product. Because it helps future conversations, you know?

As a designer you’re steeped in that all the time, and you’re looking at the data, and you’re knowing where the problem areas are and what you can improve and all that. But a lot of times, engineers are like, “Oh, yeah, I know it’s painful for that or this workflow or to do this.” But when they actually see someone do it, it just totally changes the conversation… on the good side too, they see the joy, and they see what parts of the product get people excited too.

Max: Is there something prescriptive that you can give us about how teams should, or engineers maybe, on a weekly basis, sit down behind a customer and watch them use whatever software product the engineer is building?

Steven: I mean, it’s hard. I don’t want to be too prescriptive, because it’s different for every company. It really depends what you do.

If it’s a consumer-facing app versus some giant enterprise product it really varies. What does your design team look like? What does your engineering team look like? The size of that depends.

Everything, I guess, kind of depends.

But if you can set up some regular cadence for that, I think that’s really valuable. We do that at Mux, actually.

We have a weekly feedback call with customers. Every Friday morning we’ll have a different customer on the phone with us, screen sharing and having them try out some new feature we’ve designed and put a prototype in front of them or something like that.

If there’s a specific engineer that’s working on that with me and they’re gonna help me build that, we’ll have them sit in with us, you know? It creates a great relationship, because then you take different things away from that. Sometimes engineers are coming up with better design solutions than I am afterwards which is totally fine.

When I can work with engineers that can come up with better design solutions than me that’s awesome, right?

Max: Perfect.

Steven: I’ve gotten over having an ego in that area. A lot of designers think that they have to come up with all the best solutions and ideas for designs. But I think sometimes as a designer, you’re just facilitating, right? As long as you can get out the best solutions, it’s a win.

Max: This is a topic close to both of our hearts because we both live in the San Francisco Bay Area:

For our audience that’s outside of the San Francisco Bay Area, or even outside of other tech hubs, maybe in Fargo, North Dakota, what are some of the trade-offs that you encountered in moving out here career-wise and life-wise?

Steven: Trade-offs, well, I can’t say that there’s a lot of trade-offs, right? I was in the Midwest, right? And I was very much ready to get out of the Midwest and try something new.

For me, I had written off a lot of different things at that point and was just ready to cut ties with the Midwest for a little bit and do something like San Francisco or New York.

Then career-wise, I don’t see a lot of trade-offs. I think more of the trade-offs are going to be individual and personal. Some people have good situations in other areas, but if you have the opportunity it’s a great place to be and all that. If you work in the Tenderloin in the middle of the city, and you have people shooting up right outside your office, maybe some people don’t want to have to deal with that. It’s still a big city, and there’s interesting stuff, and San Francisco has some things to figure out.

Max: We can leave it at that.

Steven: It is its own identity I guess, but career-wise it’s definitely a great place. I’m still amazed with some of the people I get to meet at different events. People you look up to and follow on Twitter or watch videos of online. Just being around that and being able to strike up a conversation with anyone about something you’re passionate about is really cool.

Max: Is there a different distribution of businesses here in San Francisco versus the Midwest when it comes to design role opportunities? I don’t know if video performance analytics is necessarily something somebody might dream up as a startup out in Fargo. Are the job opportunities out here, besides compensation, very different from how they are out in Fargo?

Steven: Well, yeah. Obviously, it’s the epicenter of all the startups, for better or for worse.

Max: True.

Steven: Fargo, though, I have to give a little plug to Fargo, because it’s got its own cool, little tech scene.

Max: Let’s fucking plug Fargo.

Steven: Yeah. It’s got a cool, little tech scene happening there. It actually has Microsoft’s second biggest campus, so, you get a lot of talent and stuff that in the area. And the downtown space has some cool startups.

Really, it’s a town that supports its businesses and especially small ones and ones that are growing. The community is just really behind it, and there’s lots of TEDx events and stuff like that going on all the time. You can’t knock Fargo too much.

Max: No one should be knocking Fargo.

Steven: But compared to, yeah, obviously, the Bay Area, there’s just more, right? There’s just more startups, more companies, more opportunities. Especially with design, companies that value design out here, it’s just really cool to see.

Max: One of the things that I found surprising moving out to the Bay Area is how much more prevalent working from home is, or distributed teams–where members of the team are geographically all over the place. And during the course of the weekday when people are working, business hours-wise, you have a distributed team where your designer might be in San Francisco, your engineers might be in, God, who knows, Brazil or Missouri.

What’s been your experience with the trials and tribulations of working with co-workers on a less regular basis than you might have in Fargo, where people might work from home two to three days a week? How do you guys keep your productivity up as a product team at Mux?

Steven: Well, it’s all the amazing, great solutions that people are creating out here making everything easier and more simple.

Max: Specifically though?

Steven: No, I mean, really, tools like Slack. There’s lots of just collaboration tools that we use on a day to day basis that make it easier for people to work together remotely.

I think remote work is gonna become more and more of a thing, and there’s gonna be more stuff to support that. Getting comfortable with working with people remotely is obviously important, and I think once you do it allows more flexibility, and people can be traveling all over the country and still cranking out products, and, yeah, it’s kind of fun.

Max: I think we should, absolutely, before we call it a day, give you a chance to plug any roles that Mux is hiring for. We’ve covered a bit about what you guys do, but are you guys hiring right now?

Steven: Yeah, definitely. We’re growing, we’re always looking for engineers. It’s a developer product, so, yeah—or if you’re working on video, I know a good company that makes tools to help build video, so, yeah.

I’m also on Twitter and usually respond to stuff and would be happy to answer any more questions.

Max: We’ll include links in the show notes. I want to plug real quick that you guys should totally subscribe to the email newsletter, the YouTube channel and, like Steven suggested, you can hit him up on Twitter.

We also have a comments section, where I’ll forward any questions you guys have to Steven, and he’ll reply to you guys. Dude, it’s been a pleasure. Thanks for joining us.

Steven: Thank you.