Drew Covi: @drewcovi | about.me
Show Notes:
- 01:04 - Honeywell User Experience (HUE)
- 05:00 - Deliverables
- 06:55 - Being a “Devsigner”
- 17:26 - Flash and Leading to Unique Skills
- 30:00 - Advice for People Straddling Roles
- 35:27 - Leveraging Design and Development Skills Together
- 39:41 - Embracing the Hardware Element
- 42:05 - Why the “Devsigner”?
Resources:
Transcript:
CHARLES: Hello, everybody and welcome to The Frontside Podcast, Episode #76. My name is Charles Lowell. I'm a developer here at The Frontside and your podcast host-in-training. With me is Elrick Ryan, also a developer at The Frontside. Hello.
ELRICK: Hey, what's going on?
CHARLES: Not much. Are you excited about today's topic?
ELRICK: Very excited.
CHARLES: Yeah. You got a personal stake in it because today, we have in the room, not only you but also two developers who are also designers or designers who are also developers. Our guest today is actually the first person who fit this description that I ever worked with. It was a great experience, a great collaboration and his name is Drew Covi. Drew is a senior supervisor of product design at HUE Studios in Golden Valley, Minnesota.
DREW: Howdy. How are you doing?
CHARLES: Good. Thanks for joining us. Now, you're going to have to explain to us two things, one, what is a super senior product designer and let's start off talking about HUE first. What exactly is HUE because I think it's a cool organization?
DREW: I'm working with four people and I'm working on all sorts of brand new ideas. I think the greatest opportunity that I've had in my career at this company, Honeywell is just working with physical product and the digital space. It's a unique opportunity. Not all companies focus on both so it's really been a learning experience for me and working with a great group of creative individuals is also been a real privilege. They say that at the end of the day, the most important thing is other people that you work with and really the entire team here has been fantastic in welcoming me and letting me explore and grow as a developer and as a designer. It's been great so far.
CHARLES: Fantastic. Working with that group was absolutely wonderful. What does HUE stand for?
DREW: HUE is Honeywell User Experience. Our previous CEO, Dave Cote often called it 'huey' but it's just HUE, without the Jersey accent. I'm going to probably misrepresent but we have over eight to 10 studios throughout the world. Each one focuses on different businesses for the most part. The one here in Golden Valley tends to focus on homes and buildings technologies. The studio out of Seattle, actually tends to focus on, again I'm going to get the acronym wrong here but it's essentially worker safety in industrial safety.
CHARLES: What is it that you all do at HUE?
DREW: What we do here at the studio here in Golden Valley is we support various businesses throughout the homes and buildings technology space. About fall of last year, Honeywell went through a bit of a shift in their business and they used to do all automation control solutions. Last fall essentially, we saw that one large business that was headquartered and based out of Golden Valley, break into two areas of more direct focus.
Out of Seattle, we have folks working on, I think I mentioned before but Seattle works on sensing and productivity solutions. We focus on homes and building space so we're both providing upfront research to understand what the customer needs. We're actually creating everything from very rough user flows to final UIs and we're also working with industrial designers to create final products. Those industrial designers work very closely with engineering.
Honeywell has a long reputation of very strong engineering when it comes to the hardware space. We've prided ourselves on excellent instruments and excellent performance. One thing that very few people understand is that we don't just do thermostats. We're in the business of turbos. We're creating the turbos for your car. We're creating all sorts of HVAC equipment. We're also handling various safety equipment. All of these items need designing, not just for end users and consumers but they also need designing for the workers in the field.
If we make a product that is more efficient, easier to use and in some cases, more attractive, not only it does lead to more sales, it leads to more efficient work forces that can work quicker essentially. You could get up on a roof and get off in record time. We're not just designing consumer products. We're actually focused on a lot of other items as well, with oftentimes very large returns on investment.
CHARLES: In the work that you do and HUE does in general, it sounds like there might be a large software component. Digital design is kind of we know in the web space but then also a lot of industrial design of just how does this thing going to look, how is it going to feel, how is it going to persist, how durable is it going to be, how is it going to withstand usage. Would you get involved in that process?
DREW: Usually, the entire organization gets involved with the process very early on. One of the other shifts that happen in the fall as we get involved less in the production and more on the actual marketing side, like marketing deciding what's going to be built. We're actually really at the beginning and understanding what problems need to be solved at first. As far as my practice and my skill set, we do get involved with all that discovery phase work but when it comes to actual deliverables, we oftentimes see our deliverables around the actual creation of understanding user interactions.
We will take research from our user research in OVOC, which is an acronym for Observational Voice of the Customer and we'll take those learnings and translate them into whatever solution we decide to build as a team. My output is going to look like a user flow, something you build in OmniGraffle or Visio and then it can start there, which is in the physical space and then we'll actually revolve those concepts into wireframes as well. Wireframes that will then be handed off to other team members who specialize and focus on visual design. Basically, it's kind of a very hands on process from the very beginning to the very end. It's essentially just understanding everything from the physical to the digital.
CHARLES: When we were working together, at least in your case, it doesn't stop there. You're actually doing a significant amount of the implementation as well. Let’s explore how did you actually end up getting to that position where you were working through interactions, wireframes and workflows and then also, getting to actually build the product in the form of a complex single-page application.
DREW: Sure. Absolutely. One of the components that I kind of brought here to the team was a bit of a deeper understanding of frontend web development. I'm often pulled into conversations here and there. In the case of the project that we were working on specifically, it was essentially kind of early days on that project. We had a product that was pretty old and need a lot of work and it was basically, need to be rebuilt. We hadn't seen a lot of single-page applications at that time. In my case, I actually had worked on a couple small projects in my previous job and we can get into that in a little bit, where my career path took me.
But essentially, it was me trying to kind of pave the way and eventually have that work scale. It was kind of proving that it could be done, showing how it could be done and then getting other developers on board. My role here has oftentimes involved, basically becoming a liaison between our design teams and our development teams. Ultimately in this case like you mentioned, it did wind up in turning into code that ultimately got factored into production code.
It was definitely a time where we were experimenting with what role we would play. I will say in full disclosure that more or less which we're trying to move towards, basically making better informed decisions but not playing as much of a role in actual production code writing. It's something that we want to help scale. I think we'll talk about that kind of role and how well it scales hopefully in a little bit here but ultimately, it kind of changed a little bit. I don't do as much code as I used to.
CHARLES: Right but nevertheless, the skill is there. Don't sell yourself short. You weren't slapping together a bunch of jQuery plugins. You were standing up, basically a full stack system with a StubDeck background, then Node.JS. This is back in early days where there was a custom-build tooling. You were using CoffeeScript. There was a lot of exploration and clearly, there is a fierce curiosity which you are actually exploring and actively kind of skinning and moving into the development space, which doesn't happen until people achieve a certain level of comfort.
Whether or not you're exercising those skills, I think they have served you well in terms of the things that you've been able to build but also acting in that liaison and understanding what's possible and stuff like that. Obviously, once I met you, you were already there. I'm curious in exploring that journey of coming up the design ladder but also coming up the development ladder too. Maybe we can talk about each one separately and then see how they intertwine. Let’s start with the design side. How did you get into that?
DREW: I can take you way, way back. I love to talk more about this in a little bit but I think we, as a generation, are kind of very unique in that. We were raised in the birth of the internet. Some of us are old enough to remember the early dial up days and I certainly was one of those. I grew up basically obsessed with drawing and art and painting. I was a designer and artist raised by an engineer, essentially. My dad didn't really have a lot of opportunities to explore his creative side to basically make a living. I want to say that although graphic design existed to a certain extent, there wasn't really the same blend of engineering skills required so he decided to take the tack of I'm going to become an engineer so I was raised in a household where he was building everything but he was also a talented artist.
As a kid, I basically did a lot of advanced art classes. I'm kind of a nerd, pretty much a huge nerd. I dropped my entire tenure as a high school student. It was also kind of dawn of video games as well so we had computers coming of age. We had video games coming of age so I was raised looking at digital art effectively, 8-bit, super accessible. It's kind of so early on that it was something that I could actually fathom getting into and creating on my own. I never got to creating any games but I will say that by my late high school years, I was using a tool called AOLpress. For anybody who has ever heard of that, congratulations. You're one of the few.
CHARLES: I've never heard of that. AOLpress, we're going to have to link to that in the show notes.
ELRICK: I've never heard of that either.
DREW: It's awesome. It's got a Wikipedia page. It's got hieroglyphs and stuff. They really went all out on this product. It's basically the precursor to the Dreamweaver. It was a very, very WYSIWYG. I'm sure you've heard of Microsoft FrontPage, maybe. It was basically a precursor to FrontPage, I would say. Same thing, those are the days of framesets and all of that. I was a kid in scouting at the time and I wanted to build a web page for the troops so I built one and put it out there. I kind of remember that moment where I was like, "I'm going to write something and put it on the internet and anybody can see it." That whole experience was just super exciting.
I know that if anybody's following Kickstarter, there's one that was started called 'What Comes Next Is the Future.' It was made by Matt Braun and Matt Griffin and it really explored the birth of the web. I would recommend it on your listeners to want to really dive deep if you didn't live through it, check it out. It's a great, great film. All the regulars are there as you'd expect. Zeldman on there, talking about it amongst others.
But if it were for the web, I don't know that I would be who I am or where I am today, just because it's such a unique platform. It's so open. It's so readily available. There's no barriers. I would say that I was just an arts student in high school that picked up AOLpress and then got addicted to the web. From there, it was kind of off to the races. In fact, I didn't even know that I could make a living as a graphic designer until late high school. I decided that I wanted to go to school for graphic design, went a year at the University of Minnesota-Twin Cities and at that point in time, it was pretty much all print design and then Flash. Flash took over in my second year and at that point in time, it was Flash and framesets and tables. There was no CSS for layout. It's very early days. It sounds like you might know what I'm talking about. Have you been there?
ELRICK: Yeah. You know, they say everyone in the world has like a twin and I'm like, "Drew is like my technology twin."
DREW: Yeah. When we were raised in that time and we had to hack it with framesets and whatever tool -- FrontPage or AOLpress -- you basically, from very early days, realized that you had to force this stuff to happen. It was not easy. There was no documentation and where there was documentation, you were grateful to have it. I remember when I was, probably just about to graduate and if I look back at my portfolio piece, it was definitely still Flash. It was Timeline-based Flash. I also think that in many ways the way the web evolved was perfect.
As a designer, I was very comfortable in the Timeline tool. Before ActionScript 3.0 and before they went on object-oriented on us, it was super accessible. You could add little bits of code here and there and create animations. It kind of got you hooked. Then suddenly, I found myself needing to create full screen Flash applications and needing to actually write code. I actually having to say, "If I want this Flash experience to scale, then I need to calculate where things go. I can't just X-Y coordinate and done," so that's where I jumped off and started getting into CSS.
CSS was kind of early days as well. Again, this is before iPhone. This is like people were using CSS but people didn't really think it was that important. It was actually kind of discouraged because everybody in the world was using Internet Explorer and why would you need to know CSS. It was unreliable for different browsers and Internet Explorer was the worst.
I remember sitting in a Dreamweaver conference, when it was Macromedia had a conference and they showed a webpage and then they hit the print button and they said, "Does anybody here know how this happened?" because the layout had changed, everything looked better and different. It was perfect for print. I remember my hand shot up because they was like, "Nobody was really familiar yet with that print style sheets?" Incidentally, I don't think that people still are familiar with print style sheets but it was a time when finally people were starting to understand that style sheets were more than just a layout tool. You could change them for all these different form, factors and all these different platforms. It was a fun time to be coming up in this age.
CHARLES: It sounds like one, CSS and two, Flash were actually kind of gateway drugs into the development world?
DREW: Absolutely.
CHARLES: We still have CSS, clearly but do you feel like Flash, despite what some people might think about it, it was a full virtual machine that was running. You could code on it with ActionScript. It's kind of like the JVM but only for running inside the browser. Do you feel like designers might not have that gateway available to them anymore or maybe is the web just as big of a gateway to move into that?
DREW: Yeah, for sure. I certainly think, beyond a doubt that had it not been for Flash, we would see a lot less creativity in the space. I say that only because at the time, if we had just gone from tables and tried to slowly evolve things, we'd have a much different feel, I believe. Certainly, it's a gateway drug. We'll be in a different web today without it. Is it still required? Are there any equivalents?
I've seen a number of drag and drop web UI on the web tools out there and many of them claim to create production quality code. It's certainly possible to get there without Flash. I think, it's certainly its time has passed but we do see tools like Sketch for instance. These are all very much screen-based design tools that seem to leverage a lot of the same web styles and the web approaches. I think we definitely have the tools there to replace Flash. But I think from my perspective, it would be very interesting to go back and imagine, would we have immersive full screen web experiences without that Flash?
CHARLES: Yeah. I remember it being very much a topic of conversation, certainly at the beginning of each project or when you were going to implement a feature is, "Are we going to do this using Flash? Are we trying to do this with native HTML? Are we going to use EGADS or Java applet?"
ELRICK: Oh, man. Java applets.
CHARLES: That was a conversation that was had before the web eventually went out but I think when it was, everything was very, very static. I do think that Flash definitely set the expectation higher and forced the web to evolve so that it could be the natural choice in those conversations.
ELRICK: The time when Flash was around, I called it the 'golden age of user interface' because you can literally build any user experience, any user interface with Flash that you could dream up. There was no limitations creatively in the world of Flash. Nowadays, we're kind of limited without box model but it's getting better year-by-year.
DREW: It's interesting to me because before Flash really died out, we had these... Let's put it this way. I feel as though, for a long time the web was a very much like a poster site kind of approach. You would have tools that were pretty rough on the eyes, pretty hard to use and then like for certain films, you have these very high budget, fully immersive Flash experiences. For a blip, that did actually translate at some point into Canvas-based and then Three.JS, like 3D WebGL-based experiences in native HTML but I don't see a whole lot of that anymore.
It seems as though, it kind of settled down and in many ways, I would say killing Flash kind of evolved the web from more of a presentational platform to more of a usability first platform. It was a bit of a double-edged sword. You could build anything you want like you said but there wasn't a framework to it. It wasn't really responsive and then certainly, when Steve Jobs decided he wasn't going to Flash an iPhone, that was the end of it. Essentially now, we have --
ELRICK: Steve Job dropped the hammer.
CHARLES: That was the memo that was heard around the world, right?
DREW: Yeah.
CHARLES: I just realized that was like 10 years ago.
DREW: Yeah, they're celebrating the anniversary for the last couple of months here. It's been a huge deal.
CHARLES: There's probably listeners that never heard that memo but it's definitely worth a read. The memo obviously, that you guys are referring to is when Steve Jobs basically said that Flash would not be on iPhone or iPad, not now, not ever. That was the end of it.
DREW: People often forget too that when it was first launched, there was no app store. He basically said point blank, "Anything you need to do on this phone, you should be able to do using the web, using native web coding," and Safari at that point in time is really paving the way to bringing those native APIs into the web. You had geolocation through web. In many ways, that too is a huge gateway drug.
Suddenly, you start looking at the web, not as just like, "I could use this as a poster site or as an informational site or a new site. I can actually use this to get things done." They're actually treating this platform as a first-class citizen. That to me was super exciting. I don't know if it gets as much attention anymore in the days of Swift and the App Store but I will say that if your listeners do get a chance to check out the show I mentioned earlier, 'What Comes Next Is the Future,' they even dive deep into just how limiting the app store experience can be. At least with the web, you can create whatever you want to create and people seemed to go that you URL and install on their home screen. This is a feature that nobody uses from what I've seen but if you bookmark a web app on your home screen, you can have an icon, you can have a loading screen, you can have all this stuff and nobody really uses it for whatever reason.
CHARLES: I think it's the install, it's getting the knowledge about the fact that you can do that. It's not widely disseminated.
ELRICK: Yeah, I think its capabilities starting to come up now with people making progressive web apps. They're starting to utilize that being able to put icons on people screens and loading screen and splash and etcetera.
CHARLES: Flash really was kind of the gateway into the development world. I'm curious what opportunities do you feel opened up as you started taking on more web technologies, more JavaScript, more CSS and mixing that with the design that you were doing? What unique skills/superpowers do you think that gave you, that made you, that helped you at that stage in your career?
DREW: Yeah, for better or worse, it really was the opportunity to get a job first of all. I know that the job market has been in all sorts of flux in the last couple of decades but I would say 12 years ago, in 2005 when I was entering the workforce, graphic design was not necessarily a hot field. I can say with relative certainty that the majority of the people I graduate with, didn't necessarily make their way into graphic design as a profession. I would say probably maybe 30% to 40% actually wound up following their degrees.
For the obvious reason at that time, we were starting to see digital replace print. It meant that I was able to get a job for one. It wasn't a dream job necessarily but I was basically a one-stop-shop. I was designing and developing websites as working for a company but in many ways, shapes and forms, I was kind of freelancing as things were. I had a very direct relationship with the clients that I worked with. It was basically churning out websites.
If I recall correctly at the time the company wanted to essentially create a Domino's Pizza of the web where we could use CSS to essentially build the actual HTML once and then restyle it. This is actually was a time when a site called CSS Beauty was just coming of age, I think the site still exists but back then, if you want the CSS Beauty, it's big thing was you have one website and people could upload their own CSS and completely change the layout, completely change the look.
CHARLES: Are you talking about CSS Zen Garden?
DREW: Maybe that was it. There's two of them.
CHARLES: I remember that one.
DREW: CSS Zen Garden was one of them and I think CSS beauty was a clone maybe of Zen Garden for sure. Maybe you're right, Zen Garden was the one where you actually had a website and Beauty was just showcasing certain CSS sites. I think you're right. Zen Garden was the one. When they saw that, they're like, "Wow, business opportunity. We can build a whole site." We were using something called 'Cold Fusion' and... Oh, it will escape me now. I think it was called 'Contribute.'
There's a product called 'Contribute' that Macromedia come up with that worked on Cold Fusion. It was basically a WordPress. You basically set up editable regions, you basically code the site once in that regard in the backend coding and then just rework CSS to create multiple sites. Actually, the opportunity to open up for me, that job was very squarely-focused around the benefits of leveraging CSS. Eventually, that grew tiring.
I kind of wanted to get into the actual marketing and advertising space. From there, I started to just jump to the next job. I worked for a very, very small marketing agency. It was called 'Vetta-Zelo' at that time and we focused on lots more Flash, a little bit of CSS websites but mostly Flash Experiences and they actually used Flash in a lot of kiosks and physical spaces.
I started to jump into that, understanding PHP, understanding databases because we would do things like we would install Flash Experience on little portable tablets that would then sync up survey responses to a web URL that it would then dump it into a database. About that time, I was always trying to teach myself how to get really deep into the backend of the stack.
CHARLES: That was just to make sure that these Flash sites that you're developing would be scalable and more robust? Was that the natural next layer to dig down?
DREW: Absolutely. At the end of the day, we wanted to have immersive Flash experiences and we wanted to have the content easy to update. I would build these really crude backend with text areas and they would update a database and then the Flash Experience would pull that in as content. In that way, we didn't have to go in and re-publish the Flash every time, essentially. It was a much more streamlined process.
I think we even gave some of our clients the keys, gave them a login and password and they could change certain things. There's an outfit around here called 'Crave.' They are a restaurant in town and we built the website for them -- one of the earlier websites. When you have to do things like update times and menus and things like that, it became pretty essential to having some sort of a CMS behind it. It was all based on necessity, in other words. What you said is absolutely true. We had to evolve what we learned and I had to push what I did to lever on different needs.
Throughout my career, I've been the guy who does web and design. One of the things about that is it's kind of a lonely place to be and find yourself in creative agencies, where the majority of skill sets are not in development and trying to explain what's going on or make commitments on timelines and deliver on them. Whenever a bug shows up, it's never really fully understood. It's also a challenge to manage expectations, certainly as a young professional at that point.
CHARLES: Yeah, I would say, what would be some advice you would give to somebody who is straddling these roles at that early career stage where they're maybe working for creative agency and fulfilling these two roles but most of their surroundings is towards the design end.
DREW: Yeah, I would say for the most part, just be upfront. If there's anything that's unknown, be upfront about it and explain. If you are early in your development career as a designer, do your homework before you committing any commitment certainly. I think it's always better to be upfront about these things than to try to over-promise and then scramble at the end. I will say that a lot of my career has been marked with the term code 'code cowboy' as a designer and teaching myself to code. It was a disparaging term, I guess. I didn't really necessarily take it that way but I think other developers are trying to use it in that way.
CHARLES: [Singing to the tune of Mammas Don't Let Your Babies Grow Up to Be Cowboys] Cowboys ain't easy to love and they're harder to hold...
ELRICK: It's so true.
DREW: You know, I'm not even embarrassed to say it because the truth of the matter is when you're a designer, you're used to just making a mess before you kind of landed on what you're done and what's right. The entire creative process is messy. I think it's inherent. If you're one of these designers turned devs and you basically just hack it until it comes together, that's kind of a natural flow from the creative process. Certainly, as you get more experienced, you want to reduce all that uncertainty and potential for error so you do learn to hone your craft, to use version control, to embrace a framework or embrace some model-view controller approach but none of that really existed in the early days of the web. I kind of came up in a time when you had to hack it.
CHARLES: Well, there's a lot of learning that can happen when you're hacking and building things that are kind of ad hoc. As you go, you get to perceive firsthand the problems with them. Without perceiving those problems first, it's hard to really understand the solutions that the internet has come up with to deal with those complexities.
DREW: I would say I was like a solo designer developer throughout the early years, because at 2010, I found my people in a local agency called 'Clockwork' and for the first time, I wasn't the only developer on staff. There was a whole team of developers. In fact, the shop was started as a development shop and they were making headway into the creative space and eventually, becoming full digital partners. But had it not been for my opportunities at Clockwork, I wouldn't have picked up my skill set as a backend coder. From the very beginning at Clockwork, they expected you to get your hands dirty and code and get your hands dirty in the terminal, honestly. Command line was required even in our design work.
CHARLES: And this is all designers needed to be familiar with the terminal tools --?
DREW: Correct.
CHARLES: -- Basic coding?
DREW: Yeah. Essentially, all of our work, whether it was creative or whether it was documents, were all managed in Subversion. As a part of onboarding, you basically learned how to use Subversion. There were some GUI tools for it but for the most part, it wasn't that steep of a learning curve. It was pretty easy to follow instructions and that was the second gateway drug, I would say.
My first gateway drug, again was kind of coming up in the age of the web and getting into CSS and Flash. The second gateway drug was basically being required to learn command line and learning how to navigate a computer without a display. Had not been for that, I don't think my career would have taken the turns that it did. I basically got more into the IoT space. I had set up a home NAS server with Drobo FS, is what it was called at the time and it was just a really basic machine but by jumping into that, I could start to play around with UNIX and tools there. I started using home automation, playing with that and at some point in time, I made the jump from just web into the role that I play here at Honeywell, which is Internet of Things.
We do a lot of Internet of Things. In fact, our latest tagline is 'the Power of Connected' so we've embraced it all the way down to our wood mark. It’s becoming the new normal for most products so it's a good time to be at the center of all these different areas of expertise, to be in development, to be in IoT and to be in design. That’s my path. That’s my journey. I would kind of pick it up at a bunch of fortunate circumstances, honestly.
ELRICK: Having these two skill sets: your design skills and your development skills, what do you believe that that gives you in terms of an advantage? Having these two skills set and being able to leverage these two?
DREW: From my perspective, having both skill sets allows me to understand. I think the biggest challenge when working with large teams, particularly in this space or in any space is to really have a common level of understanding, stepping aside from a functional role and becoming more of a liaison between design development and to be honest with you, as we look beyond that, I took a three or four or five month course in business administration, actually. It was just a night class but I wanted to be able to speak to those needs as well. I think it really is becoming a translator.
Serving as a translator between those items and then also being able to understand where the actual boundaries lie, there are a lot of very talented engineers and talented designers and sometimes opportunities are missed because, either timelines are pushing engineers to cut certain functionalities or certain features and there's a lot of pressure. Where we can lend a hand, where we can point to possible alternatives, I think that's where we really build cutting edge products. When we really know each domain, we can push those boundaries. That’s where I'd enjoy bringing my skill set to the table.
CHARLES: Yeah. I can second that. Having actually worked with you, I think one of the greatest things was the one just with the interactions that you were coming up with, were just really spot on. It wasn't ad hoc. It wasn't some --
ELRICK: Helter-skelter?
CHARLES: Yeah, it wasn't helter-skelter. It wasn't some developer coming up with like, "Hey, this is what this looks like," Or, "This is some designer putting up pie in the sky stuff." It was, "I understand what's possible and I'm going to use that to design the best thing that can be possible." It made the designs very pleasant and some of them were just really fun, I think. Thinking especially like that, the hierarchical tree selector was one --
ELRICK: Yeah, that was fun.
CHARLES: -- Which the implementation of that was just a joy. But then the second thing is being able to speak with you on the development challenges and really know that you understood that language. It really is being bilingual, I guess in the sense that I'm talking to you in French and you're talking to product owners in German or whatever. But because you're bilingual, the flow of information is as frictionless as possible.
DREW: I will say that it was a real pleasure from our end working with your team as well because one of the trends in many businesses throughout the world today is embracing a lean and agile approach to product design development. One of the growth opportunities, I would say in any business is fully understanding how that process works, having the courage to be upfront about what can be accomplished in the time available.
I think one of the other things is fully understanding those three pegs of the stool. There’s always the budget, the time and then the features of any projects. I think that working with a team that understands that really changes the dynamic. I will say that it was equally a pleasure for us to work with your team because there was just a level of courage in being very forthright and very upfront about what do we need to get the job done? What has to happen? You made my job as a translator, essentially.
CHARLES: We aim to please.
ELRICK: Absolutely.
DREW: Absolutely. The latest evolution of kind of where my career has taken us in the company is embracing the hardware element. We’ve talked a bit about the web and then how that evolved and then having to get comfortable of the command line and where that took place. I've always wanted to build. I've loved designing but I always want to build it and I want to put it out there. In the last six months actually, I finally decided that I would pull the Band-Aid off and jump into soldering hardware, writing what code I could and building actual physical hardware prototypes.
I think the next step for anybody who likes to follow this maker trajectory, for a creative looking to become a maker or a developer looking to get into creative is just not stopping. There's always something there and we're also fortunate to live in a time when I can go on at Adafruit, pick up a kit of parts for under $100 and build something that's completely new. Then by the way, they have a full-on tutorial that takes you through every step of the process and gives you bits of code to get started so what's your excuse at that point?
If you've got $100, then you can throw and toss into a hobby, pick up a soldering iron and go to town because there are videos, there's the documentation. Documentation is just everywhere now, where it was never there before. I think the next step for us is seeing how can we very early on show real physical world products to end users and get feedback. How we're taking design now is beyond the digital and into the physical.
CHARLES: That's fascinating. I feel like there's this pendulum that swings through the tech industry of things moving from hardware to software and back again. We’re in the middle of the swing towards the outside or towards the hardware again, like the distributed hardware versus the dumb terminals. It’s distributed across a bunch of devices rather than concentrated on one super-powered desktop computer. The pendulum is going to swing in it but it's just always fascinated to see what the actual arc that it takes is going to be.
This has been a fascinating conversation and the reason I wanted to have it and we were actually talking about this before the show started officially, why this topic of 'devsigner?' I think that it's a role that is emerging. I think it's still in the early days. I think that I went from three years ago having never really met this type of person to having met and worked with you. Now, I would say having met and worked with three people here at Frontside who fulfill that role and now knowing a couple professed devsigner or people who operate clearly in the design and the developer space on Twitter. I feel like it's this emerging career track that might not be fully understood or defined right now but clearly, there's something there so we wanted to explore that.
I'm curious if we might be able to open up the discussion a little bit on what is the future of this role? What tasks will it be set to accomplish? When you're assembling your team, you say, "Get me one of those because we're going to need that." How is that going to be further refined and designed so that it scales as, perhaps an official career in one, two, five, 10 or 20 years?
DREW: I can only speak to my experience in this area and I can say that for the most part, it is a very unique skill set and sometimes, it's hard to come but like you said, you're working now with three people. I think it's growing in prevalence. I believe that where coding was less common in the past, it's becoming so much more common now that it's almost like an expectation just like typing. It is an expectation now. People expect you know how to type. It’s not a surprise that we're going to see more and more of these individuals.
I would say that any design team out there could almost invariably benefit from having somebody with this skill set, somebody who can translate design concept into a working prototype. I've seen it manifest as a prototyping role, more or less just so that we can have a tangible deliverable for developers. I think it does depend on the team, certainly. If you have small teams with talented frontend developers, then certainly you can work in a lean and agile environment and make very quick iterative change.
If you have very large design teams and very large development teams, I would say that having a frontend developer with the skill set in a creative team allows that communication to happen without routine phone calls and lots of meetings, essentially. It’s a crystal clear example. I've see it manifest as a prototyping role because the expectation is this code will end up in production but some of the code may. The layout code may end up in production but the functional bits may not.
That’s not to say that the functionality isn't a part of the experience and that, designers don't care about how well an experience performs. But typically where many designers see the disconnect is in the presentation layer. Having somebody who can carry that over is usually something that is far smaller team can handle. Does that align with your experiences?
CHARLES: Yeah, that makes a lot of sense and I would say that the compliment from having this person on your development team, if you're in mainline development mode or maybe you are a small team, even if it's a production system but you don't have full time design resources, this person can slice and dice the features and understand the hierarchy of interactions and being able to put together some wireframe, some very concrete goals and set those goals for the rest of the development team. But yet also understand what goals are achievable in the iteration. I think it works from the flipside as well.
Maybe what we're seeing is the agile of the [inaudible] of everything. What we've seen over the past 15 years or 20 years, what has been the arc of my career is just seeing these feedback loops in every element of product development getting smaller and smaller and smaller. On the development side, we recognize this as being able to feedback loops and verification. Having your tests, you don't actually have to deploy your system to be able to get feedback about whether it works or have it be fully assembled to get feedback about whether it works.
But then that manifests in terms of continuous integration and deployment. You’re bringing down the feedback loop of getting this out in front of people versus these long deployment cycles that maybe you really have a release every year. It was hard to believe but that was the norm when I started. It was yearly, maybe even once every 18 months. It was not uncommon at all to have released cycles like that. Certainly, three months was very, very short but then those tight feedback loops can also manifest itself, internally in terms of team communication and I think having people who can make those feedback loops between the product and between the implementation, every time you shorten that feedback loop, you're unlocking an exponential amount of time.
DREW: Yeah, I think you kind of hit the nail on the head when you talk about setting scope and understanding things as well. Strictly speaking from agile terminology, having a product or a role that can bridge those gaps is critical. I think that the best product owners that I've worked with have understood, have had an appreciation for design but also have had some degree of a development backend as well so they know how to make those critical decisions. In any sort of iterative or agile environment, you have to dice up these features and figure out which ones are going to ship when they're going to ship. I think, yeah you hit it right out of the park with that. Whether or not you can ever have a full-on team of just prototypers, I'm not as convinced that that's necessarily scalable. It seems like there's certainly a role for teams of developer that will break down features and then there's teams of creative as well.
CHARLES: I think in terms of the person who would lead that team, this role definitely seems very well fit.
DREW: Exactly.
CHARLES: I think it's a great opportunity for someone who's looking for a leadership position in terms of developing and seeing products to market, which is kind of similar to what you're finding yourself in today or where you're headed towards, it sounds like.
DREW: Yeah, for the most part. It seems like I do find myself in a number of calls in kind of bridging those gaps. It’s certainly a different dynamic in the agile environment when work with hardware. That’s something that I think we're still exploring and still understanding. Certainly, there are companies that do agile with hardware but there's a whole slew of different challenges. You’re not just deploying anymore. You’re actually building manufacturing understanding what needs to ship with what. I think the next evolution of our company's growth into this space is how do iteratively produce hardware.
ELRICK: Interesting.
CHARLES: You got to keep me posted. The next time we have you on the podcast, you're going to have it all figured out, you're going to be presenting your thesis, it's a conference talk upcoming, agile hardware.
ELRICK: Yeah, that would be pretty interesting.
DREW: Yeah, I'll let you know.
CHARLES: In the first iteration, you just throw a bunch of boiling solder on the breadboard and see what works. "Okay, now, that didn't work."
DREW: I'll be honest with you. The 3D printing is making lots of possibilities open up in that space but ultimately, you got to ship. We use 3D printing and now we are using these low-cost computers to really prototype real world experiences and near-to-final industrial design. We can do that.
CHARLES: Drew, this sounds like you have the coolest job.
ELRICK: I know, it sounds awesome.
DREW: It become even more exciting than I had initially intended. It’s fun times. I think, again we're living in a time when we can 3D print stuff and have it done within a couple of hours. What better time to embrace these technologies and this creative spirit. It’s kind of all around us. Honestly, it's just being fortunate.
CHARLES: Yeah. Fantastic. This has been a great conversation. Thank you so much, Drew for coming on.
DREW: My pleasure. Thanks for having me, guys.
CHARLES: It's an amazing place. It sounds like even more fun since we got to work with you. If anybody is out there and they're in the design space and they think that, "Oh, maybe I can't do development," or it's too hard. It’s not. There’s a lot of people out there who are doing it and experiencing lots of good benefits. I would say that the other thing is if you're a developer, you should think about looking into the design space, something that you might be interested in. I think it's probably less common that the vectors people move from development into design and not vice versa but there's nothing that says that it can't go that way. Mostly, it's because people just aren't doing and they think that that option is not available to them but clearly, it is and clearly, it's a valuable role. I think this role is going to only get more valuable in the future.
DREW: I would second that thought and that notion. I give a quick shout out to Erin O'Neal. She's a former colleague of mine who's given a number of talks about that very topic -- backend developers caring about user experience, caring about the design. She’s given some talks. You could probably find her on YouTube. Anybody who wants to talk about it, I'm all over the web as DrewCovi. I think I pretty much have that user name in every platform so if you Google me, you'll find me.
CHARLES: We'll look for you. Obviously, you can find us at @TheFrontside on Twitter, TheFrontside on GitHub and feel free to drop us a line at Contact@Frontside.io. Thank you for listening everybody and we'll see you next week.
