Adam Stacoviak: Let's talk about tactical design advice for developers. I think that comes with some pre-notion that you're smart and you can actually give advice, so Erik, help us understand what tactical advice might look like for developers.
Erik Kennedy: Yeah, so I guess I'll talk about this by means of a little bit of back-story here. When I was in college, I programmed for the very first time; I loved it. I was just amazed that I had never stumbled upon programming before, and I decided I was gonna switch my major to software engineering. And I did, and it was going great, and then I got a couple developer internships in writing production-level code for a medium-sized business I realized was nothing at all like all the side-projects I'd been doing... And it was just like someone who enjoys, say, fixing your own motorcycle, or whatever - if you really enjoy that, it doesn't mean you're gonna like other things that involve mechanical systems, like installing the HVAC for a skyscraper. It's a totally different scale of a thing, and that's how I felt with programming. I'd loved it so much just doing these personal side projects, or little things where I could just sit down and bang something out, come up with the idea at noon and finish it 3 AM.
Then I started thinking, okay, I really do like tech, but what else is around here? And I kind of stumbled my way towards design. I'd done a little bit of UX design work in school, and some at Microsoft, so I said "You know what, I'm gonna try my hand at being a designer. I'm gonna be a UX freelance designer. I'm gonna go freelance, so I can get this wide variety of experience as quickly as possible, and we'll just kind of see where things go. Maybe I'll end up landing on a cool company."
So no sooner had I started doing this than it became clear that for most people who wanna hire a UX designer, especially a lot of the smaller companies, startups, the people who are hiring a freelancer who's just starting out, who doesn't have a ton of experience - you know, you go and you do the typical UX deliverables, things like wireframes of the whole site, or you talk to some users and do a little user research report, or usability studies... And that's not necessarily the most satisfying thing for them, because it's not clearly leading your client on to the next step. Often times they see that and they go "Okay, cool, so we know we need to add this feature, and we know we're gonna make these screens, but what's the visual spec the developers are gonna code this to?" and I'm like, "Well, I don't know... I guess you need to hire someone else for that?"
Adam Stacoviak: [laughs]
Erik Kennedy: [00:04:14.21] But you can't quite say that, especially if you're an ambitious freelancer. You just have to say "You know what, I'll do the visual design. I can do it." So I just ran with it. I said, "Okay, I'll do this, and I'll kind of just teach myself, and at the times where I feel like I'm just turning my wheels, maybe I'll just flip off the clock and not bill them for those hours, but just try and work up those visual design skills."
I think this is an experience that a lot of developers or UX designers have had, but when you're googling around for design advice, "Okay, what typeface am I gonna use? What colors am I gonna use? What are the principles that I need to be working with here?", it's so difficult to find stuff, where kind of my golden standard for quality was "If I read this article, and I apply its principles to a design that looks bad, will my design look better?"
Adam Stacoviak: Right.
Erik Kennedy: And the answer was almost universally "No, it won't look better. We'll tell you about the golden ratio...", but the problem with most poorly-designed apps is not that they lack the golden ratio; it's not that they used some weird typeface pairing where the skeletons or the typefaces don't match up, it's not that they didn't strictly follow this 12-column grid system, or whatever. So I really began to try and differentiate in my mind what was useful advice about visual design, the UI design side of things, and what was just this weird art school dogma that designers all talked about, but just wasn't tactical.
With that in mind, I started putting together all the stuff I could find, and really just trying to build my knowledge base of "How do I take my developer brain and analyze my way into something that looks beautiful?" The first results of that were a Medium article that I wrote almost five years ago...
Adam Stacoviak: 2014, yeah.
Erik Kennedy: That's right.
Adam Stacoviak: I was surprised when I actually saw that, by the way. Because it says updated for 2019, and it began in 2014. This is an old one, but now you've refreshed it for it to be modern.
Erik Kennedy: Yeah, I just went through and updated a bunch of the font recommendations, and stuff like that. But it's this long, two-part Medium article, and it's really a lot of what I would consider the tactical design advice that I wish all developers and UX designers knew. It's things like realizing that light comes from the sky, and therefore shadows are very largely going to be below any object that is supposed to be perceived as coming out of the screen, like a button, or a card... And then shadows are gonna be on the top sides of things that are inset into the screen, like checkboxes or radio boxes. That was just one little lesson that I had no idea of when I first started designing, and realizing that was a big mind-opener to me.
So in these articles I just put in seven topics that I thought were pretty applicable to just being like tactical design advice, and it ended up going viral, which was crazy, for about two weeks in 2014. It was just complete madness. But it sort of slowed down since then, and I've just continued building out from that idea; I just realized that a lot of people besides myself were looking for those tactical pieces of design advice.
We could dive into some of them... I'd love for any of your listeners to walk away from this episode and go "Hey, you know what - now I have five or ten things I'm gonna go try with my little app, or my side project that I'm working on."
Adam Stacoviak: [00:07:51.28] What I like about the way that you've laid out these rules for -- and the title of the post is "7 rules for creating gorgeous UI", again, written in November 2014, and you've mentioned it went viral... I wasn't aware of that, I didn't know that, but it makes sense to have done that. But what I like about what you've listed here - you've got things like "Light comes from the sky", as we just talked about, where to begin in terms of color, so "Go black and white first..." I'm assuming on "Double your whitespace" - if you think you have enough whitespace, probably you wanna go ahead and double it, kind of thing... Because I think developers tend to be more concise with visual... And I'm not really sure, maybe you've done some investigation on maybe why developer trends of design tend to be a certain way, but I think that one thing that seems clear here is that it's not like it's "Oh, here's Design School level design advice for developers." It's more like "Here's some practical ways of looking at the way we create [unintelligible 00:08:52.19] interfaces", and you describe ways to move in and move out of that without having to have an extreme amount of skillset to do so... So just being logical - light comes from the sky. It makes sense, that's where the sun's at, so it makes sense in interface to follow that, and/or also say "Hey, understand where your light source is coming from" could be another way to say that.
Erik Kennedy: Yeah, exactly. And that's true. I feel like design is not something you should really need to go to school for years - at least the visual design side of things - to pick up enough to get by. I think it should be very possible for someone to know a couple tips, tricks, heuristics for what they're even gonna consider doing and what they're not gonna consider doing, and go from there.
Adam Stacoviak: What I find though is that there are people -- and let's just use the developer here in this case as the primary sort of person that we'll pick on, so to speak... They tend to know good design, but not often can they create it, which I find is a really interesting thing, and maybe that's not true for every developer out there, but you can tend to see "A developer did the design on this..." Or we can use GitHub, for example - GitHub today is way prettier than it was when Tom Preston-Werner shipped it. It was not bad, it was good, but it was a developer-driven design, and Tom Preston-Werner was a developer first before he was a designer, but he had some good design skills, or he had some understanding of design. So you can understand and even see a no-good design by using it, but not be able to create it. What do you think about that?
Erik Kennedy: I think that's spot on. I mean, I hear -- it seems like every day someone e-mails me and they say "Hey, I can identify good design, I just don't have a gut instinct for it", that's what they'll say. "I can tell what I like, I just can't recreate it for myself, and I don't know what the issue is here." So here's the secret to everyone who e-mails me saying that - my response is almost universally "Here's a two-step process. Find something you do like, find something where you think it is really good design, and something you aspire to - find that piece, whether it's a website or an app, and then the second step is analyze why you like it." And when I say "analyze", what I'm getting at here is like force your brain to come up with words that surround what you think is good about that particular design. And I think it really needs to have a low bar. You don't need to think of the perfect Design School terminology, you don't even need to use terminology that would make sense to anyone else. If you're just like, "Wow, this font is really fatty and in-your-face and I like it" - cool. Just mentally make a note of that. You could even write it down.
Adam Stacoviak: Yeah.
Erik Kennedy: [00:11:48.22] Or you say, "I like the whitespace on this site." Fine, write it down. Or write down why you like the whitespace. "Well, there's a ton of it, and it makes the thing feel really presented." Let's see... Looking at Changelog.com, I like this site; if I was doing this as an exercise right now, I'd be like "Oh, okay, the dark background. The dark background is really cool. I like the green theme color. It sort of has a glow to it, and it feels kind of fresh. It's not your default green... It seems to work." I guess it also has a little bit of that command line, old school terminal feel to it, which maybe is a nod to that.
I like the font. I'm looking at this, and it's one that I've -- I guess I've really not seen this much Sana Sans. Oh, and I love that you have all the different shows and each one has kind of their own little visual icon, where there are all these geometric designs... It's like, they're clearly unified, but there's a different thing going on with all of them. Some of them have warm colors, some of them have cool colors, some of them are organic shapes, some of them are really geometric shapes, but they clearly all go together as kind of one system.
So when I load up the changelog.com/podcast, those are some of the things that I see and I go "Wow, I really like that." But the trick here is when you as a developer, as a beginning, fledgling designer are doing this, if you can force your brain to come up with a word for the pattern that you see, where you're like "Well, I like the casualness of the font", or whatever, or "I like that dark background", then you can start to see -- the next time you land on a site that has that dark background UI, you go "Oh, I like this one too. What do they do similar? What do they do different?" Or maybe I see another site that has a really similar font, and when I land on that site, I'm like "Oh, okay..." Your font kind of looks like Freight Sans, which is another one that I like a lot... And it's like, if I saw a site with that one, "Hm... Okay, maybe there's something about these fonts that look so similar that just kind of appeals to me."
The whole point of putting words around what you like or don't like in designs that you see is that then you can start to connect those. Your brain can build off of those nodes and connect them into other sites that you see, other apps; you can figure out what you like, what you don't like, when you like it, and it'll start to give you this list of ideas that you can try when you're working on your next design... And maybe it's appropriate that you have a dark background, and all of a sudden you're like, "Well, there's three sites that I like that have dark backgrounds. I can go to those, and I've noticed they all do X." Maybe they use only white and grey text, with one bright, neon-ish accent color. "Okay, cool." There's a thing that you can do that automatically is gonna put you way ahead of the pack when it comes to designing that site.
So you just start to notice those things, and you kind of build up your list of "What's gonna work here? What do I think I like, and what are the circumstances under which it's gonna look really good?"
Adam Stacoviak: That's good too, because anybody could do that, right? Anybody could say "Here's what I like about it, here's why I like what I like about it" and then archive that, and then rinse/repeat as that happens, so when they come up with their next design challenge and/or side project, or scenario where they're either by desire or force charged with coming up with something, taking the first stab at a new feature.
There's a lot of times too around here - Jerod has really good design insight, but I wouldn't call him a designer, and he wouldn't call himself a designer either, but he understands what the user needs and wants, he understands how to analyze a feature, and he understands how to do all these different things to deliver a good first pass for us to at least ship with to create that first momentum. And sometimes that first momentum is good enough, and it leads into the next phases of a design process, or user experience process, or whatever it might be...
[00:16:01.01] But I really appreciate that, because he's empowered to not be stuck behind "Here's a design spec" or "Here's a flash.design", because that keeps the ball moving in those cases; and I think when you empower developers to inch into design a little bit more, and not feel like maybe they have to do the ending all product, but that they can help move the ball forward is pretty empowering.
Erik Kennedy: Yeah, and I think part of it is just a mindset shift, just going from the shift of thinking that design, especially visual design, is just kind of this art school magic that you sprinkle on at the very end, and just make the thing that doesn't look so good look way better... And instead saying, "No, you know what? Design is open-ended. It is an open-ended pursuit..."
Adam Stacoviak: It's subjective.
Erik Kennedy: In some sense it's subjective, but I think it's way more objective, at least visual design, than most people give it credit for. Not objective in the sense that there's one right answer, but objective in that what a large number of people would agree is a really, really good answer can actually be explained fairly logically.
A lot of design decisions -- well, I think you may have heard this, but a hallmark of good design is it seems obvious in retrospect. I feel like when you implement something that is truly a good design, you go "Man, why didn't we do this a year ago? Why did it take us so much hassle, and talking to users and trying to figure out if we should do this or any of these eight other things when this was so clearly the thing that we should be doing?"
I think visual design is kind of the same way, where when you do make a good visual design choice - not to say that's the only one you could make, but when you pick what you think is the right font, a lot of times there's gonna be rationales behind that for why this particular font worked. "Oh, we had to pick a sans serif because it was gonna be on the more casual side of things... But not so casual we wanted a rounded sans serif. So we just went with one that was in the category that designers call humanist. It's based on human handwriting, if only loosely. And we knew we wanted one that would work well at really small sizes, because there's some captions on our mobile app that get displayed in this...", or I don't know; there's little things like that... But there's all kinds of rationales that build into -- why was this color chosen? It may seem arbitrary, but you can actually construct this rationale for why it's a good choice.
Adam Stacoviak: You're touching on - I think, at least - potentially even iteration, where, you know, "Why didn't we get here sooner?" or "Why didn't we do this first?", I think sometimes design is also iterative, in the fact that you're not really sure sometimes needs to go until you get to mile marker one, mile marker two, and then finally when you get to mile marker four, now you finally understand what it is you're building, or why you're building it, or even if it's user feedback, or even internal feedback, or experimenting, "Does it work? Does it not work?" You mentioned choosing a typography that works well with smaller sizes, but you may have three candidates for that particular typography or that particular font in this scenario, but only until you get to the part where you're like "Oh, it has to be 10 pixels, for some reason", or whatever the smallest size might be in your layout, and you're like, "Well, this font doesn't work anymore. Now we have to choose a different one. Why didn't get here sooner? Why didn't we choose this monospaced font?" Because heck, hackers love monospaced fonts; we should be more in the know, so that's why we in particular chose a sans serif font, as well as maybe a hacker level font... I think what we're using is -- what is it? It's a Google font; it's Mono Pro, or something like that... Roboto Mono is what it is.
Erik Kennedy: Oh, okay.
Adam Stacoviak: So we chose that one purposefully because of some of the unique attributes in that font, but we didn't get there at first. We delivered a site in 2016 that didn't have any monospaced font, and then we decided to start to incorporate that in our design that we shipped at the beginning of last year. So we had to even iterate to get there, even though we're hackers, we're developers primarily, so our audience is us. So it even took us iteration to get there.
Erik Kennedy: [00:20:19.03] Yeah. There's a lot of stuff in design where you do have to get it out there... Even visual design, which to be fair, I don't think visual design is the number one priority; even though this is the thing I teach with my course and in my blog and in the mailing list, and whatever... Visual design is not to me just the be all end all. It is important that users have the right features, and obviously getting it built in efficient and manageable ways is super-important as well... But even with visual design, you think "Okay, we're towards the end of the process here. What could we possibly iterate on?" And then there's things like the fonts, too.
I remember one project used this kind of cool, rounded font that's called the Omnis, and it's a perfectly nice font, but then what we realized as we were designing a bunch of the screens is we had to display a lot of numbers, and Omnis had these really weird numbers that just didn't seem like crisp or clean; they seemed just goofy, and they had these weird ornamentations... And for me, I was like "Oh man, if I had known this at the beginning I wouldn't have wanted to use this font to begin with."
It also comes up with color schemes... Designers love to talk about color pallets, but a lot of times it's very tough to just say "Oh, I'm gonna use this color pallet" and decide that's the pallet you're gonna use before you even start the project. You need to design out some screens, or at least start designing out some screens, and then you kind of look and see - let's take a Changelog example... It's like, maybe you wanted a part that had a green background, but with the green background you're gonna have this huge mass, thousands of pixels, all colored in that same shade of green. And then all of a sudden, if you decide that that's really necessary to have that big green background, you might want a lighter variation on that green. You don't wanna use just the standard green that you have, because it would just be too much in your face, or whatever.
So there's all these little things that as you're designing, you go "Hm, I'm gonna tweak that." It's very tough to come up with the visual specs right at the beginning and just stick with them. It's definitely a chicken and egg, iterative process.
Adam Stacoviak: So when we start projects sometimes we're a little lost... I know for me, I'm an old-school kind of person; I used to just open up Photoshop, the default for new Photoshop documents... You can tell I'm showing my age here, because Photoshop for design is sort of like done with; you moved on to new tools there, like Figma, or Sketch, or whatever... Saying "Photoshop for design", and that being your beginning is showing your age, but that's what it was for me - I would open it up, get a white document, and I would stare at it and be like "Okay, what do I do...? Do I lay out some content, do I lay out some headlines? Where do I begin?" I think that might even be the show-stopper for some people; it's like "Where do you begin?" Do you pick off certain pages? Do you decide your typography first? It just seems so daunting of a task, you're almost like "You know what, I'm just gonna go ahead and code this feature and ship it and be done with it, and skip the design stuff. I'll let somebody else handle that." What do you think? Where do you begin?
Erik Kennedy: [00:24:34.16] Right, that is the temptation. It's just, "Um, I can't decide. We'll just do a bootstrap thing and table the decision for later."
Adam Stacoviak: Yeah.
Erik Kennedy: Yeah... No, it's all too real. I think exactly what your beginning process is depends on how big of a team you're working with. If it's just you, it's like all the communication is intra-brain. You might have things that you've decided on that you don't need to sync and validate with everyone else on your team, and you can just charge ahead and start designing something right away... But I think if you have even a couple people that you're working with, it's probably best -- and this is gonna sound so obnoxious to a developer, and the part of me that still loves all that development and analytical stuff is like "Really...? Start here?", but I would honestly start with the brand.
And by brand - if you want a tangible definition of it, I would say "How do you want users to feel when they're landing on your site?" And this, again, is just something where it's like you almost wanna pick some words, some adjectives, and it can be very loosey-goosey, it doesn't need to be perfectly nailed down, but on the whole, are you more friendly, or are you more professional? Are you for kids, or are you really edgy? Is there traditionally masculine connotations or feminine connotations to your design? Just questions like that, where you have these sliding scales... You say "Where roughly are we? What is it exactly that we wanna convey?" And while this does sound like just sort of a ridiculous exercise, it'll help, because the moment you go to pick a particular color or pick a particular font - which is kind of the next step - you can validate, like "Does this make sense, given the brand that we want?"
This is an example that I was thinking of today, right before the podcast... So it's no secret that a lot of social media sites use blue as their theme color, and a lot of people will talk about how blue is this color where the emotion is trustworthiness, or sort of state, it's solid, it's dependable, it's not gonna have too much of a one unique voice, that's like a strong brand in any one direction, but it's just kind of this general-for-everyone sort of feel. Blue is a very safe color. And if you've identified that you're Facebook or you're LinkedIn or you're Twitter and you're kind of like an app that should be for everyone in the world, then blue is a very decent choice.
But then from there, maybe the next step after saying "Okay, we wanna be a safe brand, we wanna be open, we wanna be universal" - maybe those things push you to say "I'm gonna open up Sketch or Photoshop (that was where I started, too) and I'm gonna take this blue, and...", heck, you could even start with the default HTML or CSS blue color - totally saturated, all the way cranked up to the full brightness, default-default blue. That would be 00F, I think, in terms of the Hex color... And then you just kind of adjust it from there, and say "Okay, we clearly don't want the default-default blue, but what blue do we want?" And one thing is - I'm pretty sure that all of Facebook, LinkedIn and Twitter have done this - is they lower the saturation of the blue, and they also shift the hue down towards green, if you think about the color wheel.
Adam Stacoviak: [00:28:11.00] Yeah.
Erik Kennedy: And maybe they keep the brightness pretty high... But those two levers, just moving the hue, injecting a little bit of green in, and just kind of lowering the saturation - those are things that Facebook does at a different amount than Twitter; Twitter does at a different amount than LinkedIn. But the net effect is they all end in a slightly different blue color, where they all could have started from the same place, saying "Yeah, we want this universal, dependable brand for everybody, but we're just gonna have it be a little brighter and funner than what you might think of as this default blue."
So from there, when you've kind of said "Here's the brand adjectives", then that's when I would start playing with colors and fonts. Those are two of the first things that I'm really gonna need to decide. And for beginning designers, you always have the option to just say "I'm really gonna not use hardly any color." There's always the strategy of just going as grayscale as possible. And if you look at most of the apps and sites that you use that look really well designed, it's really not like they're gonna have four or five different colors that are all featured prominently throughout. It's usually just gonna be mostly grayscale, with one color, and that color has some variations on it. And maybe, yeah, you need a red for your error message, or whatever, and a green for your success message. But for the most part, it's pretty simple. It's just those little variations.
But like I said, this is the point at which I would open up Sketch, once I kind of know those brand adjectives, and I would do what the design community calls style tiles. Style tiles basically just means like make little bits of your UI that you're not trying to make them look exactly like the finished product, but you're just trying to suss out "Alright, if I pick this serif font - I'm just gonna make a button and see how that button looks. Then I'm gonna try and address some questions... I need this serif font to be in all upper-case, because it just looks incongruous to have a flat, perfectly rectangular button with this fancy font." Or maybe it'll make me think "I've gotta change my font to something else."
But for a little more on style tiles, I think I have a blog post that covers it in some detail, called "Five practical exercises for learning UI design for free", something like that; you can just google that. I think I give some examples of style tiles that I've done where I'll play with some of the type, I'll see what a header would look like on the site, and then I'll see what the body font would look like on a text page... Say it's the About Us page, or the Contact page. Or, speaking of Contact page, most sites need to design a form; so I'll just try putting a few form components together...
And I don't mean to say that the whole purpose of this is to create your design system, or your design library. It's not about making every component in advance. It's more about just trying to get little bits of interface that you think you might actually use in the real thing.
Here's an example - I'm on that blog post that I was just mentioning, the five practical exercises for learning UI design for free; one of them is style tiles. If you skip to that, I show this one that I made for a company - I don't think they're around anymore, but they were a Y Combinator company a few years back called Instavest. They were this investment company, and they had a unique way for allowing users to invest in stocks. And a couple of the things I was playing around with for style tiles were like, I have this little chart widget where I have a line chart on this dark blue, and then I had just a couple colored rectangles to play with, like what colors might look together...? Since it was a site related to finance, I was like, "Oh, maybe we'll go with a green." Green has strong financial connotations, especially in America.
[00:32:07.25] Then I had a couple things where I'd just put little bits of text that may very well appear on the site, but it was real copy from the site. I put "Find world-class investing ideas" or "Make money twice on your best stock tips." Those were things that were kind of relevant to the business... But the point is all that stuff that might really appear on the app or the site - I wanna just start playing with those and kind of feeling out like "Is this giving me the brand that I want? Is this making me feel the adjectives that we've agreed that one should feel when they land here?"
Adam Stacoviak: It's interesting how you use the -- obviously, we're talking about adjectives here, and they key off of emotions, and I think that people often forget that there's an emotional reaction to every user interface that you encounter, whether it's in the real world, or in the digital world; there's some sort of emotion that you're kind of getting. I like how you've said and prescribed to begin with the emotional things, which are the attributes.
Erik Kennedy: Yeah, yeah. I mean, again, I'm so worried putting that advice out there, because it's like "Who's gonna really want to follow that?" But if you're working with a team, I think it's a good thing to settle on some of those brand details ahead of time. If it's just you, you might actually have a sense of -- without even needing to label it, with specific adjectives, you may have a sense of the brand that you're trying to go for.
Adam Stacoviak: Let's try that exercise real quick... Since you've used changelog.com a couple times as your examples, I have here in front of us our brand guidelines, and I'm on page two where we have our core attributes. Our core attributes - when we did this same thing prior to design, we sat in a room, figured things out, and we said "Okay, we are hacker, we're real, we're open, we're caring, we're steady, we're curious and we're fun." Do you think what you see today represents those words? And I can say them again if you want.
Erik Kennedy: Yeah. So when I just popped open your site, I was like - developer-oriented, modern... Not casual per se, because I don't think I've seen anything that's like "How you doin', buddy?", but just -- not laid back; I don't know... Not too uptight. I would say developer-oriented, modern, and not uptight. That's what I see boiling out of that. But I wanna compare that again to the list that you read.
Adam Stacoviak: I'll say it again. Hacker...
Erik Kennedy: Definitely.
Adam Stacoviak: Real.
Erik Kennedy: Yeah.
Adam Stacoviak: Open...
Erik Kennedy: Okay.
Adam Stacoviak: Caring, steady...
Erik Kennedy: Okay...
Adam Stacoviak: Curious and fun.
Erik Kennedy: Yeah.
Adam Stacoviak: So do you think we delivered?
Erik Kennedy: I think so. I mean, there' a couple where I'd be like "What exactly does that mean?" The open and the curious.
Adam Stacoviak: Right. Yeah, curious is definitely more the one where you're like "Eh, it's a bit ambiguous. What does curious really mean...?"
Erik Kennedy: Yeah, right? But I don't think it's a problem to have that kind of stuff in those brand guidelines, because it might apply to plenty of other stuff besides just the visual design, right?
Adam Stacoviak: What I like too about your idea of the style tiles example is that it gives someone a chance to take a micro-version of the ending thing and begin to experiment small, achievable ways. And then you're also able to present those to other team members and/or themselves later on, if it's a single-person project... But let's just assume you're in a common development team, whether you're in a large business or not; they usually break them up into units, so they tend to be between four and six people... Maybe a little bit bigger than that, but generally four to six people; you've got a product owner, you've got a couple developers, you've got a designer, you've got potentially a copywriter, a UX designer, maybe somebody's doing both of those things, or straddling a couple of those titles, but those are roughly the breakdown... So even in a team like that, you can roll out style tiles, or some micro-version of portions of your interface, and begin to feel good about the direction you're taking.
Erik Kennedy: Oh, for sure. Yeah. And that's one of the biggest things with working on a team, at least for a designer - syncing those expectations. It's always the worst if you're designing with a group, to put a bunch of work in and be like "This is perfect. I love it. Also, I will present it to them after it's totally done." And then you present it to people and the rest of the team is like, "That's not what we had in mind at all." That's the worst feeling.
[00:36:17.29] So something like style tiles definitely helps avoid that. It's like, you can sit down and in half an hour come up with some of the first-stab attempts at brand adjectives, and then an hour after that the designer can waltz back and say "Hey guys, look what we've got here. What do we think of this? Is this kind of what we're thinking?" and people go "Oh, yeah!" Then you get the awesome reaction. "This is exactly what we want! This is cool!" It's coming to life already, and all it took was one hour, and one 20-minute session of talking about your feelings.
Adam Stacoviak: I like too when you lay out the fundamentals that color is number one, because I do believe, even though you say later on in different examples that you share, black and white first - I think that was in your seven rules viral post from 2014... But in your fundamentals of user interface design the first thing is color, and I think that may be coming after you've made some choices potentially, but color being a key thing, because that is the very first thing that conveys emotion. For example, your example of -- let me go back to it here real quick... Instavest, right? This one here, if I can see correctly, it seems like green was chosen, probably because it dealt with money or finances, and green obviously is the color of most money, or at least the underlying core color. And then you mentioned social networks earlier, about trust and things like that, blue being used there... So there's certain places where color is sort of even pre-decided for you, because of just... Life. There's just certain things that say "Hey, blue is best used here. Green is best used here."
You mentioned error messages - red. Well, you're not using green for error messages, because that means Go. My son just told me yesterday when we were driving, "Hey dad, red means stop, green means go." Even a near three-year-old gets that.
Erik Kennedy: Yeah, it's true. I think the color is definitely one of the first things that conveys "Hey, you as a user, as a viewer, what should you be feeling? I'll tell you." And it's funny that you mentioned it's just decided for you... This is kind of what I mean by it being not objective, but also not quite as subjective as you might think.
The real fun comes when you say "Alright, here's the color that is pre-ordained for us to use. We're launching this big social network. The pre-ordained color is blue." "Oh, we're launching this product that's exclusively for women. The pre-ordained color is pink." "Oh, we're launching a bank. The pre-ordained color is green", or whatever. Then you say "How can we twist that? How can we come up with a little variation on that? How can we do something that's not gonna be exactly what people expect?"
Take the pink example. Just because you're working on some product that's just for women - just because you're working on some product that's just for women... If you do something that's just pink, you're lost in the crowd of other pink products, right? So maybe you could do something that captures that you're trying to attract a market of women, but not just with the color. Maybe you could use some watercolor, or floral imagery. There's just other things that have feminine connotations besides that pink, and maybe your brand color could actually be -- I don't know in this case, but maybe you're just using a lot of whites, and light greys, and then some pastel stuff.
[00:39:47.06] Or with the bank - yeah, maybe you think "Oh, we need green, or something", but there's plenty of banks that have explored light blues... I was just on simple.com. They're a new banking app, and they've got this almost [unintelligible 00:40:00.10] light blue sort of color, and it' s just a cool take. It's like, "Okay, I see what they're going for", but they just twisted it just a little bit. They're just playing with it... Yeah, like I said, that's kind of where the fun comes in, I feel like.
Adam Stacoviak: Obviously, most design is made of content - not just simply images, but actually words, so the next choice would obviously be typography, and the importance of it; that kind of plays into whitespace even because of things like letter spacing, or kerning, or even how thick or thin the font might be, things like that. So why do you think -- I'm assuming you think this, but why do you think typography makes or breaks a design?
Erik Kennedy: Oh man, now I have to decide whether or not I agree with that, and then answer it... [laughs]
Adam Stacoviak: Let's start there - do you agree or disagree? And if you disagree, why?
Erik Kennedy: You know, it's kind of this design truism, that people say "Web design is 90% typography." I think my answer to that is "It can be." [laughs] You can make a site that's just incredibly text-based; you can also make a site - and this takes maybe in some sense more skill; I don't know - that relies on just astounding imagery, and a bunch of cool colors, and just uses the default system font, and looks perfectly fine, and no one would ever complain about the typography.
So yeah, maybe I would lean away from the statement that type does make or break it; I think type CAN make or break it.
Adam Stacoviak: Oh, I like that, okay... I could be swayed...
Erik Kennedy: I'm just getting wishy-washy here.
Adam Stacoviak: I could be swayed. I'm digging it.
Erik Kennedy: I will say that one thing that blew my mind when I first started designing was the degree to which using a really good font was just like a cheat code for making your stuff look nice.
Adam Stacoviak: That's true, yeah.
Erik Kennedy: Yeah, and I had no idea. I thought, "Oh, fonts are like five of one, half a dozen of the other", or something. You know, there'd be differences, but they'd be so slight it would hardly even matter. And then it turns out -- I've definitely worked with a couple students on some of their designs, and I'd be like "Let's just sub this font for this", right? And then all of a sudden they go "Whoa... This looks so different!" I list a couple of those in the Sever Rules piece, just some of the free go-to recommendations that I have for what typefaces you should be using... But almost anything that you hear of as being too trendy of a font - I think Proxima Nova might be the biggest defender from the last three years or so...
Adam Stacoviak: Oh, I used that one for a little bit.
Erik Kennedy: Yeah, it's a fantastic font; it's just -- like, try and make just normal text look as good in some other font. And of course, it depends on exactly the style you're going for. If you have something that's more scholarly, then maybe you want a serif font, or whatever. But I think most clients these days, most projects that I've worked on just kind of want something that's generally clean, simple, modern, fresh... And it's like, well, Proxima Nova is not a bad option. There's definitely a reason why people say it's trendy. So yeah, type can be important with that.
Adam Stacoviak: In part two you say "Only use good fonts" though... So what does that mean? Are we layering the onion one more layer? It's in your rules, it's rule number six, so...
Erik Kennedy: Yeah, but that's kind of what I'm saying - when you use really good fonts, when you use the highest-quality, the top 1% of what's out there, it is just gonna be this cheat code where you're gonna look like you're doing a better job designing than you might actually have the skillset to back up. It's like, take some default web font, like a Tahoma, or whatever. Something that's set in Tahoma - it's gonna be very tough to make it look fresh and interesting. It's just gonna scream "Default!" to everyone who sees it, and it's very tough to get away from that connotation.
We talked about Freight Sans, and -- was it Sana Sans that you've got going on?
Adam Stacoviak: Yeah.
Erik Kennedy: Both of those seem like really good ones, where you start working with those, and something that looks kind of boring is gonna all of a sudden "Oh, okay... This is cool. This is modern." But can I put an addendum on this "Use good fonts" thing?
Adam Stacoviak: [00:44:13.10] Yeah, please.
Erik Kennedy: The other thing that blew my mind, in addition to just the importance of using these top quality fonts was also how little of design was actually picking fonts. You pick fonts once for a project, presuming you just have one font. Maybe you have a couple, so you pick your two or three fonts. And then all of the rest of the visual design work that you're doing is like styling text. So as far as typography goes, I had totally underestimated how important styling text was, and -- this is, again, the sort of thing where if you're just googling around, looking for design advice, you'll find so many articles on pairing fonts, or evaluating what font is good for body copy... You'll find virtually none on practical text styling tips. These would be things like -- beginning designers, in my experience, almost universally under-use upper case. They almost always use thin weights of fonts too much, and bold weights of fonts not enough. So just little things like that.
Then you can even break it down into like "Buttons are gonna be far more upper case than you might otherwise expect" or, when you have lists where there's kind of a key-value pair of something, like "This product weighs this much and costs this much, and the height is this, and the length is this...", styling lists and key-value pairs like that - there's different tips and tricks that go into that. There's just all kinds of little text styling stuff that comes up, and to me, that's the real skill that you need to hone if you're trying to get into design. It's like, you pick fonts once, and then for the rest of that project all you do is style text... At least typography ones.
Adam Stacoviak: So after you've got good color in place, good typography, the next logical place is "How should we lay this page out?" You've got things like what's important, what's the hierarchy, where do buttons go, where does the footer go -- we obviously know where that goes, right? At the bottom. So there's some easy choices made for you already, but it's kind of like a sandwich - you know there's a button on top, you know there's a button on the bottom, and you've gotta choose your ingredients, what you put in the middle there... Is that layout? What is layout?
Erik Kennedy: Oh man, now you're getting into the tough questions here... Because people will e-mail and they'll say "Erik, I really wanna improve the layout in my designs", and I can't quite crack the code of what they mean... Because everyone means something different by it. And I actually have to ask, "What exactly do you mean?" I've never gotten the same exact answer twice.
Layout means a lot of things to a lot of people, and if you google around for design advice, you would think that for most designers layout just meant what 12-column grid system you're following, and if you have the golden ratio worked in somehow.
Adam Stacoviak: That's not layout then? This whole time I was wrong.
Erik Kennedy: [00:47:59.08] Yeah, I mean, in some sense I think that's layout, but it's not the tactical side of layout. If you go and put your stuff in a grid -- I mean, grids can be a nice way to format content by default, but they tend to get overused and overhyped in terms of how powerful of a design tool they are. It's more important just to be good at aligning your content really well.
I have another blog post talking about this called "Why beginning designers don't need to learn grids, and other designer dogma...", and there's a couple other names that I name in this post, but grids is one of them. It's kind of the go-to talking point when designers talk about layout.
I think what it should be instead, if you really wanna get good at layout - it's not that layout is some one skill that you just develop directly; I think it comes more from developing all these other little sub-skills, and then as you develop them, your layouts are going to get better. Here's a couple of those things...
One would be -- well, designers call it hierarchy, but I think that's just sort of a fancy word from what pops, and how much. In general, any design you're working on, you want the most important thing on the page to pop the most; you want it to be the first thing the user sees. Then the second most important thing on the page should pop the second most, and the third most, and so on... And just kind of go on down the line. If you do that, then you're neatly corralling the users' attention through your site, or through your app, so that they're looking at exactly what they should be looking at, and the moment they decide "Hey, I actually wanna try and find this feature... I wanna find the search bar." The moment they look for the search bar, they can find it, but it wasn't screaming out to them and distracting them before they were looking for it. That's good hierarchy, and I feel like that's also the stuff that makes for good layout. And then maybe part of the other side of the coin is just keeping things really neat, aligned, and well-spaced out.
Adam Stacoviak: I like what you said there about the search bar, because it is important to find if you wanna find it, but you don't want it to be like, "Oh, you must search to navigate this site", because that equals potentially a poorly-designed site, because you've got your importance off-key, because "Hey, visually I'm not finding what I think I should find. Trigger words aren't jumping out at me. I'm a first-rated user, I think I should search." But if you do get frustrated, it should be "Hey, don't make me think." (Steve Krug) Where does search tend to live at? Up into the right, or somewhere North, right? And it tends to be a little subtle until you interact with it, and then it's like "Okay, I'm definitely in some sort of search mode."
Erik Kennedy: For sure, yeah. That search does kind of work as a good example, because it is something that a user thinks "I need to find this", and they might be thinking that while they're at any other point in the page, and then they look for that. I suppose a main menu/overall navigation could be the same sort of thing...
Adam Stacoviak: It seems though that it can take a level of experience - and I don't mean smarts, but experience meaning you've done it enough, you've gotten some wisdom, having had some bloodied knuckles along the way that layout is actually kind of hard. You've gotta try several times and probably get it wrong a lot before you truly begin to hone your layout skills.
Erik Kennedy: Yeah, that rings true. When I look at a design, there might be things that -- let's say it's one of my students' designs, or something; I look at that, and they say "Oh, I've got these layout issues with it", but to me, I'm seeing those as being issues of hierarchy, or issues of alignment... So yeah, if there are a bunch of sub-skills to layout, then it would make sense that that is something that you've just gotta churn through, try and improve slowly, bit by bit at... So that would make sense.
Adam Stacoviak: [00:52:01.00] How do you get to a good design then? If you've got color, typography, layout... You're kind of fleshing all those things out, you kind of feel good about it at least. You've gotten some colors chosen, everyone feels good about that, you've gotten some typography you've experimented with and it works in all the areas you need it to work, so you've got that locked down and you've got a good layout groove. What's next to kind of wrapping it up into "a gorgeous UI"?
Erik Kennedy: That's a good question. I think in some sense you're just never done with the fundamentals; there's always gonna be little things that you realize you could have improved upon throughout the site... So there's little tweaks and stuff that are gonna just continue to keep happening. But I think you're asking maybe more about something like "What are the finishing touches to a design?" Once you've decided on the font, once you've decided on the colors... Say you've got a bunch of the pages even fully designed in Sketch, or whatever app you're using, I think I would circle back around to brand, and then also at that point I would be really trying to make sure with the team - and maybe even with the users too, depending on what exactly the product is - like, "Is this coming off the way we want?" It's always the best when the project is done and people go "Yup, this looks exactly like what we were hoping for. We didn't know what we were hoping for, but now that we've seen it, this is it." If you're not there, then it's just, like you said, this iterative process of saying "Well, where did we go astray?" And you can be analytical about it - "What is the goal that we had and we're failing to meet? What is the brand adjective that we came up with that is not being evoked in our users' or in our own minds when we look at this?" That's where I'd go to from there.
Adam Stacoviak: Is there anything in this process that you have to get right? If you had to pick one... You suck at four, but the fifth one you've gotta get right. Is there one thing you have to get right, or is it like "If you don't get it all somewhat right - failed design"?
Erik Kennedy: Oh, stop... Someone's gonna quote me on this. [laughs] And I don't even know, I'm totally thinking on the fly here. I would say that if you only could master one skill - out of all the things we've talked about, like the layout-related stuff, the typography-related stuff, the color-related stuff, you can basically do with a super-simple layout and drop all the colors and just have a site that's typography. You can just have words on the page. If you can do that really well, then yeah, you can make it shine.
I don't think the same can be said of color, or I don't even think the same can necessarily be said of layout. If you're good at that layout, and that hierarchy, and attracting users' attention in exactly the right way, you may have a very usable site; you might have an app that no one files support requests, and everyone knows where the features are, and it just works really great for your app and for your users, but it seems tough to believe that if you haven't at least mastered some of color, typography that you're really gonna be able to knock it out of the park. So I think in that sense typography kind of stands alone.
Adam Stacoviak: The reason I wanted to ask you that question wasn't so much to get you a quotable moment - although I like that - it was more so to give someone that first step, because I don't disagree with you one little bit. I think that you're spot on. I think - and I'll allow the world to quote me as well, and if you're wrong then I'm wrong, so we'll be wrong together - and I do agree, if you can get just the most basic layout, left-aligned, there's nothing special about this design other than what [unintelligible 00:55:40.01] or common design tools default to you, but if you get things like headings, sizes, weights, italics, different elements in typography down pat, you can have a pretty good-looking site. And if you choose the right font, and all the other things you begin to hone and master over time, you don't have to worry about shapes, colors, or even icons - anything, besides the words on the page. That can deliver enough for you. That could be step one. And once you've gotten that, have enough feel-good to yourself to take that next step of saying "Hey, let me master the next thing."
Erik Kennedy: [00:56:26.11] Yeah. Well, alright, Adam, I'm gonna hedge you a little bit here...
Adam Stacoviak: Okay.
Erik Kennedy: ...because maybe that's what's necessary to kind of go from the good to the great, if you want a great site with just one skill... But I will be honest that most sites that beginners send me, most of their designs - whether they're apps or sites or whatever - a lot of times the bigger issue in going from bad or moderate to just okay/good is alignment. I think we seriously underestimate the degree to which the things we view as well-designed are incredibly aligned. All the elements on the page are basically gonna be aligned with at least one other element. Every single thing on the page. And this counts centering as a form of alignment. But I think that's one thing where -- maybe that's the thing that's really knocking things down into the Bad category easier than some of these other things, but typography... I still stand by that as being maybe the one where if you can master that, you can get something that's truly great, even without mastering the other skills. Yeah, so there we go...
Adam Stacoviak: We've been talking around a couple of the different things you've been doing to lead and teach design... You've got a pretty interesting course you've got going on - what is this course called? Is it called Learn UI Design? Is it that simple, Learn UI Design?
Erik Kennedy: That is the name of the course, Learn UI Design, at LearnUI.design. I try to keep it easy there.
Adam Stacoviak: It's on the nose. And actually, this all came from Jerod originally logging a color palette generator that you had put on the same website; it was pretty interesting, where you were able to get -- for the design-impaired, so to speak, to choose one color and then be able to get a whole host of colors from that. That's kind of where things began, but this course we learned about as sort of a follow-up e-mail, as a thanks from you to Jerod and us, saying "Hey, thanks for sharing this palette generator. By the way, I've got this course, and I'd love to share with you all some interesting tips for developers to get better design, tactical design advice, so to speak... But you go much deeper in this course. Can you tee that up, or what's that about?
Erik Kennedy: Yeah, for sure. Learn UI Design is a video course, it's got about 40 different lessons, 20 hours of content, and it's really just the full run of tactical design advice. It's the same sort of stuff that we've been talking about here, but in a format where you kind of watch over my shoulder as I design sample projects, or go through sample designs to talk about different concepts... All the fundamentals, things like alignment and spacing, there's a whole unit on color, a whole unit on typography, a unit on process... There's tons of stuff there, but it's basically for people who are maybe developers, UX designers, maybe graphic designers too, but someone who says "Yeah, it's gonna be worth my while to have UI design be this career skill of mine."
Maybe you're not necessarily looking to call yourself a designer, but you know that this is gonna be something that you just want to be able to do competently... And yeah, so all students get lifetime access, and that includes all the updates and stuff that I've been making.
There's also a student community, and a Slack channel, and I don't remember if I mentioned it, but there's a bunch of homework assignments, which is a pretty significant part of it... It's kind of just "do at your own pace", but they're really just a bunch of exercises to focus you in on mastering the skills that the different videos talk about. So it's the whole deal, yeah. LearnUI.design.
Adam Stacoviak: Are you grading that homework? Are you looking over this homework? Is it interactive?
Erik Kennedy: [01:00:09.21] Yeah, so I'm not grading it per se, but I am trying to give feedback to everyone who posts their homework assignments to the Slack channel...
Adam Stacoviak: Interesting...
Erik Kennedy: Or, I guess if you're afraid to do that, you can e-mail me, or whatever... But that's huge too, because in the real world, a lot more design happens post-feedback rather than pre-feedback, and I feel like almost everything we've been talking about is kind of pre-feedback stuff; it's like getting started on your project, just starting to pick the fonts, just starting to pick the colors. Once you get a little feedback on whatever it is that you're working on, often times it's like your ability to run with that is almost more critical than your ability to come up with something good in the first place... So I really value -- it's like, I'm not gonna grade students; they're submitting stuff, they're trying to learn this skill, huge props to them. I'm not gonna give you a D or an F or an A or whatever, but I will give you some feedback, and a lot of students will come back and rework the assignment, and the changes can be huge. I think that's where so much confidence is built. It's really cool.
Adam Stacoviak: You need that interactiveness, I think. That's why I asked you if that's how it was, because especially when it comes to design, if you give someone homework that is visual, then you should have some check to see that they're on the right track, and that way they don't take away what they assumed you meant, they take away what you really did mean, and they can be corrected.
Something else that occurred to me too as I was looking over your blog, your newsletter - which are well-produced, great content; I love your style of things - it occurred to me that there doesn't seem to be a particularly good on-ramp for up-and-coming UI designers. And as you'd mentioned, you may not make -- or this person or these people who take this course may not particularly wanna become a user interface designer, but simply add one more skillset to their expanding belt of skills, so to speak. It didn't seem like there was a good on-ramp, and maybe I'm wrong, and maybe you know this more since you're in it - would you agree with that? Is there any other pretty cut and dry "If you take this course, or if you read this book, you can come out with the fundamentals of being a good UI designer?"
Erik Kennedy: It's a really tough question... Honestly, a big part of why I created this course in the first place, and the blog, and then the same thing with the newsletter, it's like I just couldn't find something like that; I just couldn't find that tactical advice anywhere. So I really have tried to scratch my own itch with this one.
Adam Stacoviak: Well, even during this show you mentioned a couple times, maybe even from your own past, googling for things, or finding certain articles, and it almost seems like all the information out there is disparate and not consolidated to one area, or like "Here's a path from 0 to UI Hero" kind of a thing, that path... And it may not be the silver bullet of it, but almost to this conversation here - the fundamentals, color, typography, layout, process... If you get those things down and then you take your seven rules for creating gorgeous UI, like where light is coming from, beginning with black and white, doubling your white space, learning how to overlay text over images, and making text pop, and choosing (in your words) "only good fonts", and the last one, which we didn't even talk about, which might be a good show closer, is "Steal like an artist." Getting those things down will help you take that very next step to just adding either UI design as your title, and/or just your next skill to add to your belt.
Erik Kennedy: Yeah, exactly.
Adam Stacoviak: What do you think about this last part we really didn't cover much, "Steal like an artist."
Erik Kennedy: Steal like an artist, which that is a title that I stole from the name of a book called "Steal like an artist", so I guess that's appropriate...
Adam Stacoviak: Touché, right?
Erik Kennedy: [01:03:56.01] Yeah, yeah... All apologies -- I think Austen Kleon is the name of the author. But yeah, the whole point with that was - especially when I was just beginning with design, it just really struck me how much going and looking at what the best designers were doing, and then trying to imitate that, how much that helped. That was huge.
I'm certainly not in favor of lifting a design wholesale, but at some point, when you steal from enough places... Like, when you steal from ten sites that you love, that's no longer called theft, it's just creativity. That's how creativity works. And at this point I'm sure I'm "stealing" so to speak from other sites and things that I've seen, and that I may not even remember seeing... I just remember tucking it away in my memory as that being some good idea, "How I could use this font to do this", or "Hm, maybe if I do this with the color, it would work out nicely."
So I just really encourage beginners, to the point of like -- it's called copywork, and I wrote a piece for Smashing Magazine on it; if you just search for "Smashing Magazine copywork" it'll probably be the first thing that comes up... But it's just going and recreating a design that you really like and admire, pixel for pixel. So you just open up Sketch, or Figma, or Photoshop, or whatever you're using, and you just recreate that design in total, and that will teach you so many things if you try and imitate it perfect. If you try and use exactly the same fonts, and exactly the same positions, with exactly the same letter spacing and sizing and whatever, you're gonna learn all these things that the designer is doing that you never would have thought of... And I give some examples in the article, too.
But maybe that's a bit odd to recommend, because it seems so much like plagiarism, and obviously what I'm saying is not "Put this in your portfolio", but instead--
Adam Stacoviak: Use it as an exercise, not as the final product.
Erik Kennedy: Yeah, exactly. Look at what's out there that's so, so good, because you can make leaps and bounds towards that faster than you think.
Adam Stacoviak: Back to the Learn UI Design course - it's been around for a couple years now; this is the first I've heard of it, so that's a bummer... So now, listeners, you've heard about it, too... I think it's not even open now; it re-opens sometime soon. What's the scenario here? Why did you choose this kind of launch pattern?
Erik Kennedy: Sure, yeah. So I've typically launched it every few months, and what I'm doing in between the launches is just making changes, making updates... But this is nice, it definitely builds some amount of excitement; it gets all the new students synced up at where they are in the homework. If you start the course soon after enrolling, then you'll be going through, say, the color unit at the same time as many other students, and you'll be able to very quickly and easily get feedback and give feedback on the assignment that you did last week, or whatever.
It's also nice for me to batch a lot of that customer support stuff, because I do try and maintain client work, and do a bunch of other things as well.
Adam Stacoviak: Gotcha. That's an interesting pattern to do. It gives you time to really be present and aware with your students.
Erik Kennedy: Yes. It definitely adds a whole seasonality to my career now, which I kind of appreciate, too... It's like, "Oh, launch time is coming up", there's this excitement, I'm getting more e-mails about it...
Adam Stacoviak: Right, yeah...
Erik Kennedy: And then there's this big batch of new students, and there's tons more excitement. Then things start to peter out and I get a little more other work done, and then it starts over. But yeah, the next enrollment period starts on February 13th, so look for that.
Adam Stacoviak: Good deal, I love it. I think as people question "It's 2019, how do I begin learning UI design?" LearnUI.design is a great place to begin. Your blog is full of knowledge; we've covered some of it here in this show today... You've got a newsletter - is this a weekly newsletter? How frequent is this?
Erik Kennedy: [01:07:48.00] It's not a weekly newsletter. I don't even know if I could do that. The way the newsletter works is -- yeah, by no means do I assume that someone's gonna just wanna sign up out of the blue for this UI course... I really wanna put out a lot of good, free advice on UI, that people can use, that they find useful, and say "Okay, cool, what else does this guy have? What else does he have to say?" and the newsletter and the blog are really those two things.
The blog has a whole series of different topics, articles on color, typography, process, and so on; a lot of the stuff we've covered here. Then the newsletter - when you first sign up, you're gonna get a couple of best-of posts, including one on alignment; I think you get that one the day after you sign up. So that one is really worth reading, in my opinion. But you'll get this kind of best-of sequence, and then when that runs out, it's basically however often I'm updating the list.
I try and send something about once a month, but I'd really rather send out something that is long and in-depth and super-tactical. People write me back, saying "Hey, that was awesome. I used this today, and it made my designs better." I'd rather do that once every two months, than send out something once every week that's just short and pithy and not as practical, or whatever.
I really do try and take care to make it be the sort of newsletter where people say "Wow! I don't like newsletters, but I like getting this, because when I see your name in my inbox, I know something good is gonna be in this e-mail."
Adam Stacoviak: They get excited, they're like "Ooh, new design tip. Let me try this out, let me examine this and swing this into my next visual project." I like that. I was reading over a couple of the quotes here, and the one at the -- which one was it...? Bummer! Oh yeah, "It's possibly the best newsletter I received since 1999." [laughter] I don't know how often that person is getting e-mailing, or whatever, but... You might have even made this up, because it's just the first name; you didn't put the last name here, so you could be making these up...
Erik Kennedy: Oh no, it's all real. And there's more, too.
Adam Stacoviak: I'm just kidding with you, I know you're not doing that... But I think that's why I asked about the frequency, because when you ask somebody "Hey, give me your e-mail. I promise to send you a newsletter", my preference personally is I wanna tell them, I wanna promise them the frequency. That way they know the expectation, and then that way it gives us something to deliver on... And that way it's clear; it's like, "Hey, I agree. Let me give you my e-mail. Sign me up, send me a weekly tip", or something like that, or whatever the frequency is. That's why I wanted to ask you that.
Erik Kennedy: Yeah, that makes sense. I make far fewer promises about the frequency. I really try and have the only promise be "It's gonna be good. If you really wanna get better at design, you'll wanna open every e-mail." That's what I go for.
Adam Stacoviak: Good deal. Erik, in closing, is there any advice you wanna share, any closing thoughts to share with the listening audience before we tail off?
Erik Kennedy: Oh, man... I mean, just kind of the same stuff that I've repeated - if design has seemed so inaccessible to you, try and view it as something that you can analyze your way to a better design, and try and think about what else is going on there, in the sites and the apps that you like... Because it's so possible. It worked for me; I can do it, and you can do it, too. That's all.
Adam Stacoviak: Good deal. Erik, thank you so much for your time, man. I appreciate you sharing so much wisdom with us. It was good.
Erik Kennedy: Thanks for having me, Adam.