 All right, I'll go ahead and get started now. So hello, I am Josh Riggs. I am the lead user experience designer at ThinkShelp in Portland, Oregon. Just a shameless plug, we are hiring in Portland an additional user experience designer. So if you're a designer either in Portland or willing to relocate to Portland, come see me. I'd love to talk. Of course, you can follow me on Twitter and pretty much everywhere else on the interwebs at Josh Riggs. So I'm going to talk about ballin' on a budget or how to create great design at nearly any cost. First, just introduce myself a little bit. I'm originally from the Swamplands of Orlando, Florida. In 2013, my wife and I decided that we wanted to move to Portland, so we literally drove across the country in five days with our dog and a trunk full of stuff and I don't recommend anybody do that in the middle of July. It was a little rough. But we've been loving it ever since. I love hiking and adventuring and photography. And just a quick background. My specialty is UX and visual design for responsive websites, typically on large content, or typically large content managed websites. The last couple of years I've worked on responsive redesigns for Grammy.com, Sci-Fi, Bravo, Nike Foundation, and currently Southern Poverty Law Center. And yes, so I'm a UX designer at ThinkShout. Actually, I am the UX designer, which means I wear a lot of hats. I don't currently have any other designers that I work with, so I'm responsible for basically how things look and how people interact with them on every single project we do at ThinkShout. Despite all of that, my job description is pretty simple. I take abstract ideas and I create something that humans can use. I take content strategy docs and business goals, and I use those to create user interfaces. Really, on any given day, I can be sketching UI concepts. I can be creating wireframes or creating visual designs like style tiles or page comps, or I can be building a prototype. This is all pretty standard design-ery stuff. Working at ThinkShout has a bit of a twist. And that twist is we work almost exclusively with nonprofits who really have to watch their budgets carefully. Nonprofits typically have smaller budgets than private sector clients, although not always. But the difference is they're typically under a lot of pressure to keep tabs on their spending. By law, they have to report very carefully what they spend their money on. So that means we as a company need to make sure that the things that we build and the amount of time that we put into it match what we say. So that's what I want to talk about designing on a budget. So here's what I'm going to cover. First, I want to talk about, well, why should we talk about money? What does it have to do with the work that we do? Secondly, I want to talk about ideas and the fact that ideas are free. Kind of the meat and potatoes of the presentation is going to be budget killers and how to avoid them. And I'll get into some specifics here. And then finally, I want to end with some final thoughts and some resources to help you out. Okay, so why should we talk about money? Well, I recently realized that for the majority of my design career, working for both for-profits and non-profits, working both in-house and at agencies, I've been battling the budget. I've worked on project after project that I've either had limited resources, maybe limited time, really tight budgets, or all three. I think over time I've gotten pretty good at both creating good design within these budget constraints as well as managing my expectations and clients' expectations. So let's talk about comparison. As designers, comparison is part of our pretty much everyday working life. We compare our work to what others do constantly, and our clients also do that. They compare our work to other work that we do, and they compare our work to other great things that they see out on the Internet. And comparison can be a major driver in our design decisions. How many of you, just a quick show of hands, have designed something because you saw something similar that was cool? That's everyone. But when we compare, we're placing really high expectations on ourselves, sometimes unreasonable expectations. And the same with clients. It also places high expectations on us. Sometimes we need a reality check. I think all of us tend to underestimate just how much work and time and resources go into the best products and websites that we see out there. So let's look at some examples. This is the Apple Mac Pro website. Is everybody familiar with this guy? Apple is a design leader. We all know that. Designers everywhere, as well as clients, tend to look to Apple for inspiration. How many of you have had clients do something that Apple would do or say they want to feature like they saw on Apple's website? Yeah. So this screenshot, like I said, of the Mac Pro website, is pretty awesome. It's got all kinds of HTML5 and CSS magic. You basically scroll through the site and there's all these crazy animations of beautiful products. By the time you're done scrolling through, you're ready to cash in your 401K to buy like an $8,000 computer. I know some folks who are involved with this project and here's some numbers they gave me. 4,000 hours, rebuilt three times and no set budget. That's also not including, I imagine, however many billions of dollars they spent on R&D, on designing and building this beautiful product, plus probably, I would imagine, a couple million on their photography resources. To do in the math at think-shouts rates, that's about $700,000 for a microsite. Does anybody in here have a client that's willing to pay $700,000 for a microsite? No. So of course this site's freaking amazing. There's another example. I'm a really big fan of Google's recent design renaissance. I have a Nexus 5. I love it. I switched from iPhone. I might switch back, but I really like, I really, really like material design. And there's a lot of really cool details. There's fun animations. It's just a really great design language. If you do a quick job search for user experience and design at Google, they have between 50 and 60 job openings. So it's three times the entire size of our team at think-shout. We have about 20 people right now. So of course they're going to have time and budget to spend on extremely detailed UI components and animation. One last comparison that's a little bit closer to my specialty. Most of our clients know of Charity Water. Charity Water is considered a leader in design and strategy in the nonprofit field. And their products are great. I personally aspire to design things that are at the same quality as Charity Water. But here's the catch. Charity Water has 11, 10 to 11, depending on when you look at their website, full-time employees in the area of front-end design and strategy. They have VP of creative. They have senior graphic designer, senior product designer, UI designer, production designer, videographer, copywriter, content strategist, and two front-end engineers. And then who knows if they also have contract workers or people that they sub-workout to. That's a lot of talented people working on one brand. By comparison, think-shout has one designer, which is me. We have one content strategist, which is Brett. And we have one and a half front-end devs. We have one awesome dedicated front-end developer. And then we have a guy who splits his time between front-end and back-end. That's kind of unfair for us to compare our resources to theirs. At the same time, when clients come to us, they want that quality of work, so we need to find a way to give it to them. So the point of all this comparison is showing that great design costs time and resources. What if we're short on both? If that's the case, then we need to ask ourselves this. If time equals money, how can we work more efficiently and make the best of what we do have? So one thing that we do have that doesn't cost any money is ideas. Good ideas aren't things that we should be skimping on to meet budget requirements. There's no hours or price tag attached to an idea. Anybody here in this room can create the same great ideas that big boys like Facebook and Google, people with unlimited wallets, you're just as smart as people that work there. So I picked up photography about seven years ago, but it wasn't until I read a book by a Canadian photographer named David Doucheman called, Within the Frame, that I really started to grow as a photographer. The subtitle of the book is called The Journey of Photographic Vision, and the mantra of the book, which he repeats over and over again, is gear is good, vision is better. And what David's saying is that technical things like camera gear, this is hardware, software, all the stuff that people like to spend money on, they don't matter as much as having a good solid photographic vision. For example, Ansel Adams got his start, he shot film, and he had a fixed lens, and he had one camera, and he shot some of the most amazing work in history. People that spend thousands and thousands of dollars on camera gear may not necessarily take the same photos as he does. So a photographer can know every single detail about their camera and have the best lenses in the world, but if they don't have a solid photographic vision, those photos are going to not be interesting. So reading this book kind of blew my mind, and I started applying this philosophy not only to my photography, which coincidentally got better, but I also applied it to my design work, and I think it made me a better designer. So what does that have to do with budget? Having a solid design vision will help you keep things in perspective, and keeping things in perspective will help you stay, really help you stay on track with time and budget, and this isn't something that you necessarily have to share with your clients. You don't have to create a formal design vision and then have clients sign off on it. It's more of just something to create for yourself and think of it as a start of sale you're shipped by. So let's kind of shift gears and talk about some quick investments that pay back simply by using your good design skills. For me, I think that the core of good design, that all the good products that we see out there, that's not really attached to money. That's attached to personal skill of a designer, and I think these basic skills are what separate the best products from everything else out there. For me, two of those best quick investments that we can make in our designs are good typography and good simple image editing. So there's lots of free and cheap fonts out there. That's not what I'm here to talk about. For me, it's more about how you use your typography. Good typography creates a high end and elegant feel. Using things like proper line height and letting makes reading easy. And hierarchy of text, headings, body copy, quotes, et cetera. These are going to effortlessly lead users that are still getting over the pantheon party last night. Effortlessly lead users where you want them to go. It's a tongue twister. Here's an example. So medium.com I think is a great example of good simple web typography. So on the left is a basic blog post on medium.com. The right is a basic blog post from kenrockwell.com. The person who laughed, I'm sure, is a photographer. If you want to be entertained, I would suggest reading kenrockwell.com. He's kind of a curmudgeon. Anyway, they're both made of exactly the same elements. White background, text, and a few images here and there. But as you can see, the post on medium.com looks way more professional and higher end simply because of better typography design. It looks like they spent a lot more time. Maybe they did, but just by using better type. Secondly, simple image editing. One of my personal biggest pet peeves is seeing great looking sites that use images that haven't been treated in any way. I see it all the time. It really just takes a few seconds to treat the contrast and color intensity. You can do this in Photoshop. You can do it in Sketch, Lightroom. But it just makes all the difference in the world to me. Here's an example of a client website that I modified for this presentation. The live site doesn't use that image, but the hero image is one that I took on vacation in Zion National Park last year, and it's pretty much straight out of the camera. A lot of our clients either rely on stock photos or photos that they took themselves, and most of them aren't savvy enough to edit their own photos. So this example isn't too far from the truth. As you can see, it looks really flat, and it kind of sucks the life out of the whole design. So in this example, same photo. I just took a few seconds to treat the color and enhance the contrast a little bit, and for me, it kind of breathes life back into the design. There's warmer colors, there's more contrast, and I spent about two minutes doing this. So for me, the investment of the extra two minutes to edit this photo was well worth it. So the thing is, I know you're all awesome. You're all great creative professionals here. I don't need to tell you the benefit of good type and photos. So what I am trying to say is that if you find yourself short on time, refocus your remaining resources on the basics of type and imagery. All right, so now I want to talk about budget killers and how to avoid them. So as I said earlier, good creative ideas are free, but the catch is implementing those ideas can be expensive. For me, one thing that separates a junior designer from a senior designer or a director is the knowledge of how your work affects everyone else in your ecosystem. Do you really know what it's going to take to build and implement what you've designed? Just by show of hands, how many people think that they have a really good understanding of how their design affects everybody else in the project? I like seeing that. How many of you have ever gotten, say, are there any front-end developers or developers in here? How many of you have gotten work from someone that you think had no idea how their work affected the project? I'm as a designer, I'm trying to help in that. So I've made a lot of mistakes and missteps in my 10-year career as a designer, and lucky for you, I'm going to share that with you. It's forced me to learn a lot about the consequences of my ideas and actions. So there's four breeds of budget killers that I've found in my own experience. Technical underestimation, inconsistencies in design, misguided design deliverables, and bad communication. Technical underestimation, this is something I've been guilty of many, many times. I'm getting a lot better at it. And I don't expect any designer in here to be an expert developer, but we need to know how our designs impact the development process. If we don't have a clear understanding of what it takes to build what we designed, bad things are going to happen. It's kind of like punching your developers and your budget in the face repeatedly. So an example that I see a lot, and I saw it a lot more when I was doing some consulting, was a lack of understanding and source order and responsive design. I worked on a project last year for a large TV network where they had a really awesome in-house creative design team, but they didn't understand source order. So as they were designing things to be implemented, they were moving bits and pieces around, like the mobile design might have a different order than what was in the desktop design. Well, I guess I should back up. Does everybody know what source order means? Cool. It's basically a fancy term for the order in which the bits of any HTML page are rendered from top to bottom with responsive design. Of course, we need to make sure that our source order stays the same. So kind of talking about the example from before, this is one of our projects at ThinkShout, a hypothetical example. Left is a desktop mock-up and the right is a mobile mock-up. They both have the same four sections, hero image, intro section about us, and the stories of success section and a new section. If you look closely, you'll see that the source order's changed. So this is one of those things where, yes, there's technically a way, like if it was mandated that you had to do it this way, you could do it in Drupal, say with panels, or you could probably find some JavaScript way to do that. But the issue is if you do this on scale over the course of a very large website, this is going to be a lot of time that's being eaten up, either going back and forth with developers and designers to say, oh, no, actually you can't design it this way, we need to change it around, or maybe your designer actually showed it to a client and it was approved that way, and now as a developer you have to find a way to make it happen. Neither one of those situations is a good situation. Solution is pretty simple. Make sure your source order doesn't change with your responsive layouts. In this example, both mobile and desktop mockups have a matching source order, and for me, the overall design in UX hasn't been compromised one bit. Here's another example, and that's know your CMS or platform. I know we're all very much Drupal folks, but sometimes we work with designers who maybe don't necessarily have experience with Drupal, but it's okay to talk to them and kind of give them a primer on it, and I think we all know that Drupal has its quirks. It's back to Medium.com. Currently it's really popular for blogs and articles to have a big header with an H1 title and maybe a subtitle on top of a full-width image. Does anybody use that on a project, on a design? Yeah. So the problem is if you're a developer in here, you probably already know this. Drupal likes to output the title of the article inside the content of the article by default. So as you can see here, the design breaks that default output by removing the H1 and H2 elements from the article and placing it in the header region. Of course, we can make Drupal do this. We see it all the time, but the important thing is, as a designer, know that the things that you're making have to step outside kind of Drupal's defaults and know that it's going to take some extra theming time to do this. And also know that on the scale of a large project, if you're doing several things that kind of push the limits, that's going to affect the overall theming time and it's going to add up. So the solution is, as designers, talk to your developers. What I mean here is that you should try to keep an open line of communication with the people who will be building your design. Too many times, we're in silos and designers and developers never talk to each other, and that's just a really bad idea. When you're in the early part of a design phase, run your ideas by developers. They'll be able to tell you pretty quickly whether or not your idea is feasible or if it's going to cause too much complexity. Something I ask developers a lot is if I'm not sure about an idea or concept, I'll say this. A scale of 1 to 10, how difficult is this going to be to build? If it's any higher than a 5, I change my idea. It's much easier for me to change my idea than it is to implement something that's much more complex than was originally estimated. You guys have probably already seen this, but Martin Golding said, if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. I've modified this a bit to apply to designers. I say always design is if the guy who ends up coding your designs, or Gal, will be a violent psychopath who knows where your desk is. If you do this, you will save on budget and you might live longer. Okay, so inconsistency. This is kind of like a swarm of angry Ds who slowly devour the budget. I tried to think of an analogy here that really captured the concept of slow annoyances and time sucks that are really painful, because that's what design consistencies are to everyone. So an example here, something I've seen a lot, are thumbnail sizes. So of course Drupal has a feature that allows you to auto crop images. It's really great because it means clients don't have to use Photoshop to crop images. So here's an example of a wireframe for a project that we did. And it looks fun. But if you'll notice, there are three different types of aspect ratios on the images. There's 16 by 9, there's really wide, and then there's one by one or square. So of course this makes sense from a design hierarchy perspective. If you're looking at the page, you can see that the hierarchy is most important thing at the top, second to most important things in the middle, and then everything else. However, because this is all the same content type, this is all a blog or news item, yet we now have three aspect ratios. That's going to be more time and effort that is going to need to be done in theming. So while you could tell your developer, or if you are the developer, you could spend a whole bunch of extra time making this happen, the easier solution would be just to make all those images 16 by 9. For me, I don't think that the example on the right that has all the images in a 16 by 9 aspect ratio, I don't think that that loses any impact. I don't think it's a worse design than the other one, I think it's fine. So anyway, the solution is be consistent. Try to be mindful of all of the components that you're designing, and try to think of it as reusable parts, and the more reusable parts that you have, the easier it is to implement. Also, always allow yourself time to look at your work with a critical eye, or better yet, add some peer review into your design process. If you're like me and you're the only designer, I'm sure you can find somebody in your office or somebody that you know to just take a second look at your work. For me, many times it's really hard to notice inconsistencies when I've been staring at the screen like so close, but if I step back a little bit, or if I send it off to somebody else to take a look, as soon as they come back with something, I'll say, oh yeah, that's right, I remember that. So anyway, misguided design deliverables, or as I see it, how to burn yourself out and torch your budget. So the examples we talked about before are kind of things that impact developers, whereas these examples are more things that impact yourself. And this topic can be anything from designing the wrong things, creating too many designs, not creating enough designs, or jumping into designs way too quickly. So one thing that I've learned is that design deliverables have to make both clients and developers happy. This is not an easy task. It can be really difficult balancing the needs of developers, the needs of clients, as well as the needs of users. We want to make sure that clients have everything they need to approve things, to sign off on things, and to contribute, to make sure that their voice is being heard and that their vision is being met. But we also need to make sure that they have everything they need so that they don't have to constantly come ask questions. For example, a lot of clients want to see every possible page, an interaction mocked up in high fidelity, every break point, multiple variations. This is, of course, doable. But that's very different from the needs of developers. Developers oftentimes would love to have an HTML and SAS component style guide. That would make their job a lot easier. If you show a style guide to a client, most of them don't understand that. And that's fine, that's perfectly acceptable. But I guess my point is that we have to meet somewhere in the middle. Also, different clients require different deliverables. We need to accept and embrace this instead of trying to shoehorn one process for all clients. Some clients are more technical and web savvy. You may be able to get away with showing them one or two page comps in a component style guide. You may be able to get away with more of an iterative design approach to where you show a few small things at a time and over time you've got a lot to show. Other clients are really, really literal. They need to see a lot of mockups and wireframes before approving things. So it's okay to customize this process and customize your deliverables for each client. I think it's necessary. But I think you need to plan for that. For me, process is more important than deliverables. As long as we have a consistent process of problem solving, then we can customize deliverables as needed. How we think is much more important than the tools we use to create. So at ThinkShop, our deliverables vary a lot based on our clients and our budgets. We always create wireframes of some sort. Sometimes I'll do fully responsive and sometimes I'll make static wireframes using Sketch. Then I'll upload them to Envision which is a web app for, I've got a thumbs up there. It's a really awesome web app. I'm kind of an unofficial evangelist for Envision. And you can make your static mockups clickable and interactive. But anyway, we always create style, tiles and visual designs. Design mockups, excuse me. Sometimes I design in the browser. Other times I use Sketch or Photoshop. Not so much Photoshop anymore, mostly for older projects. But anyway, deciding which tools to use to create wireframes and visual designs really depends on the budget and the timeline. As well as our own personal internal resources. So if I'm working on a smaller project and there's no budget for a front-end developer, maybe I'll design everything in the browser and I'll be the front-end developer. If it's a larger project and we have, say, one or two of our front-end developers working on it, then maybe I'll focus specifically on UX and visual design. On the other hand, our design process is always the same. Our process is actually pretty simple. We start broad and we work down to the details. We experiment with style tiles before we create any high-fidelity visual mockups. I sketch before I code any prototypes. I don't mean the application sketch, I mean like hand sketching. I need to know what I'm going to build a prototype of before I start building it. From there, we turn the client's business goals and content into something a human can use on a variety of devices. So the solution to misguided design deliverables is focus on objectives and not specific design deliverables. Create a plan before starting. Write down your plan so you can check back. Write down how many wireframes you want to do, of what interactions. Write down what your objectives are and what you plan to get accomplished. How many steps do you think you're going to need to get from a nebulous idea to a finished set of wireframes? What all do you need to wireframe those things? So finally, bad communication. This can be like a Betty White mounted wrecking ball to your budget. Every single project I've worked on, big or small, communication has been the deciding factor of success or failure. It has not been did I design in Photoshop versus designing in the browser. It's also been the main reason why a project comes in under or over budget. So why does bad communication cost us? It's simple. Assumptions cost money. Assuming something is easy to build when it's not will cost you money. Assuming the client wants something or wants one thing when they want something else that will cost you money. Or something that I get a lot is assuming you can come back later to rework something or to design or fix something. Part of a good design process is to remove assumptions. When we don't communicate, problems snowball. A little assumption in the beginning of a project can lead to really, really big delays or hot fixes once we're knee deep in development. As we all know, it's a lot easier to change a wireframe than it is to change a feature in a deployed website. So a typical web design project looks a bit like this. Strategy, UX and visual design and development all happen in large blocks of time one after another. In between these phases, there are massive walls and we kind of throw our deliverables over. Strategy throws a doc to the designers and says here's how to design. And then the designer goes away and does their thing and throws all their work over the wall to the developers and then developers make it happen. That's not a good thing to do. Besides being a really bad environment for creating a great product, the biggest problem with this kind of work environment is that it allows no room for us to iterate and solve problems as they arise. How many of you have worked on projects to where what you thought the solution was going to be in the beginning ended up being way different from what the actual solution was? Yes, because these things evolve over time. They're almost like living creatures. So when we're dealing with really complex content-managed websites it can take weeks or months to really get clarity on things. Sometimes you have to actually get in there to really understand what you're doing. No matter how thorough we are with UX and design, there's always going to be something that comes up in the development phase that needs our attention. Sometimes clients need change. That happens. It's a fact of life. Sometimes we just didn't consider what we wanted to do. Sometimes it also happens. It doesn't mean that we're not good at our jobs or that we didn't do as much work as we can. It just means that there was a black swan. Or sometimes we're wrong. So for example, if we look at a typical design phase of a project it can be front-loaded happening just after a strategy phase but just before development and engineering. So let's say it on this hypothetical project it's allotted for visual design. If all these hours are used up at the front-loaded design phase and they likely will be what happens if and when something comes up later on that needs design thinking. Then we have to go back to the client and ask for more money. Or we have to take it home and do it on a weekend and don't tell anybody about it. A better process would be to remove those walls we talked about earlier. We rearrange our timeline so that design, strategy, and development are happening at least somewhat simultaneously and everyone is communicating with each other along the way. There's far less room for assumptions and miscommunications to come up. I know this isn't possible for everybody. You can't just go into your office or go into your company and say I want to completely change how we're doing our development and strategy. But you can at least start planning to save some of your design hours for the development and implementation phase of the project. We always, at Think Shout, spread our hours out for design over the entire course of the project so that if something comes up at the end that needs design thinking. The solution to bad communication is really a very simple solution that's be in constant communications with engineers, PM's, and clients. Don't be afraid to ask for clarity and if you have to move your desk to sit next to an engineer. Honestly, that's how I've learned all of my various HTML, CSS, SAS skills is by sitting next to engineers and asking questions. I think not enough people. I think a lot of people are afraid to ask questions because maybe they feel like it might make them look like they're doing or it might be annoying. But that's probably the most important thing that's made me successful in my career is being able to ask questions. Okay, so just some final thoughts and time savers. So let go of pixel perfection. I struggled with this for a while, but I'm kind of a recovering pixel perfection addict. I just pushed myself to get over it. Wireframes, prototypes can be ugly. That's okay. We want them to be ugly. Obsessing over pixels and responsive design is pretty much futile. And finally, there's kind of the old average of shipped is better than perfect. This is kind of an important one and that's beware of the framework. Zurb Foundation bootstrap can look like these great, shiny things that will help you. They're like the white knight that comes in from the time in the budget. And they're great to get prototypes up really, really quickly. But they also typically include a lot of stuff you don't need. They're great for using out of the box, but as soon as you need to change something and kind of personalize something to work a little bit different than how bootstrap or foundation works, it might take you a really long time to do that. And they can also be a nightmare to use because Drupal's markup is Drupal's markup and takes a lot of wrangling to make it work, and it's different from bootstrap or different from foundation. So I recommend if you're going to use a framework, use it for prototyping only, knowing that those prototypes are going to be quick and then you're going to throw them out. This is a big one for me. Stay inspired and knowledgeable. And what I mean is that set aside some non-billable time to keep up with trends and inspiration. You know, if you wait until you start a project to spend like an hour or two researching new ideas or researching interesting things, that's going to add up. So that's two to three hours that you could have used for design QA or you could have used for extra animations or something like that. So be proactive and do your research beforehand. One thing that's really cool is called the Chrome Panda plugin. It's basically a feed for designer news sidebar.io and dribble, and it shows up when you open a new tab in Chrome. The benefit is that it's essentially inspiration right in your face all day. Every time you open up a new tab, you see the most popular dribble posts and you see some great articles. Just some fair warning, it can be a bit of a rabbit hole if you have to kind of make sure that you don't spend much time reading some of the articles, but it is a good way to constantly see new designs, new colors, and just keep those things fresh in your mind. Another thing that I like to do is daily exercises. Your design skills are like muscles, they need to be exercised. Daily exercises are a really great way to keep your skills sharp so you can work faster. I'm a really, really shitty illustrator. Last year, I committed myself to creating one illustration per day based on a theme with the intention of knowing that I'm a really bad illustrator but I want to start getting better at it. After a few weeks, I kind of started to get into a groove and then one of the projects that I was working on actually had a chance for me to do some illustration on it and it took me a lot less time to do those illustrations than had I not been spending half an hour to an hour a day and this doesn't have to be just illustration, you can do daily code pins or maybe a daily treehouse lesson but again the idea is if you're training for a marathon you start out by running short distances and then by the time the actual marathon comes up you're ready to do it. You don't just wait until the day of the marathon and start running and hope for the best. Finally, sketch. Again, not the application sketch but the active sketching. Sketching ideas quickly before jumping into code or jumping into Photoshop saves you a lot of time. You can show quick sketches to your clients, most clients, not all of them but most of them, or to your team to get immediate feedback. It can, showing a sketched idea that maybe took you a couple minutes to get out if it was the wrong direction. That saves you much more time knowing that than you spend a lot of time on a wireframe or a mock-up and then finding out that it's not the right way to go. You can even make your sketches interactive using InVision. Finally, let's talk about free stuff. Save money by not buying shit. So we all love fonts. There's a ton of really good high quality fonts out there. My personal favorite sources are Google Fonts. When it first started they were pretty crappy but they were interesting and some good designers and good typefaces. League of Moveable Type is another one of my favorites. That's more for headline typefaces. Not a whole lot of good body typefaces. And also Lost Type and Font Squirrel. You will see a lot of the same typefaces on those three websites. And then Font Squirrel is great because you can upload a font and create a CSS as long as you have an OTF or a TTF font, you can create the whole package there. Some good resources for free photos are a little bit harder to find, especially for specific subjects but they are out there. Some of my personal favorites are the stocks.im which is an aggregator of several other Tumblr blogs as well as Unsplash and Death to the Stock photo. Just one warning is they can get a lot of lens flares and shots of coffee and stuff like that. But if you scroll through the hipster stuff I say hipster lovingly because a lot of people think I'm a hipster but whatever. You can get some pretty good stuff. It may be harder to find very specific things like photos of kids. There's almost no photos of kids on there. But you can typically find something good. This is an example of the stocks.im. Like I said, it's an aggregator of several free stock photo sites. And finally, code snippets are great. They're a lifesaver if you're building responsive prototypes with HTML. They're also a really great way to get interaction, design, inspiration. And best of all, they're 100% free to use. And what I mean by that is like code drops or code pen. Is everybody familiar with code pen? Yeah. Code pen, so it's a great way to create simple snippets that you can show other people. But it's also a really good way. They have a whole pattern library that you can browse through. Let's say you have a problem of designing a responsive navigation with two sub-levels of navigation and you want to see how it's done, go to code pen and search for it and I guarantee someone's probably done it before and they'll be able to see what you want to do. And then also bourbon refills. So we use the bourbon suite a lot for prototyping. For those who don't know, bourbon is similar to compass. It's a SAS library. They also have a grid system and then they have what's called bourbon refills. And refills is a component library. Of course, it runs on bourbon. And the best part is that you can easily copy and paste HTML, SAS, and JavaScript separately. I don't know if you can see it here, but you've got the little copy buttons for your HTML and for your SAS. And if there is JavaScript, you can copy that as well. So this is a really great, really easy way to say in this example that's just a card design. So if I wanted that in my prototype, go to the site, grab that code, modify it a little bit, and then it's right there. I'm a big fan of bourbon refills. So, I want to end with some food porn. Here's some Jamaican oxtail stew, some Italian meatballs, and some chanam masala for the vegetarians out there. All of these delicious dishes come from the same humble roots. Poor folks who had to make the best of what they could. The best of the few ingredients that they had, whether it be some off-cuts of meat that were really tough, a few vegetables, some herbs and spices, and a lot of creativity, technique and love. You put those things together and you have something amazing. When it comes to designing on the budget, we can choose to see it positively. We can choose to be creative about our budget constraints, and we can choose to use them to our advantage. Creativity is born out of necessity and constraints are just needs. It says somebody on the internet. Thank you. Turn it up for questions, but first I want to take a photo. Does anybody have any questions? Come up to the mic, please, so we can get it recorded. Back to your point about source order. So I assume you would also allow that if in fact the use case is different for a mobile device, and the content prioritization is therefore different, then it's okay to re-sort things around. My point with that was just knowing that your choices have consequences over the entire project. If you have a few use cases here where it's knowing that this particular component really needs to be in a different place for mobile, but you plan for that, that's one thing, versus having to spend a whole lot of time going back and forth with your development team or with your project managers or all the above, and you're also doing that. You're logging your time to that that's really going to add up. Hi, I have kind of like a three-parter, but each one's like quick questions. First one, I noticed when you had your design prototypes, you had the normal one or like widescreen and mobile. What do you prefer to design for mobile first? I mean like specifically as far as design, or do you like to still kind of go normal widescreen and then go from there at the same time. That's a good question. It can vary from project to project, so I typically like to design interactions like wireframes, mobile first, just because I mean that's the way to do it. You know, we're seeing such a big shift to mobile devices, like when I was talking about that, we know that. However, we do have some clients that are, we have some very specific use cases. We've had some clients that we're building a project specifically as a tool for people on desktop and the edge case may be that people are using mobile versus using mobile in the edge case as people are using desktop. So we are open to kind of changing how we do that. I will say that I tend to, once I've created wireframes and created kind of the interaction design, a lot of times I'll start visual design wide screen because you typically have a big picture kind of thing. Yeah, you typically have more complex layouts and more kind of bits and pieces on the screen at the same time that you need to account for, whereas you know, mobile is just typically a more simple experience. Okay, thank you. Now, I'm no longer the web designer at my company, the marketing department is finally caught up from print so they actually understand a little bit but I still always get my mock-ups in Photoshop and it's pretty much like the whole design and it kind of, the idea is to try and get it pretty much pixel perfect and they are pretty tolerant even though I can usually get it pixel perfect but Did you say they are or are not pretty tolerant? They are tolerant of it. They can always be perfect but any advice on in a situation like that to kind of help out what I could ask them to maybe understand that it's not always a Photoshop mock-up being like the best possible way to start maybe start thinking about style tile type things. Sure. Since you brought up the style ties I just want to kind of clarify that at least my impression what I use style tiles are more for experimenting with design direction versus a deliverable for developers style tiles are more something for clients to like pick a direction they want to go to so we don't have to go through rounds and rounds of comps versus something that you give a developer and say, you know, go for it. So advice I would give for that would be most designers that I've worked with are very open-minded to like to learn new things so they may not be aware that they may think that what they're doing is what you need because it's what the clients probably needing and so they may be unaware that they're not getting enough information from you so I would say first and foremost try to set up a lunch meeting or go somewhere and get a beer and kind of show examples and explain what you're doing and hopefully if this is a reasonable person they'll be happy to work with you and maybe they'll be willing to start designing in the browser or start learning as much about responsive design as they can or maybe also have to consider that the knowledge that you have is also years and years worth of knowledge and trying to get somebody up to speed with that much knowledge might be difficult so maybe you have to give them some parameters to work in like saying these are the things that I need I don't just need a comp I need to know what these different states are or whatever talk to this person and show examples of what you need so we all have clients that just have low budget and they can realistically only afford like two mock-ups like the home page a basic page or maybe like their feature specific content type so how do you go about communicating this is holistically what the design is going to look and feel like or how do you instill confidence in them in your designs when you can only realistically deliver just a few pieces of design to them that's where I think having really comprehensive wireframes helps so you can go to and say here's your wireframes here's if you go through the do you go through the style tile process or more of a lighter weight process of picking an art direction um I typically do just a lot of sketching like a mofo with wireframes and then I delve a little bit into style tiles and kind of designing components in Photoshop or sketch gotcha what I've found is that if you tend to um if you tend to if you involve them in the process of picking an art direction but doing that in a lightweight way like with style tiles and then you show them the next step of a few mockups by the time they've seen the wireframes plus that design experimentation in style tiles plus a few mockups when you go and say okay now we've what we have left to do is design the rest of the components on the site so in my case I'll go through the wireframes and just do like one document I'm not doing it in the browser I'll do like one sketch file that has all the buttons and type and you know header design whatever uh typically by that point they've seen enough of it to where they can kind of map the two together and say okay I've seen all this now I understand what's going to be sometimes clients are a little more demanding or sometimes they just don't get it um that is just kind of one of those things to do a little more mockups than you thought just getting to that no trust me the design is going to look great points a little harder than others what I've found is that most clients that do that would still do that no matter what process you use or no matter how efficient you were cool thanks yeah no problem in regards to focusing on images and type keeping those consistent is there anything that you guys do to handle once you've handed off to the client and they're like well we're just going to start dumping word documents into the body field and our flip phone photos into the photo fields and that sort of thing I mean is it mainly a lot of client education to try and say don't do this or do you guys do anything maybe in the CMS to really lock down the whizzy wig or post processing images or anything like that um well okay so you typically have two types of clients those who understand and those who don't the biggest thing that still keeps me up at night is sometimes you just can't control that like you can educate people you can give them as many tools but sometimes they're just not going to use it and that is kind of the downside of open source Drupal design is that you do kind of hand off your work and hope for the best I've just found that putting together as much information for the clients to use as possible like like you said like putting together some type of like photo style guide of saying you know if you're going to use a photo here the subject needs to be on the right so that it doesn't you know it doesn't compete with the title that's on the left or whatever I think we tend to lock down our our whizzy wig fairly well um some of the times I don't want to speak for all of it um but I guess the long answer to your question is uh you can try the best you can but sometimes you just have no control over it thank you um curious about your design process uh specific to working with Drupal like when you're designing in the browser are you already working on the theme Drupal theme or is that a static uh html site that you hand over to a front-end developer to make the theme sure that's a good question um and that's actually something that's kind of constantly changing um I've actually learned a lot of things from DrupalCon that I plan on taking back and I'm kind of at a phase where I want to reassess what I'm doing um but to answer your question up until this point uh I've been doing everything I've been creating designing in the browser creating um prototypes using a combination of Jekyll and then the bourbon suite of bourbon bitters and refills um it's great in that I can create some really cool stuff with it uh it takes a lot takes a lot of time and there's a lot of overhead in getting it started so that's where I'm looking at finding you know slightly better method and then it does require that uh our front-end team tends to rebuild that design but at least they're getting like all the information that they need like they're seeing it as it should be in a browser um I think we definitely want to find a way to uh get those prototypes actually into the production site so if you have any thoughts I'd love to talk about that later because we're looking for an answer for that um and does Link Shout just have a basic base theme that you start everything from that I don't know but I can get you in touch with someone who does I mean we have like I said we have a base um Jekyll and bourbon setup that we use for the prototyping but um I believe we use do you know if we use the Zen theme Zen thanks no problem any more questions cool thank you very much