015: Design Systems Engineering w/ James Stone

James Stone is an award-winning web designer and a top contributor to ZURB Foundation.

I was able to land an interview with James to get his insights for streamlining complex development across teams with diverse personalities and skills.

[podlove-subscribe-button button=”podcast-itunes”]

James Shares With Us

• How the technology has changed over the last 15 years
• New challenges for teams that face increasingly complex systems
• How to address the communication challenge across different groups
• Should project managers learn to code?
• His take on augmenting a team’s weakness

Connect with James Stone

James Stone is an award-winning web designer and a top contributor to ZURB Foundation. He has written for UX Pin and ZURB University and is an Adjunct Professor of Art at Penn State’s School of Visual Art. He has presented at TEDxPSU, Harvard University Extension School, and the HTML5 Dev Conference.

Free Course: http://www.DesignSystemsCrashCourse.com
Website: http://www.JamesStone.com
Twitter: https://twitter.com/JamesStoneCO
LinkedIn: https://www.linkedin.com/in/jamesstoneco
YouTube: https://www.youtube.com/user/JamesManOfStone

 

Transcript

Hau Ngo :	Hi, and welcome back to the show. Today we have an incredible guest who will walk us through his process for streamlining development for his clients. James Stone is an award-winning web designer and a top contributor to the ZURB Foundation. He has written for UXPin and ZURB University and is an adjunct professor of art at Penn State’s School of Visual Art. He has presented at TEDxPSU, Harvard University Extension School and the HTML5 Dev Conference.
	Hey James, welcome to the show.
James Stone:	Hi Hau. Thanks for having me.
Hau Ngo :	So James, FYI, I used to do a bit of web development maybe 15, 20 years ago. Back then I remember the transition from writing your code in Notepad to the new thing, which is Dreamweaver. How are web projects different now than say 15 years ago?
James Stone:	Yeah, that’s a great question Hau. What kind of web pages were you creating back then in Dreamweaver and Notepad?
Hau Ngo :	Initially it was just plain one page HTML pages. At that time I was working for the California Research Bureau maintaining their website in Sacramento. I think the technology we were trying to incorporate was ColdFusion, which is the new way of incorporating dynamic content into HTML. That was just leading edge at that time. But even then I thought that was pretty complex. I can’t imagine what it’s like 15 years since then.
James Stone:	Yeah, totally. It’s interesting because I worked in the web a long time ago too. I started a start-up and we were doing Java stuff, and it was just a completely different beast what the early World Wide Web is to even today. Even though it’s still kind of just the page with information that links to different pages, now you have entire applications being built on the web. I think, even from just a few years ago things are really radically different, but from the early web it’s just an even bigger transition. I think the big way I like to think of that is things that used to take myself and teams of engineers weeks to do, can be done in the day, maybe half a day by a single engineer. There’s a lot of tools and processes that make this possible; MVC frameworks, VSAR frameworks also on the front-end and it just really simplifies a process. You have a lot of structure. You don’t have to spend so much time reinventing the wheel for every single project.
	I think that’s one of the major differences is there’s a lot more efficiency, but the downside is that it’s incredibly complex. I focus on the front-end of web development, so not doing too much of the server stuff, but everything that’s rendering on the browser. Even there, the ecosystem has gotten so complex even in the past years. Now, often you can get a lot more efficiency from that, but it means that you’re touching a lot more tools. Maybe back in the day you just had Dreamweaver and you would use that for most of what you were doing; now you have Gulp and Grunt and Command-line tools and automation. All these things are loading in the browser real-time. It’s just a lot more complex under the hood.
	I think the other thing that’s a really big difference today is that there’s a much higher emphasis on visual design, and I think for organizations there’s a lot more value to be gained in visual design. Of course, a great example of this is Apple Computer. Look how much emphasis they put on visual design for their website, all their products. I think everyone’s trying to emulate that. Where maybe five, 10 years ago it wasn’t so important the visual design of your website, and the user experience of your website, today it’s really critical. I think when you see a site that’s five years old, you think it’s hacked or broken or somehow accidentally still on the web. It doesn’t have a certain kind of look. There’s a higher bar for that kind of visual emphasis.
	I think the other thing that’s really interesting too that we didn’t have back then is a variety of different types of devices. We had pretty much everyone on the web was on a computer with a pretty standard size screen, but now you have massive screens, you have televisions, you have mobile phones, tablets, even have wearable devices, like the Apple watch. So you have to design so that you can use your application or website across a variety of different devices, and that typically on the web is mobile responsive design.
	Probably the final thing I would think about is just the projects are much more complex. I think that’s because when I first mentioned you can have a lot more progress with a single engineer as opposed to back in the day having to build everything and reinvent the wheel, the downside of that is now the applications are so much more complex and so much larger than they used to be that you’re back to spending two weeks with a roomful of engineers to accomplish much more, you just have a much higher expectation of what you have to accomplish.
Hau Ngo :	Yeah I think you hit the nail on the head right there, because I remember when I first started out in college there was only two browsers I had to worry about. Back then it was Netscape and Internet Explorer. Even then writing one bit of code renders differently in either browser. Also back then every single website looked a little bit different. I’m talking about all those miscellaneous GeoCities domain that you see, and bunch of banners and pictures everywhere of flying rainbow cats or whatever, but now it sounds like everything in terms of design hasn’t been exactly standardized but is definitely scrutinized. There’s so many UI experiments being ran on each type of minute change that I think you’re right, the bar has been raised, where instead of saying it’ll take one guy weeks and weeks and weeks to build something, a teenager or maybe a middle school student can just install WordPress by himself with the push of a button.
	The fact that kids are now being able to set the own domains, their own websites, their own web presence, those in the professional space have a much higher bar. Especially, I would say, the commercial space to say, “Here’s a quality product.” It’s no longer, at least from my opinion, that it’s just one or two or three guys building a website. It’s something you have to communicate and coordinate with multiple teams. You have your web developer, I’m guessing the UI person, the front-end marketing business. So how do we get all of these different groups to work together, and how can we avoid that team miscommunication on these web projects?
James Stone:	Yeah, that a great question Hau. Obviously the projects are getting much larger in complexity and then you’ve also got a lot of specialization. I think back in the day you didn’t have this kind of specialization on the web; back-end, front-end, UI designers, UI developers, UX developers and so on and so forth. Really what you’re looking at now is multiple teams within a web project working together. You’re asking how can you have this clear communication. Typically on web projects you have some sort product manager, project manager leading the team, and you’re going to often have a design team and an engineering team working together.
	Now design can mean user experience, it might mean more UI, more visual design, but because there’s such a high design emphasis what you’re finding now is rather than purely marketing teams working with developers directly, you’re actually having a mix. It might be a marketing team PM, the design team and the engineering team. Now, a lot of the miscommunication I think happens because there are just very different people that fall into those roles. Someone who’s in marketing, versus someone who’s in engineering, versus someone who’s in design, they are very different people. They went to school and probably studied this for quite some time, and had a lot of emphasis in their particular area.
	I think what happens is that when you bring all these people together they have a different set of cultures, a different set of ideas, sometimes a different way of talking about things, and overall they might even have just a different agenda about what they’re seeing a successful project be. Everyone want to have a successful project, but if you ask those three or four groups of people, “What is success in this project look like to you,” I think it’s likely you’re going to get radically different answers.
Hau Ngo :	Got you. Yeah, I think that’s true with a lot of the projects I’ve been on also. I would say on a lot of the legacy projects I worked on, I say legacy in the sense that it’s not this leading-edge SAP products but more of the bread-and-butter SAP ECC business warehouse, where you had a project manager who is focused on making sure the project is completed on time, under budget. You have your analytics architect like me who wants to make sure that we may have to burn budget, we may have to work longer hours, but we want to deliver a quality product for the business, so my goal is different. Of course, you have the business who says unless this report runs and shows him the metric that he’s looking for and is usable; it doesn’t work no matter how well the report is designed or however we finish a project. So that’s true.
	When you’re talking with different groups of people with different agendas or different definitions of success, how do you get them all on the same page? For example, should a project manager learn how to do data modeling? Should designers learn how to code? Should the coders learn how to design? How do you get everyone on the same page and smooth out the miscommunication bumps?
James Stone:	Yeah, it’s a great thing to bring up. I always think in terms of like a design team or designers, sometimes they really care about the visual nature or the aesthetics, and a user experience person might care more about having empathy for the user and having the experience be really fantastic, but then you go over to the side of the engineers and they’re going to care more about code quality and maintainability of the project. These things are sometimes in opposition to each other. Now, I think that that’s not like the end of the road, sorry, everyone doesn’t get along, but I think what you need is something to bridge the gap. What I think helps to do that is to have a set of clear documentation and processes that bring these teams together on some common ground so that they’re still feeling like they’re accomplishing their agenda or their goals as a team, but then there’s more continuity in what the team is achieving overall.
Hau Ngo :	Got that.
James Stone:	Yeah, no problem. I know you said should engineers start designing or should designers code. I think you’re saying the product manager, right?
Hau Ngo :	Yeah.
James Stone:	Should the project manager learn to code? I don’t know. Sometimes it seems like every day I look online and there’s somebody telling somebody else to learn to code. It’s interesting for me because I actually teach at Penn State in the School of Visual Arts; I actually teach a beginning coding class for designers and artists who have no experience coding whatsoever. It’s a very challenging subject to teach. I’m not saying that people shouldn’t learn to code because I think it’s a really valuable skill to have in today’s world, and I think it’s very good for a deeper understanding of computation or how computers are working, but I don’t think that a product manager going to like a coding boot camp so they can better understand the engineers, I don’t think that that really solves a problem. I think the problem is really being able to communicate ideas clearly and efficiently, and have this common language and common way that you can flow through your process. It’s not about really the product manager becoming an engineer.
	I think probably the important thing to think about is when you have a team of people and when you have specialization, you don’t want to start de-specializing everyone. You really want to play to people’s strong suits. For example, if you have your team of engineers, and you’re like we’re going to teach all of our engineers design, and you sent them to some boot camp or class for a few days. What are you going to do then? What are they going to be designing? Because you’re putting them up against designers who have spent probably most of their working lives, if not their educational life, focused in design and aesthetics, and they’re just not going to be able to compete. I think more importantly, it’s probably not what they want to do.
	I would imagine if I was an engineer and I went to school took computer science, got really good at my craft, I certainly wouldn’t want to learn something that’s in opposition of perhaps my personality, perhaps my interests. If I had an interest for it, sure. But I think what’s happening is people are pushing this on employees, they’re pushing it on teams, and they’re trying to solve this problem of efficiency and miscommunication because people are not understanding fundamentally how to communicate with each other.
	Now, in the case of visual design and web projects, there is this kind of intermediary space where you can kind of smooth the communications. That’s kind of a space I’m interested in in where I work. It’s really about solving those problems outside of the realm of engineering and basically taking ideas from design and trying to keep the design intent strong, but also provide a quality tool set that engineering can expand upon.
Hau Ngo :	I think that’s the most valuable thing I’ve seen on projects to be honest, because I see clients make this mistake over and over where they would hire for the skill set and they assume that anyone with that skill set is interchangeable. It’s really a commodity in their mind. They almost always pick the lowest price commodity. You get into these situations where the engineer has one way of looking at it and the business has one way of explaining the problem, and there’s that gap, and they just cannot reach each other over that gap. Fortunately, I have my foot in both spaces where can I help coordinate the business requirements and delivery to the engineer to the programmer. But I’ve seen usually after a failed project that you this could’ve been avoided had they had that either set of processes or templates in place, or have someone like you who can actually bridge that gap for them.
	I would a second point you brought up, which is really, really true, is that coding is not easy. I remember my first coding class in college. It was my first year, first quarter, and I was pretty much crying the entire quarter because this stuff does not make sense. I wasn’t interested for the first, I would say, year and a half until I took that web development position in Sacramento, when I had to solve these real world problems. The course I happen to have been taking was about efficient programming, and it just solves so many things that I could apply to my afterschool job that I immediately became more interested in trying to figure out what else I can do with programming. But I would say you’re right it’s not for everybody and it’s a very steep learning curve.
	James, I think we’re about to hit the 20 minute mark. We can probably go for another 20 minutes, but I don’t want to take up it too much your time. I think what you’ve touched upon in terms of having a very strong set of guidelines, or what I consider guideposts for the entire team and making sure everyone’s on the same page at the beginning of the project is crucial. For the listeners, if they want to learn more about you and design system engineering where can they find you?
James Stone:	The best thing for them to do is to go to designsystemscrashcourse.com, and they can sign up for a free email course and learn a little bit more about the benefits, and what I call design systems engineering which is kind of this intermediary space in which occupies design and engineering, and how you might start with that in your organization to try and realize some better communication and some efficiencies. If they do that they’ll get a three day email course, but more importantly they’ll be on my list. I use my list a little differently. I use it more like a laboratory. Here they’re going to learn a little bit more about me, what I’m all about, and how I operate. This is really the best way. All they need to do is go and give their email address and we can start a longer relationship, and then later if you decide I’m not worth paying attention to you can just unsubscribe. That’s what I encourage people to do. Go to designsystemscrashcourse.com, sign up for that free email course.
Hau Ngo :	Okay, awesome. Thanks James for joining the show, and thank you again for your time.
James Stone:	Thanks Hau. It’s great to be here. Great talking to you today.
Speaker 1:	Thanks for listening to the Experts and Influencers podcast. Learn how problems are solved at the biggest companies and apply to your project at expertsandinfluencers.com.