Design for Developers

"Design for Developers" is a comprehensive guide that addresses common application design and usability issues with expertise and style. It equips developers with essential design and UX techniques, enabling them to adeptly create positive user experiences, smoothly iterate on front-end features, and foster effective collaboration with their designer counterparts. The book covers a range of crucial insights, including using color, typography, and layout to establish a clear visual hierarchy on web pages, ensuring consistent application of color palettes within user interfaces, making informed decisions about typefaces and fonts to elevate design quality, employing user research to validate design choices, and efficiently planning website layout and structure. 

Drawing from her role as a designer in the Microsoft Developer Experiences team, author Stephanie Stimac spoke to Sophie Freiermuth about fundamental design principles essential for contemporary web applications. Watch this GOTO Book Club episode to learn how to master the intricacies of polished visual design through manipulation of color, space, and typefaces, readers gain the ability to construct websites from the ground up, effectively translating theory into practice.

The story behind the book

Sophie Freiermuth: Hi, everyone. I'm Sophie Freiermuth. I'm here today to speak to Stephanie Stimac about her new book, "Design for Developers," that's coming out, and you get to hear a little bit of how Stephanie came up with her book, who she is, what she means to convey, and how she can help you. The book has already been out in pre-print, so I had a glimpse, and it's very good. But I want to hear it all from her. Hi, Stephanie. How are you doing today?

Stephanie Stimac: Hi, Sophie. I'm great. Thank you.

Sophie Freiermuth: Are you ready to tell us everything about the book?

Stephanie Stimac: Yes.

Sophie Freiermuth: We're gonna stick to the book today, and you, because there's a little bit of you as well. I know this book has been not too long in the making. I think you had the idea quite a while ago already. How long ago did you start to think about this book?

Stephanie Stimac: I think it was, let's see, it was in 2021, towards the end of the year, Manning Publications actually approached me about writing a book about design. It was something sort of in the back of my head, wanting to write a book. But I never seriously considered it until they approached me, and then they did. It's felt like a long time coming, to me, definitely.

Sophie Freiermuth: And now, 2022, 2023, and we know these have been difficult years, but they approached you because you have quite an experience talking about design to developers. I think your background is really important because it really explains why the book is a direct continuation of what you have been doing, and just bringing this message out, right?

Stephanie Stimac: Yes, it is. So, I started my career, like, I went to school for design. In my mind, I was always gonna be a graphic designer. I started my career out that way. And then in my second full-time job, I started doing web design, and I was the one responsible for UX, the visual design, and then I would even go on to do the front-end development bit of it. I was doing the whole process, and then, after four years at that agency, I was hired at Microsoft, and I was sort of doing the same thing, but I was on the web browser team, and I was working specifically with developers, and continuing that design. And I was actually building for developers. So, I was building developer tools, and really, really got deep into that space. And so, in working with developers, a lot of the feedback I would hear is, many of them want to know how to design, but they don't know where to start. They can go build a website, but they don't have those core fundamentals to make it look polished. That's really where this book focuses, is building up those skills.

What is design?

Sophie Freiermuth: Building up those skills for developers, to get to a polished look. And these words come up in the book, and they come even in the table of contents. Can I take a little step back? And when you talk about design, and you've already mentioned UX design and visual design, what is your definition of design, as a whole?

Stephanie Stimac: Oh, as a whole. Design is the visual communication of ideas.

Sophie Freiermuth: All kinds of ideas?

Stephanie Stimac: Yes. All kinds of ideas. 

Sophie Freiermuth: Where does the polish need to come in? Where do you see the design coming from, needing a polish? Where does it get to typically, and where did you see that gap starting to come in, for lack of, I guess, skills, first of all? Because I know your book focuses a lot on transmitting those skills. Is there even a lack of awareness, in that there is a polish possible?

Stephanie Stimac: Again, based on my conversations with people, people can see that something doesn't quite look right. Usually, a lot of that comes down to really basic things, like spacing, the size of fonts, like, not knowing, sort of, how to build a system to apply to a design. So, like, not knowing how to size your fonts, the space between things. A lot of problems can actually be solved just by focusing on spacing and sizing, and knowing how to apply that cohesively throughout the site, or your app. And just doing that can really make a world of difference in a design and how it looks.

Sophie Freiermuth: You have worked directly with developers, for developers, so I guess they got to see the design process much closer than they normally would. There are still so many products and projects where there is a handover between design and development. Where there are static deliverables, there is sometimes zero communication. In your experience, is that where the problem starts for developers needing that extra bit of help? Or does it run more deeply, that developers really need a basis of design to really excel at front-end development?

Recommended talk: DevUX: Improving Developer-Designer Collaboration • Yu Ling Cheng & France Wang • GOTO 2019

Stephanie Stimac: I think it depends first on sort of the team that you're in. If you have a design team and a development team, and that's the environment that you're in, I don't necessarily think it's required you have a basis, like, design skills knowledge. But I think it can be incredibly beneficial, just for the communication aspect between the development team and the design team. The sooner you get involved in the design process as a developer, you can help identify the points where things may not work from a technical standpoint. A lot of my book talks about trying to reduce that, like, the cycle of churn and doing unnecessary work, and speeding up the process with communication. But the other side of it is…on some teams that I've worked on, just being able to identify where something doesn't look right, in terms of spacing, or if things look too big in a user interface, being able to identify that, and then go fix that, and have a designer review it, instead of a designer going and basically building out a whole new mockup to fix that, is incredibly beneficial.

Because that's not the best use of a designer's time, trying to fine-tune those spacing issues or font size issues. They can focus on some of the bigger UX problems and usability. One of the key messages in the book is about just getting those base design skills so that you can communicate well with your designer, and help your design team be more effective, and focus on bigger problems than something small like spacing or font size.

Smart design for devs, by devs

Sophie Freiermuth: And this is where both your experience coming out of design school and having worked at the edge of design into development seems to really kick in. So, to take it back, communicate clearly with your designers. I know there has been a lot of work in the design community to go and learn about development. Designers are encouraged to code, and designers are encouraged to go and learn about development approaches and techniques, such as, for example, Agile. And this is where you're turning that picture around, and saying, "Developers, get better and do better work and bring more value and avoid waste," which is not an Agile, but it's a lean concept. They avoid waste by getting those basic design skills and being able to come in and support the design team. There's a very cohesive and collaborative approach that you are communicating, isn't there?

Stephanie Stimac: Yes. So, like, in so many of my roles, have been, like, I've been working on products, for developers, with developers, and working with... I've been the designer and I've also been a product manager, working with the design team, trying to direct the design and development team together. And just, like, clear communication is always so key, and especially when you're working in a fast-paced environment, like a startup, being able to move quickly, and not have to wait on a designer to do something for you, is so, so critical. Going back to the "should designers code" thing, just started talking about a tweet recently on Twitter about this, and it came up again. The point with, designers learning to code, or developers learning design, isn't that you're gonna be an expert at either of those things. As your design counterpart, I'm not expecting you to be a top-tier designer at all. But, knowing the concepts, and again, coming back to communication and collaboration, knowing those concepts will help us work better together. That's really, really, I think the core message of the book.

Sophie Freiermuth: You say it clearly, it is one of your points in the book, that says, "You won't be design experts, but will be design smart." And this idea of smartness really echoes me. And I was wondering if you could share an example of where you have seen this kind of design smart build-up with developers, and take the work to a different direction, hopefully, a better direction. Is that where you've seen experience and where you've fed some of the theories in the book?

Stephanie Stimac: I haven't really seen it anywhere yet. And I think that's, again, why I wrote the book, is to help sort of start that culture of being design smart, but not necessarily being a design expert, so that when we're building products, we are building, like, the best thing possible.

Sophie Freiermuth: And this is where your book comes in a very timely manner because indeed, I think there are a lot of very advanced, hyper-specialized design books. I have in my bookcase books on color theory and typography, which, at the same time assume you have the basis, they assume you've been to the school of design. They bring some concepts that are intelligible to someone who hasn't. But taking it around and starting at the, you know, back to basics, to get smart about it, to understand the bigger picture, and start seeing by yourself what's going on, starts changing the game. But what's interesting, I think, is asking developers to look at design is asking them to see something different. Sometimes I'm amused by the fact that developers need, and need to have, a very binary look and understanding of the world because ultimately computers are binary. The command is do or don't. Execute, don't execute. And all of a sudden, we're inviting them to break away from this binary, will this code roll out to deliver what we want, into looking at it in depth, in colors, in volumes, in spacing, in shapes of objects, including letters. Do you think that everyone can become design-smart?

Stephanie Stimac Absolutely. I think a big misconception is that, like, good designers are just born with that. And even as a designer, in school, I always felt a little bit out of my depth. I had an eye for it, but when I looked at, like, the top students in the class, I was like, "Oh, I don't know how to get to that level." But it's, you can train your eye, and just by copying, sort of, aesthetics and looks that you like, you train your mind to do that yourself. Everything can be learned. I feel like sometimes there's a little bit of gatekeeping too, with design, like, "Oh, no. Like, you're not a designer, so you shouldn't touch the design system," or "You shouldn't touch the color of that button or any..." You can learn all of this, and you can become a better designer, just like you can become a better developer. Like, sure, let's say you know HTML and CSS and JavaScript. But if you want, you can go learn another discipline. I know it's a different side of the brain, but design is the same thing.

Design skills for building products

Sophie Freiermuth: It is the same thing. It's about imagining what the world could be. And what I really like about the book is that you've brought a very holistic view of the book. And if I name some of the titles of the chapters, in Chapter 2, we have "Design Fundamentals," in Chapter 3, "User Experience Basics," in Chapter 4, "User Research," in Chapter 5, and "User Experience Design." And as a UX designer, I appreciate you've broken it down, but then you continue. You go to web layout, but it's not just web layout in Chapter 6. It's web layout and composition. In the anecdote of the kind of rainbow of skills that you've drawn, it continues enhancing web layout with animation, choosing and working with typography, and then color theory. Is that the order you've experienced building projects well? Is that where it all should be at? Or is this rather a sum of techniques, that this is a walkthrough that's suggested, and just pick and mix as you need it, depending on where you come in, depending where you're at, and what's needed? 

Stephanie Stimac The way the book is laid out is how I have typically experienced building products, just because...and I would say it's a suggested way to approach things if you have never sort of built or designed something from scratch. And maybe all the different parts aren't necessarily applicable to you. Maybe you're not doing research, so you can skip that. And then, I would say it's definitely laid out, though, in three sort of chunks. We have the design fundamentals, which are visual design fundamentals, but they come before everything else in the book because, in the UX research, and sort of content planning part of it, even though you're not visually designing anything, you still need to understand those concepts, those fundamentals, to build relationships between the content and how to do that.

That's why the fundamentals come, sort of, at the beginning. Then we go into research, and then the UX design part. And then the visual design part is the web layout and composition and typography. I wouldn't necessarily say that... Like, that particular section doesn't have to be done in that order. That's just the way that you could approach it. 

The end part is focused on testing and sort of how to iterate on a design. Again, you may not be in that situation. You may just be building a website for, let's say you're a freelancer. You're just building a website for a client, and then that's it. You're not necessarily going to do all that iteration. It's not a product you're designing. And so, it's pick-and-mix. It's almost like a choose-your-own-adventure, kind of. Depending on the context you're in.

Sophie Freiermuth: And choose your own adventure, I think, is very much how work is becoming in the digital world. Let me see if it's been your experience as well. I think for both designers and developers, there are two very conflicting trends. There is one that says you need to be hyper-specialized. You need to be excellent at Python. You need to be excellent at Ruby on Rails. You need to be excellent at React. You need to be also a full-stack developer. So, there are a number of these things you need to be excellent at. And yet, the jobs you're brought in may ask you to dip a little in all of these, to work with a team that has similar strengths, so you don't have to be the expert. And at some point, I think, even in a very balanced team, there comes a moment when you're almost alone. People are on holiday, they're all at a meeting, there is something that needs to be done, and then you are all alone, and then you get to pick your adventure.

"Do I wanna do a bit of research? Oh, the UX designer's not here this week. Maybe I go and complement my understanding." Has it been your experience that the jobs are changing, and the skill sets that are required to do fine in most situations are also changing? And this is why we need to keep learning and keep spreading out and getting more and more basics in more and more domains.

Recommended talk: Design For The Utopia You Want, Not The Dystopia You're In • Chris Atherton • GOTO 2019

Stephanie Stimac: In my opinion, at least from a development and design side... I'm gonna use my previous job as an example. We hired very quickly and had, I'd say about 10 to 15 developers. And they were all on their own teams, but what ended up happening was the ones who had skills for roles that were still open, even though they were hired, let's say, to do JavaScript, had Python experience. They got pulled in to do the Python work and backend work. And I think it's a good thing to be specialized in a certain area, but still having at least a basis of knowledge of what else is out there is incredibly helpful. I think that is gonna make you more appealing as an employee if you can... It's gonna also open up more opportunities for you too. Maybe you get bored doing just Python and backend stuff. But let's say the company needs someone to do front-end stuff. If you sort of like that context switching, I think that makes you more valuable, depending on, again, the environment. I think if you want a fast-paced startup environment, that broad set of skills is incredibly valuable. But I'd say having an area that you're specialized in is incredibly important as well.

A sequel to “Design for Developers”

Sophie Freiermuth: I appreciate that you finally brought the book that helps to keep on the side. And I think it's going to be one of these books that people have in their bookcase, and they don't refer to it every day. I don't think that's an everyday reference. I think it's a from-time-to-time. "Oh, I remember seeing about this. And let me do a bit of that." In your experience, of the many chapters is there a, and I know each of these could be a book on their own, but is there one already that you... Although you've provided the basics in the book because that's what this book does, it gives the basics, there's an interest, there's a curiosity, or do you know there's a need for more deep skills that start with the basics, but might be more... Is there a second book in you, Stephanie? Tell me more.

Stephanie Stimac: Is there a second book in me? If I was to write a second book, I actually don't know if it would be focused on design basics. I do talk about designing for developers because there is an aspect of user experience that is focused on developer experience. I think that would be a really interesting book to write. However, if we're gonna talk about, like, of what's already in the book, color is such a... Anyone who's not a designer seems to always have a problem with color. How do I apply a color palette? The psychology of color. And I have so many books. I have a book that's literally, about the interaction of color, and how colors interact together. And you can really transform a website's look and feel with just color. That would be a whole other second book. But I don't know if I would write that, personally.

Making colors accessible

Sophie Freiermuth: Just yet. Just yet. Let's have the first one out. I think color theory is so interesting because color brings so many aspects. There is, you've mentioned the psychology of color, the emotional attachments. There are strong cultural connotations to color and very simple things. Red, in Asia, is marriage. Blue, in the West, is corporate. Like, there are those big things that can be turned around and broken, by the way. They're not carved in stone. But they also bring in the fact that colors together may work or not work. We start slowly going into the domain of accessibility and understanding why, you know, a dark gray font on a pale gray background may look good, but it's not great. So, accessibility, I've seen it as not mentioned, but a running theme of, like, just make it work.

And I think in the polish, it comes in that this is where we start understanding why things work and don't, and we start making choices. This also takes us to the capacity to see colors. In your experience, have you encountered difficulties... Colors are difficult, but there's this other difficulty, which is about perceiving colors, and in particular, I'm talking about forms of colorblindness. And I don't know if it's been your experience, but I've seen, amongst developers who are, the ones I've worked with, are, I would say, a vast majority of Caucasian males. There is certain colorblindness. Do you have some trick for identifying that one of the issues might be a form of colorblindness, which means that yeah, it is a bit harder to gauge colors well?

Stephanie Stimac: The only sort of tip I have when it comes to colors and accessibility, in particular to, like, colorblindness, is there is a, I think it's a browser extension that lets you... It's a tool, and it will actually change the page that you're on, to even... Or it might actually be in the browser developer tools too. I'll have to check. I can't remember. But there is a developer tool out there, and it will change the color palette of the webpage that you're on to reflect what it looks like to someone with color blindness. You can use that tool to help identify points where, even though two colors may seemingly work together, and may be accessible, or look accessible to someone who's not colorblind, using that tool will let you see, "Oh, this is gonna be an issue."

Recommended talk: Did We(b Development) Lose the Right Direction? • Stefan Judis • GOTO 2021

Handling “I don’t like that color” feedback

Sophie Freiermuth: This all brings us to the fact that our perceptions are individual, and yet there is a very collective perception. And that collective perception, if I go on with a theme, starts going towards the, "I like, I don't like." And I think what's interesting with development is there is no liking or not liking the code. The code works or doesn't. The code compiles quickly or it compiles slowly. It calls in, in millions of microservices or it doesn't. When we start going towards design, the first thing that walks into the door is, "I like it, I don't like it." And as a designer, it has been my experience that a lot of the discussions I've had with teammates, with stakeholders, have been about who likes the most, or what is liked the most. What's been your experience of dealing with that aspect of design that developers won't have seen, I think, in their interaction with stakeholders and colleagues? How do you handle the "I don't like it" comments and feedback?

Stephanie Stimac: So, I always ask why. Why don't you like it? Because there's gonna be two sorts of answers. They're gonna say, "Because I have a personal preference. I don't like this color." Or they have an actual reason. One of my favorite anecdotes about client feedback is actually about a client I worked with at an agency. They worked on the Microsoft military affairs team, and we were building a website for them. The agency that I was at was. And I had used the color red somewhere. It was part of the Microsoft brand palette, obviously, like... So, I was using red as, like, a button color. And did the first design review, and the client immediately said, "I don't like the red because it's aggressive." And I was like, "Oh. I mean, that totally makes sense."

In the context, we're thinking in the context of someone who's former military. The users that we're targeting for this site are people who are just coming out of the military and trying to build up a new skill set for a career. And he was like, "It's too aggressive, and will have a negative, like, connotation to a lot of people." That, I was like, there's a reason I still talk about this feedback because that's a perfect example of good color feedback. On the opposite end of the spectrum, there was another project I was working on at Microsoft, with my team of developers. I was designing it and building the front end, and they built out the back end, but we were sort of our own customer, essentially. And so, we did a design review.

One guy didn't like the color that I had picked. And I was like, "Why?" "I just don't like it." "Well, why?" Couldn't give, like, a valid reason. And everyone else was fine with it. So that's not actionable feedback to me. I need to be able to understand why this isn't working for you so that I can make it more effective. I think one thing that people lose sight of as a stakeholder. When you have someone building your product or designing your product or designing your website, it's not about your preference. You think that it's important to you because it's your product, but you're actually trying to target a certain set of customers, and their preference is actually more important than what your preference is. You should still like the design, but if the only feedback that you can provide is, "Well, I just don't like that color," and your designer has a valid reason that they're using that color because it pertains to the audience that you're targeting, like, it's gonna be hard for them to make adjustments just based off of, "Well, I don't like it."

Sophie Freiermuth: I love those anecdotes because they... First of all, I absolutely have experienced the same thing, and you've broken it down into, I think, one of the fundamentals that design has to fight, which is, we get into power battles in meetings, of, "I don't like it." And I wonder if somehow this person wanted to say, "Well, I'm the most important person in the room, so when I say I don't like it, you should all be jumping." It seems like it didn't work. But also the fact that ultimately... Unless we're... There are two exceptions. It's a hobby, and we are building a website or a product just for the fun of it, because we just get kicked out of it, and then, "Yeah. Pick the color you like." And the other extreme is you are actually an artist or a fashion designer, and it needs to echo you, so if you don't like that shade of blue and you are the creative director of a fashion house, yeah it has to work.

But then it means that] if I like blue, it has to be me. And everywhere else, there is color theory. There is this wonderful tool, and I think you've expressed kindly that there are ways of approaching things, because it's about delivery efficiency. It's about delivering value, adding to the product, through those means that are now, for a developer, beyond the code working. The code also delivers an experience that enhances the power of the functionality. I don't just click a button, and I see that I don't know, my order's gone through. I see that the order's gone through and I get a feeling that it's going fast, and it's precise, and it's gone to multiple places at once, so great things are happening.

And color palettes are, I think, one of the angles that often seem like they're perfect. "Oh, you have a color palette? Just pick one." And yet, so often, "You can't use this color because it's for an alert. You can't use that color because it's a primary call to action. You cannot use this color because it's only used in the logo and never anywhere else." And now there is a simple method in the book to come in and get a bit of understanding of where's my wiggle room.

Stephanie Stimac: Yes, true.

Sophie Freiermuth: And a lot of the points you're bringing up are, in design, you need to go look, not for the obvious, but you need to look for the wiggle room. I think this is a mind shift, compared to development, where development, works or it doesn't, and your code compiles or it doesn't. It runs, but it doesn't. There is no wiggle room. Design is all about the wiggle.

Stephanie Stimac: Yes. 

Sophie Freiermuth: And developing this sense, I think, is where, also, you spent a lot of time in the early chapters. This is not just a how-to manual, the checklists. There's a lot. I really like the tone of voice you have in the book, which is a "we." It's a very inclusive tone of voice. You are taking the reader along the journey. It's not made for any specific kind of person. It's not for the freelancer, it's not for the person who's in a big team. It's for everyone who develops and just wants to get their head above the wall and have a bit of a look at what goes on. 

In the structure of the book, you've really made it not as just a checklist, do this, do this, do that. It's a little bit of a journey with just enough, and every chapter ends with a summary. Anyone who's in a hurry can just read the summary. I appreciate, however, that you really constructed the chapters at a fast pace, and constructed the layout of the book so that you apply your own advice. I think the way the book is constructed, with the titles, and the blocks of content, really works well. And if someone looks through the book, they can already see the advice you're communicating applied. Give the structure.....give the colors. Can you tell us more about that?

Stephanie Stimac: I know we sort of talked about, like, the three different parts, and how it's constructed, but we're literally designing a website, in the book. As you go through, there are, like, a couple sort of one-off exercises, but when we get to Chapter 10, we take literally everything that we just read, and then we just apply that, in the order that the book was written, so that you can just sort of quickly... I've tried to make it very step-by-step, to make it as clear as possible. Like, this is an approach. It doesn't have to be the approach, but it is an approach if you have no idea where to start, or how to sort of work through this.

Hands-on design

Sophie Freiermuth:  I love the structure, because when you look... I don't know if everybody does that, but I kinda look at the table of content and I try to see where is this going, and where could I use it. And I got to Chapter 10, which is called "Building a Website." And I'm like, "Oh. Okay. So, we're now doing all the work." But this is where there is a little subtlety. This is the exercise part. This is the, you can go and test everything I've just talked about and you've read about, and just have a bit of a play with it. I guess you chose a website because it's just an easy start. And at some point, we still all do websites, even though we say we do apps and products.

Most of them display in the browser at some point or another. And you touch on so many topics. I mean, if I just look at the introduction of what this chapter covers, it tells me about building a landing page based on requirements given to us by a client. I think for a developer, this is great. I think they often come in very late in the product development process. The design brief's been given, a design team has gone around, or a designer's gone around, or a client, which can be an internal client, has long thought about what they want, and the requirements are just so constraining. By the time it gets to developers, this problem of design decisions that are not implementable rise up, and throws everything in the air. So, this is really an invitation to come and play early. Do you think that people are going to get opportunities to do that in their jobs? How can you invite someone to go and do that and invite themselves early on in the design process, now that they're armed with the content of the book?

Stephanie Stimac: If you're a developer and you're not being invited to those early meetings where planning is happening, or if you have a product manager who manages that, message them, to ask to be involved. Tell your designer that you would like to be involved more early on in the process. And most people shouldn't have an issue with that. Some people might feel maybe a little territorial, but it's all about better collaboration, delivering a better product, and getting a different perspective. Just ask your team members how you can be involved earlier on in the process. I think doing that will help shift the culture. Then if you're a product manager who is not doing that, you should be doing that. You should have your team involved when you have the requirements, and start brainstorming. My experience with designing products and trying to come up with ideas for features, as a PM, I've been in the situation where we have a VP, we have our designer, we have another PM, we have a developer. Everyone has different ideas, and they're all valid. And that's how you get the best ideas, is having all those different perspectives in the room.

Leave a door open to grow

Sophie Freiermuth: Getting to be involved earlier is, again, what I think really is great with the book is that you're not telling people how to do their jobs, but you're opening so many little pockets of knowledge. Have you had this experience of getting little pockets of knowledge open to you in your career? Are you playing back your own experience of growing and developing and learning more, and being in more places, to...

Stephanie Stimac: I never expected to end up where I am right now. I mean, I'm currently doing consulting work, because I got caught up in the last tech layoff wave. But I started as a designer, and I thought that that was gonna be it. Quite frankly, getting hired at Microsoft changed my life. And I really, really loved that job, because I was in such a unique position. I was a product manager, but I was doing design work, and then it shifted into, I was also doing developer advocacy work. Like, I actually know quite a bit about the browser, how the browser works, and technical specifications. Like, my name is on a W3C spec. And Stephanie 10 years ago would've been like, "What is that?" Like, no idea.

Recommended talk: White-Hat Attention Jacking for Accessibility, Fun & Profit • Chris Atherton • GOTO 2022 https://youtu.be/VwocXCyOieM?si=ZS5SAkOm-dH6Ho_m 

Recommended talk: White-Hat Attention Jacking for Accessibility, Fun & Profit • Chris Atherton • GOTO 2022

After leaving Microsoft, I sort of shifted into, like, full product management mode. But I'm still a designer, and I still consider myself a front-end developer. I think it has benefited me greatly, and I definitely feel like my opportunities for work are much more broad. I can pick if I want to go back to design, or I want to be in product, or... And so, that has benefited me. It also just makes me incredibly hungry to learn more. I think that answers your question.

Sophie Freiermuth: It does bring it, I think, to everyone that there is this constant paradox and tension that technology, as it develops, requires more and more hyper-specialized skills, but it also requires people to always stay a generalist. And you might be the very, very, very best at this language, at this framework, but you also need to be able to step out and work with the rest of the teams. And teams are getting bigger and bigger every day. Design and development, I think, should be at the core of it. We've got all the QA. We've got content that is a domain that is not quite growing as fast as it should because integrating content and content libraries and structures is actually a monster that comes and bites very often. Soft skills all around, but also deep technical skills. And it keeps going around.

I think you've described very well that you're now in a position of knowing so many domains that you can still hyper-specialize in one. You can come in and take a job as a designer tomorrow. You can come in and take a job as a front end. And I think what's great about your book is that I'm hoping it invites more developers to dip their toes into the design, expand there, and see the fun that there is in understanding the bigger world, but also contribute so that this fundamental of technical feasibility in design starts getting addressed. Because I have also been on a project where, you know, it gets to tech, and they're like, "Oh, can't do." And, like, "We've spent six months designing this?" And, you know, the shoe that...the words that lack to shoe, for the lack of having the one guy who knew the bandwidth of the internet in that very location, six months of work were thrown out the door. We keep spreading the message. So, keep little basics and keep dipping this kind of books, you know, are so helpful. And I'm grateful that you brought this in. I know you're also doing a lot of work to continue helping... There's not just a book, because you speak at conferences as well, don't you?

Stephanie Stimac: I do. So, I've been taking a little break, because speaking at conferences is a lot, but I will be starting that up again soon. I speak about design and development. The last couple of talks I've given are on dual-screen design and development. So, I just got excited again, because obviously, Microsoft has the Surface Duo foldable phone, but Google just released their foldable phone. And so, I'm excited about that because there's so much cool stuff you can do on the web to design for design layouts that adapt to those screens. And then the other talk that I like to give is on PWAs, and design and development considerations. So, I give a lot of, like, design, development, like, intersection talks, so... And I love it.

Sophie Freiermuth: And you will be speaking. Most of these conferences are already recorded and accessible. Just look up Stephanie's name, and look up her book. And finally, so, you are working right now as a consultant, right? Some people can come and grab you.

Stephanie Stimac: Yes. Absolutely.

Sophie Freiermuth: And you're based out of the UK. Tell us a little bit how they can get hold of you.

Stephanie Stimac: Right. So, I am, we'll say, based out of Europe for the moment. But I also work with people in the U.S. So, my website is stephaniestimac.com. I have contact information on there. I'm also on Twitter. I'm @Seaotta, S-E-A-O-T-T-A. And I'm probably on there the most, but considering the state of the platform, find my website. My email address is on there, and you can reach out, and I do quite a bit... Like, I just got done doing a design assessment of someone's website, where I just went through and was like, "These colors aren't accessible. The spacing is off. Here's what you can do to improve it, or I can design for you." So, I design websites, logo... I mean, I'm a full-stack designer, you could say.

Sophie Freiermuth: You're a full unicorn. You can do it all. And I'm glad you brought the book out that helps to do more. I know I will certainly be keeping it in my bookcase, because I tell you, white spacing, I'm a UX designer. I am not a visual designer. I know my eyes don't see what I've seen some amazing visual designers do. They can spot things. I'm like, "My brain's not wired the same." But I'm so happy to have a resource that I can use and refer to, and just get things a little bit better, and make it a little bit of a better world, and develop new skills. So, that brings us to this is a better world for having your book in it. Thank you for writing it, because it's hard work.

Stephanie Stimac: Thank you.

Sophie Freiermuth: Very hard work. Coming out soon. You're available for questions. Let's hope Twitter continues to host wonderful design and development conversations. Otherwise, we'll find a way of connecting through the metaverse that is this world. And thank you very much to GoTo for having us have this conversation.

Stephanie Stimac: Yes. Thank you so much.