Episode #251 Ben Callahan - Dissecting Design Live!
Many teams follow a linear design process with a big reveal—ta-da!—once the aesthetics, layout, and flow are “ready” for client feedback. Weeks later, the front-end developer enters to turn an approved design into a responsive site that functions perfectly across devices. Now imagine showing clients your work in Week 1. How would everyone respond to unpolished designs?
This is Ben's full presentation from the 2014 UX Immersion Conference
Many teams follow a linear design process with a big reveal—ta-da!—once the aesthetics, layout, and flow are “ready” for client feedback. Weeks later, the front-end developer enters to turn an approved design into a responsive site that functions perfectly across devices. Now imagine showing clients your work in Week 1. How would everyone respond to unpolished designs?
Find out from Ben Callahan. In this talk, he’ll describe how to:
- Improvise solutions—and make it a habit—right out of the gate
- Focus on the people involved, rather than the process itself
- Solve problems in whatever medium you’re most comfortable using
Ben learned all of this when he and his company, Sparkbox, stopped designing deliverables and, instead, focused on the end-product. And after years of trying to discover The Perfect Process that optimizes budgets and skills, he’s finally learned a secret: there is no such thing.
Ben Callahan: I want to share a little bit about just the things that I've learned over the past few years of trying to figure out how to do design in the context of a situation where what we design has to work at 200 pixels and at 2,000 pixels. That kind of throws a little bit of a wrench into the process that we have. And so, I just want to share a little bit of these things.
The way I want to structure this, if we can, is about an hour of things that I'll share with you guys. And then I've got plenty of time reserved in the end for us to just have a conversation. So if there's other things you're interested in talking about, I'm pretty transparent when it comes to how we work and all that stuff. So we can talk about anything you guys want, so we'll make sure we leave plenty of time to do that, OK?
All right, so we used to pretend like things are pretty simple. And Jeremy Keith called this the consensual hallucination. I can remember sitting-- I think it was An Event Apart, and it was years ago. Eric Meyer had just finished blowing my mind with some ridiculously cool CSS thing, and I was sitting in the back, just kind of like, wow, that was awesome.
And he says, does anybody have questions? And a guy in the back corner raises his hand, stands up. Eric's like, what's up? And the guy says, can we start designing for 1024 by 768?
And it was like, Eric gave all this awesome CSS stuff, and the question's not related at all to anything that he talked about. But it was like complete silence. Everybody's like, oh, wait, and everybody's waiting for Eric Meyer from above to convey down whether we can start designing for 17 inch CRTs.
And that moment kind of stands out to me because I lived in that time. I lived in those moments where we were constantly checking analytics, just hoping we could File, New in Photoshop, and put 1,000 pixels in instead of 800. And we were just itching for a little bit more real estate.
And honestly, back in that time, for me, when I was kind of just coming into things on the web, I had a super simple process. This is kind of what my process looked like. I did some design, I built some templates, and then I integrated with a content management system of some kind. Super simple, right?
And you're all smart usability folks here, so you realize that I'm missing a few things in this process, right? Somewhere in here, I probably need to spend a little time thinking about my users. And then-- I know this has never happened to you guys, but for me this was always a problem-- at some point, you've got to have content to put into the site, right?
And so pretty quickly, I think, as an industry, all of us sort of landed on a much more-- a slightly better linear workflow. We kind of did this. We put content up front, because we understood that, hey, if I'm going to design something, I need to know what the heck I'm designing.
If I'm going to create a sculpture, I can't do that unless I have the material. Same idea. And then we make sure that we're thinking about the usability of this stuff. It's not just content. There's functionality.
We need to think about how users are accessing that content. Think about the flows through the site. Then we can start to think about the design, and front end development, back end, and getting content in, and launching.
Well, we did this at my company for a long time. This was kind of how we worked. And interestingly enough, a few years back, Ethan wrote this article. And for us, it was kind of like, holy crap, we've got to rethink what we're doing.
And responsive web design hits the scene. And for a while, I think we started to think about the fact that-- or maybe assign the blame for ourselves challenging our process to responsive web design coming on the scene. But honestly, that really wasn't what caused this, I think.
All these tiny browsers that we're carrying around in our pockets-- very capable tiny browsers. And that, honestly, wasn't even really what caused it, either. I think, really, it was just reality kind of setting in. We used to think about this-- and again, referencing to Jeremy's idea of this consensual hallucination-- we all just pretended like our users browsed with their browsers maximized at whatever the capabilities were of the display they happen to have. And that's just not the truth.
So I read the Ethan's article, and I thought to myself, this is what we should be doing. So I went back to my company, and I said, stop everything. We're jumping into something new.
I was so excited, and that's kind of what it looked like for us to jump in. I mean, we thought we could get this right, but what happened is we kind of took this workflow, and jumping in kind of looked like this for us, because Ethan's article was about three CSS techniques. And at this time in our organization's history, the front end dev was the person who was writing a lot of the CSS.
And so we're midstream on redesigning our on site when I read Ethan's article, and I said stop everything. Let's look at where we are. OK, front end dev, you're the next thing in line. Why don't you make this site responsive? Go.
And I think a lot of us I think have tried this. In fact, we've tried a ton of other things. We've tried saying, hey, maybe you just need to spread that out a little bit, and that can still work. And what I finally realized is that none of that stuff actually helped us make a better experience.
And I think I finally just settled on this idea that we've got to tear down a little bit of understanding that we have. We need to invite some of the people into the process. And so the way that I've been talking about how we work now-- and again, today I'm covering-- I want to dive specifically into design, but I'm going to talk a little bit generally about process, and then we'll jump into UI design.
But I've been talking about this idea of a one deliverable workflow. Instead of focusing so much on all these individual deliverables where we're passing things off, where we're perfecting the wireframes and then passing those off, and perfecting the UI design and then passing it off, and perfecting the front end templates, this process can be a very frustrating experience, especially for the person who just handed off that design, and now they're looking at the templates that they got back, and they're not like the same thing. This is a common experience.
So instead of focusing so much on refining all these individual steps, we're constantly reminding ourselves-- and our customers-- that we need to be focused on that end goal, the actual reason that we're building this, that we're doing this project. And so, we talk about this idea of kind of spiraling through. And I have this financial or business consultant that's been working with me. He's kind of a friend of a friend, and he's an older gentleman. He's been in business for a long time.
And I'm a software developer, right? That's my history. Software development, I moved into design, I did front end dev, then all of a sudden I found myself leading an organization of people building the web. So I felt like I needed somebody to kind of bring me along in terms of what's going on with the business stuff.
And I can remember the first time I sat down with him. I had some specific problem that I was dealing with in the business, and I was explaining it to him, giving him sort of the overview of the company and what we were struggling with. And he said-- and I asked him, can you give me some advice? Like, what should I do in this thing? I need an answer.
And his name is Jeff. He said, well, I don't think we know yet. Let's just wait.
And I was like, really? This is important to me. I need to know.
So next week, we get back together. Same thing-- well, let's just wait a little bit. Next week, same thing-- and it's a month in before he'll tell me anything. And I'm starting to doubt whether I've chosen the right guy.
But what he was doing was spiraling. Each time we sat down, he was learning a little bit more about all the different aspects of our business, and he was spiraling in. And he was focusing in so that he could really actually provide valuable advice.
We talk about this in the context of our workflow as making natural decisions, or waiting until the last responsible moment-- procrastinating, really, is what we're talking about. But procrastinating in a way that means that I don't have to solve all of the design problems at the beginning. I can wait until some of that's been put into a browser. Now I can actually interact with it, and maybe that means I need to make some design changes.
These things are not independent. They feed each other. So that's kind of the idea with the spiral.
It's not intended to be a path that you follow through. It's not really like that. I'm just sort of suggesting that all of these disciplines need to be involved from day one and through the end.
We also kind of put some dots on this just to say, not that these are deliverables-- again, this is a one deliverable workflow-- but these are opportunities to sit down with stakeholders, with your clients, with the rest of the team, and say, hey, here's where we are. Here's the update of our current status. On our journey towards producing the thing that we've been hired to do, this is where we are in progress.
I'll tell you, I want to read a quick quote to you here from Selman, actually, back in 2007. He said, "Almost no one who makes websites works in their company or organization's web division. That's because almost no company or organization has a web division, and that void on the Orr chart is one reason we have so many bloated, unusable failures where we should be producing great user experiences." 2007 he said that.
And you'd think that seven years later, we'd maybe have that figured out. But I still sit in conference rooms all the time with somebody from IT and somebody from marketing or communications, and I can tell these people do not like each other. And they have to work together to build the thing. They have to work together to build the web.
And so this kind of a process works in opposition to that sort of structure where we have these verticals, where we have a user experience team. All the UX people, they're on this team. And all the design people are here, and all the content people are here, and all the developers are over here. Separating ourselves out-- structuring our organizations around these disciplines is creating-- I believe it's creating sort of a fractured experience of the stuff that we're building.
I tell you that just to say that this is not easy to do if you find yourself in an organization where that is the structure. Now, actually my favorite part about this whole diagram is that you can actually hypnotize people with it if they don't believe you. So this is the right way.
OK, now I want to contradict myself a little bit if that's OK. So we draw lots of pictures-- pretty pictures like this-- all the time. And I've sat out there dozens of times to hear somebody talk about process.
And to be completely frank, oftentimes I leave a little bit frustrated, because these pictures don't actually help much. Like looking at this little spiral doesn't tell you how to do anything. In fact, if we were to look at just the design component here-- like that little slice of pie and that circle, there's a whole lot of stuff that's encapsulated in those little shapes. And we really haven't talked about what that means for you when you go back to work next week.
So what I want to do is I want to try to answer this question-- how do we advance design through a one deliverable workflow? So again, we're focusing in on design. And I think that's one of the bigger challenges that I've seen them, just because a lot of our customers still expect us to be doing full comps.
They still expect-- I mean, literally, I got an RFP the other day that said, I want three design concepts, I want each design concept to have three pages-- a home page, a listing page, and a detail page. And I want you to design it for small screens, middle-sized screens, and large screens. That's 27 comps. I'm like, really, that's how you want to spend your money? Because I think we can do this in a much more efficient way.
So the answer is actually really simple. Web designers still use Photoshop. Thank you very much. I appreciate it.
No, I'm kidding. We do use Photoshop, but we'll get there. So I think in order to answer that, I'd like to just address quickly this idea. There's a lot of folks who have said, if you're going to be a web designer, you need to learn to write code. Have you
Guys heard this? Yeah? Yeah, OK. So I think there's definitely validity in that statement.
But I also think that it's not just about that simplistic view. Design is much more than just one specific thing that we do. So what I'd like to do is just talk about this idea. Any task that you do, you can kind of accomplish in this way.
You start, kind of ramp up, get a lay of the land. You do the bulk of your work, and then you have sort of the long tail where you're kind of finishing things. And we can break that up in this way, and we can talk about it like this-- in the context of design, we're establishing the aesthetic early on.
And then we shift into problem-solving. Real design is actually problem-solving. Jeffrey [? Venes ?] said, I've been amazed at how often those outside the discipline of design assume that what designers do is decoration. Good design is problem-solving. I'm sure that you guys know that and feel that, and that tension every day in what you do.
So once we've solved a lot of these problems, we shift into this mode of refinement. Now how many of you would consider yourself a designer? OK, I'd like to talk to everybody who didn't raise their hand.
You know that if you let all those people, they will push those pixels around forever. I mean, look at this, right? I'm sort of suggesting it's about half the amount of time that we're going to spend refining-- if you let people.
Now designers, I'm not criticizing you in any way. I love that about you. I really do, because I think that's what creates something really beautiful. That attention to detail is critical for what we do. But I think we need to be careful.
And so what I'd like to do is kind of examine each of these quickly. And what I'm going to do is give you a ton of tools that we're using now to accomplish each of these tasks. And then I'm going to give you a way to make a decision about which of those tools are appropriate for you in your context.
So let's start with this idea of establishing the aesthetic. I'm going to cover three things quickly, and we'll just jump in here. I had an opportunity to speak with Dan Mall at a conference at the end of last year. He's a fantastic designer, one of the guys I just have so much respect for in the industry.
And he was, about a year ago, was in the middle of building out a new office space in his house. And one of things that he wrote, kind of a cool post about this, he talked about this idea that as a designer, his first urge was to jump in and design everything perfectly. But he was able to sort of resist that, and he and his wife just created a Pinterest board. They put a ton of stuff in there that they loved, that met the aesthetic they were looking for in this new space in their house. Then they shared that Pinterest board with a contractor.
This was a chance for them to basically trust the contractor that he was actually going to do the work that they were suggesting he would do, but they were really trusting that he could do his job. We can easily translate that to the web-- something so simple like this, style comparisons. You go out on the web and you search for, hey, give me the best light-colored web designs. And you're going to find 300 blog posts that all list the top 78 whatever light-colored web designs.
You can sort through some of those, pick a few that are good, screen cap those, throw them into a presentation. Super simple, right? And you can do this very simply. Did you want flat or does textured make more sense? Are you looking for illustration, photography?
And so, this kind of thing actually is so easy to do. You can do it in a matter of literally just a few minutes. And then without spending any time doing a ton of design work-- like in Photoshop where you're comping things-- I can just get a concept. Am I moving in the right direction at least?
Another way to do this is Samantha Warren Style Tiles. Anybody using Style Tiles? OK, a handful of folks. Great.
She talks about them as like defining a visual language. Or I think she calls them mood boards for the web. Here's an example of one. You can see the idea here is that it's a static image.
So she's done this in Photoshop or whatever static design tool she's comfortable with. And she puts a handful of assets on screen. This is not the design of a page, and it's fairly clear that that's not the case.
That's actually one of the dangers here. If you make it look too much like a website, people are going to be confused about what you're showing them. But keeping it sort of short and simple like this-- showing how a headline might be treated, what colors are we going to be using, how photos might be treated, what does a button look like-- simple things like this.
It's really just a step in a certain direction. Samantha does usually a handful of these for a project, and then she'll lay these out with a customer and say, what's working? What's not? And it's basically a way to invite your client into the conversation with you in terms of what aesthetic is going to be good for their brand.
I had an opportunity to see Samantha present this at South by Southwest a couple years back. And I can remember literally walking out of the auditorium there with one of my front end devs, and we looked at each other and we were like, that's really cool, but we should be doing that in the browser. So we quickly came up with this concept of a style prototype.
Very similar to what Samantha does, but this is done in HTML and CSS. And you can see, it's very simple. I mean, just a little bit of text, how is the headline looking, maybe a logo treatment, what colors are we using. I've got an actual button down there-- I didn't scroll. We can open one up a little later if you guys want to see it.
But these are so fast to do. I mean, literally in a matter of just a day, my creative director can create this thing, and push it into get GitHub somewhere so we can do a review with a client. We can put real web type in here.
And I know Photoshop and those things are getting a little better at the rendering, but my creative director is a type geek. OK, like this guy is hard core. And I mean, let me just-- quick example, OK? We used to do ridiculous things to get accurately rendered type into our designs. He would design it in Photoshop.
I would get it coded in the browser, screen cap it, and then bring it back into Photoshop so that the rendering of the type was being displayed accurately. That is ridiculous, right? I mean, that stuff is stupid. We should not be doing that
So shifting this idea into the browser means that they're going to look at it on whatever browser they use, their browser of preference. Now we can start a lot of really good conversations in terms of, what does it mean to support your browser? Like as an example, if I chose-- maybe I thought that these should be sort of rounded corners instead of squares. I could do that in CSS with a border radius.
If the client happens to browse on IE6 and they open this up, they're going to get square corners. And now we can have a conversation about what it means to support that browser. It's an entry into that in a very simple way. Much better in my opinion than doing this in a static way, showing them squares, and then having to explain later once it's in code why they're not round. That's an ultimately simple example, but you get the idea.
What else? We can show real web interactions here if we really want. Like I'm tired duplicating layers in Photoshop, and creating the hover state, and then exporting lots of different images to show that.
I mean, that's a pain in the butt, right? So we can do that so easy, in a matter of just a minute or two with CSS here. It just makes things much easier.
And I love the fact about this that I can sit with the customer in a meeting, I can have a front end developer with me. They start making suggestions or have some ideas about how things can change, and we can make a few changes in CSS and upload the file and just refresh, and we can see it. Very real time, very collaborative.
So we're using these on a lot of our projects now. Here's another one we did recently for an organization. Look if we scroll down on those pages, here's some more of the detail that's in there.
So again, we're just putting some design thought here, but this isn't exactly-- it's not a web design layout. It's just some of the assets kind of designed out and put on a page. Here's another one we did.
When we're talking about establishing the aesthetic, I think it's important to select tools where you find you have a lot of comfort. That's why I don't think it's necessarily bad to use a static tool in this phase if that's really where you have a lot of comfort, if that's where your team's comfortable. The idea here is this is going to be one of your first interactions with your customer. You're going to be sitting down with them and showing them your work very early in the process.
These things only take a day, right? You could do a lot of this in just a simple day. And so, that means you need to be very comfortable with these tools. It's got to be a very easy conversation with that client.
So I want to shift into solving the problem. Again, I'll cover three different options here. And let's just kind of jump in.
So Photoshop-- static design tools. People-- we still use these tools pretty much every day in our process. Photoshop-- there's a bunch of new ones on the scene. Anybody use Sketch? A handful of people.
Pretty cool tools. Our creative director really likes Sketch. It's got a cool feature now where if you've got your device connected, you can actually sort of have the device mirror the design right on the device itself, so you can kind of see very quickly without having to export and upload and all that. You can just get that image, a static image of what you're designing right on your screen.
And that helps because you can't just sit this far from the display and make good decisions about font sizes and things. You need to hold a device in your hand to see, is the layout appropriate? So we still use these tools. I'll talk about how we use them a little bit more here in a moment.
And then, honestly, we solve a lot of our problems with paper or white boards. We've got white boards everywhere in our office. I'm sure that a lot of are sketchers, as well.
My creative director starts everything here. Like this is just a very comfortable place for him to start thinking. It's very common for us in our office to do something like this, or sketch on a whiteboard, and take a picture of that thing with a phone, and push that picture into Basecamp, and have a conversation with a client.
That's a quick example of what I mean by a one deliverable workflow. This is not the deliverable, so I don't want to spend 20 hours refining a wireframe. That is not what I want my team doing. I would rather have them get these ideas on a piece of paper or on a white board somewhere so that we can have a conversation about it, and then we'll talk about refinement later.
So these are static tools. There's also tons of these new responsive web design tools. I don't know if you guys have seen Reflow from Adobe. Pretty cool tool.
Fruit is a web-based responsive web design tool. So you can actually create an account, do it all right in your browser. Pretty cool, pretty cool.
And then Macaw recently-- anybody using this yet? No? It just dropped pretty recently, the actual live version. So Macaw is really an interesting tool. It's gotten a ton of press from front devs because the code that they're generating is actually fairly clean.
At Sparkbox, we don't generally use these tools a ton. And when I say "these tools," I mean the tools that are going to let you visually design but will generate code for you. I think they have a place in the process. I think they can be fantastic for doing interactive wireframing or prototypes. And I think that's probably where we'll see them-- at least in our organization-- where we'll see them with the most use.
And then, HTML and CSS. Pick your favorite editor, throw in some browser dev tools, maybe a library or two, and it's really incredible how much work you can get done in a short amount of time if you take an approach like this. Now I do want to address one quick thing, which is this idea that-- and Brad, I think-- I'm sure a lot of you were able to attend Brad's workshop yesterday.
But Brad talked about atomic design. And there's a lot of people in the industry talking about this idea, of the separation of modules that need to work, and the layouts that they need to fit into. And so we definitely agree with that concept. We have our own little way of doing this.
But what we've seen is we use tools like Photoshop and a piece of paper, those kinds of things to solve a lot of the layout problems. Oftentimes, we'll use sketching as kind of the primary way that we're concepting layouts. And then modules are solved in more of a refining kind of way in Photoshop where we're-- it's hard sometimes to wrap your mind around how to build a specific little widget just in CSS, so sometimes it makes a lot of sense to start that concept in Photoshop. And then that can quickly move in-- once the problems are solved, quickly move into the code.
Brad's talked about atomic design. I love the quote here at the top of his post. "We're not designing pages. We're designing systems of components."
I agree wholeheartedly with that statement, but I also think that we need to be careful. You can't just design the components. These components, the way that they look and feel will change based on how they work on a page together.
So I love this quote from Carl Sagan. "The beauty of a living thing is not the atoms that go into it, but the way those atoms are put together." And so, this is kind of the mentality that we're kind of constantly-- this balance between developing these modules, making sure that they're beautiful, that they're functional, but also that they can work very well together on a page.
And so we have this sort of distinction. And I'll tell you, too, in terms of making decisions about what tools you should be using, I believe that you best solve problems using tools that you're fluent with. So what I'm suggesting is, from for my organization, we have a lot of fluency in HTML and CSS. My designers know those tools, so we make a lot of decisions-- design decisions-- with code.
But I want to drill into this idea of fluency for a moment, OK? When we first moved into our office-- our original office-- we kind of inherited this huge pool table. The guy who had that space before had put this in, and could not figure out how to get it out of there, so we kind of just got it basically for free.
Now, I hadn't played much pool up to this point in my life, but I'm the kind of guy that likes to-- I like to be kind of good at the things that I do, and I'm also a total nerd, so I went to the library-- I'm sorry, I went to the bookstore the night after we got into this office, and I bought a book on how to play pool. So I'm sitting in bed that night, and my wife and I are chatting, and I'm trying to read this book.
And chapter one is all about like the equipment, kind of a boring chapter. It was about the rails and the pool balls and the cue stick and the chalk and all that. And I'm like OK, next chapter.
Chapter two was all about angles. And I was like, OK, I got this. The book gave me this little system for visualizing where we two balls need to connect in order to control where the one that's been hit will go. And I thought, I've got it. Let's do this.
Go back into the office the next day. I'm talking smack. Get on the pool table with somebody, and it was all right. The book didn't really impart this amazing ability to play pool to me.
But what I had was an idea, something to shoot for. And so, I was diligent about it, and I was constantly trying to use this little technique they shared with me. And so I did, I actually got better. I quickly kind of improved.
But I also very quickly plateaued. And we play game in my office called nine ball. Anybody play nine ball? OK, so traditionally, most folks who don't play a lot of pool, they kind of just play eight ball, right? You either go for stripes or solids-- pretty simple.
With nine ball, you only put nine balls on the table. And one of the important rules is that the cue ball has to touch the lowest numbered ball on the table first. So if the one's on the table, and you hit the cue and it hits the two first, that's a scratch. So that means essentially, the way the game kind of plays out is you end up putting the balls in in order-- not always, but generally.
So what that means is it's not enough to be able to just get that first ball in. I also have to control where the cue ball goes after. That means I need to set myself up for the next shot.
So this was not working. I would get the angle. If I happened to have a shot on whatever the lowest number ball was, I could put that one in, but I could never set myself up for another shot.
So I go back to my book, and chapter three was all about English. And English-- spinning the ball, right? And this was a technique that this book explained where, depending on where you strike the ball-- the cue ball-- with the cue stick, you can impart various kinds of spin on this ball. And what that does in terms of the physics of what's going on is it will actually allow you to somewhat control where that ball goes.
So that means you have an opportunity to set yourself up for the next shot. And I thought to myself, now-- now I've got this. So I go back in the office, talking smack again, get one of my partners over to play some pool, and I totally blew it. I mean, my game went-- right? And it's because I was so worried about spin that I forgot about the angle.
And what I'm describing to you is a well documented idea. And this is how people learn things. And this is a diagram called the dip. I want to overlay this quickly with something called the four stages of learning any new skill from a researcher back in the '70s named Noel Burch.
When you start off learning something new, you're in this stage of unconscious incompetence. That means you have no idea how bad you are. That's me when I first start out with pool.
Quickly, you'll realize you reach a place of conscious incompetence, and this is where you realize that you suck. That's me, quickly plateauing, and I'm like, oh, there's a lot more to this than I thought there was. And then if you're able to kind of focus and push through this dip, you can reach a place of conscious competence.
This is where you're actually very good at something. You've achieved a level of skill, but it's also something that requires a lot of focus. You have to be very conscious in the way that you work. It's not something that's natural to you.
And if you continue to push, you reach a phase of unconscious competence. And this is where the skill is just a natural outpouring of who you are. And just so the Olympics wrapping up makes this pretty poignant. You know, I can remember watching these athletes-- even just this year-- and thinking, these people make these difficult things look so easy.
And I know, it looks like I could just jump out there and do that. I know I could. But I know I would break my leg if I tried.
And that's because these people spend hours and hours and days and months, and their entire life is dedicated to this. That is fluency. And so what I'm suggesting is if we want to solve problems, and we want to solve them well, we really need to find tools where we can actually be fluent.
So now let's shift into this idea of refining the solution. I'm going to be a little bit more direct here, because I don't believe that you should be using static tools to refine your concepts, refining your solutions. I would say instead consider something like design pairing, and let me tell you a little bit about what I'm talking about.
If we choose to do this where design perfects this Photoshop file, and that Photoshop file gets handed off to somebody who's going to code it-- I've been in this situation many times where I get to right here, and this guy's not so happy with what I did. That's pretty common. A lot of times, the designer feels like their vision has not been accurately carried out. And honestly, it's usually not.
So what I think we need to do is just be able to recognize when we've shifted here. And I think we need to start considering something like design pairing. Let me show you a little bit about what I mean.
So here's my team. Actually, I'm missing our apprentices here in this picture. But we have 21 people in our office, and we have one guy who's actually-- this is our creative director, Jeremy Loyd. He's the only guy that actually is a designer technically.
All we do all day long is design responsive stuff. But all of the front end developers on my team could probably be designers in another organization, but they're fluent in HTML and CSS. And so, Jeremy sets the direction for all of the creative that we do, but he only does just enough to get the direction started. And then we get into the browser with all the front end devs, and he'll pair with them.
And he'll sit with them when it's appropriate, he'll review some of the design decisions that they've made with code, and he'll make some recommendations. And the more that he does that, the more that he sits with them and teaches them why he would choose to do something differently, the better they're getting at implementing his visions for these websites. And the converse is true, as well. He's also learning about the front end development. He's watching them code.
That's worked well, and he's actually now writing HTML and CSS himself. Just the other day, I was on Slack-- one of our communication tools-- and I saw a pull request from for GitHub come into one of the production code projects that was from my creative director. And I was like, yes, that's amazing. My creative director who started in branding-- he's an illustrator, never wrote code until two years ago-- just submitted a pull request on production CSS for one of our projects. And I mean, that's the evolution that he's gone through, and it's been incredible to watch.
We believe in this idea of pairing a lot. In fact, as we set up our new office, we structured it in a way that-- hopefully, the idea is to kind of facilitate this. So we've got these big white desks that kind of stick out from the walls. And you'll see there's enough places here for six people. You could put one, two, three, four, five, six.
And we call them quads because we only actually seat four people at them. We leave the center seats open. And we do that just simply so that anybody at any time can go sit next to anybody else, and have an opportunity to work with them on something. Here's a shot of Jeremy, our creative director, working with one of the front end devs, Rob Harr. And this is just sort of a natural part of how everything's happening now in our space, because it's so simple to do it.
Again, my point is that you do not want to do this long tail more than one time. Switching mediums is going to require that refinement to happen again. And so, we need to start to learn to recognize when we reach this switching point.
This is not an easy thing to understand, honestly. And designers have a really hard time realizing when they've shifted from a problem-solving mentality into a refining mentality. Sometimes it takes somebody else in the team to say, hey, you might be refining a little bit. Let's get this into the browser so we can do that refinement here.
Now another thing that's important about this is you have to tell your customer that you're going to do this. If they didn't know that was happening, and they've seen some static design in some way, and then all of a sudden the next thing they see, it's in code, they're going to freak out because they think you're done designing, when in fact you're not. You haven't refined yet. So they need to understand that that's part of the process. That needs to be part of the communication from day one with them.
When you're trying to make decisions about what tools to use as you refine your solutions, I think efficiency is key. So again, that's simply because we don't want to do that long tail twice. So a quick wrap-up of the guidelines for selecting the tools that I'm suggesting.
When you're establishing the aesthetic, think about tools you're comfortable in. When you're solving problems, think about where your fluent. And when you're refining, think about where you're efficient.
So a quick example-- and again, I'm only talking about the visual design here. So there's a whole other part of our process that's involved with usability and a lot of things. And I realize these are very related, but there's sort of a parallel path that runs for us. And I'm happy to sit with anybody later and chat about that in more detail.
But I'll give you a quick rundown of a quick project we did not too long ago. So we started sort of establishing the aesthetic with a PDF file that my creative director created with super simple little inputs-- so two checkboxes and a text box. And this was given to our customer so they could say yes or no, I like dark or light, or I like flat or textured, I like photo or illustrated, I like friendly or masculine. And we got some really interesting feedback from them in this little box which facilitated some really great conversation.
We shifted into a style prototype. This is the style prototype for this site. Again, similar to all these others. This is in a browser, so it's HTML and CSS.
And for them, there's a big part of what they did on their website was people could apply for this activity. So we needed to demonstrate quickly what would an input look like, what was a button going to look like-- very simple. Then we started to kind of mock these things together. This was done in Sketch-- two pages, I think, that we mocked up, just this concept and this concept.
And then very quickly, kind of shifted to moving those things into more of a style guide. So we've got different pagination styles and button styles and error states, and how does the table look, and those kinds of things. And the next phase here was to then code this, and actually get a lot of these things-- a lot of this stuff was actually done in the browser so that we could see the actual hover stages with these buttons-- those sorts of things.
Now we can talk a lot more about pattern libraries if that's something you guys are interested in. We do that in almost all of our work now. And Brad's presentation on atomic design-- he's covering a system for doing that.
So now I want to shift gears just a little bit. I want to get into, how do you facilitate great work in your organization? The process itself is probably not enough to do that.
And so, another quick story for you. Any jazz fans here? Who owns this album, Kind of Blue? Yes, you're my people.
I love-- this record is one of my favorite records. A lot of people will tell you that, actually. Anybody who's a real jazz fan will tell you this is one of the greatest jazz records of all time.
This was recorded in 1959. Miles got four or five-- the artists are up there-- of the most influential musicians to date into the same recording space. It's a little church converted into a studio in Manhattan.
1959, they had two sessions. And this was recorded over the course of these two sessions. But the musicians who arrived had no idea what they were going to record.
This thing-- this thing still sells 5,000 copies a week. Recorded in 1959. That's a timeless piece of music, right?
What was going on is Miles was really frustrated with what was happening in the jazz scene of the day. It's called hard bop. And the way that worked generally was you'd have a band that would sort of stand in a semicircle. One of the guys would step out-- or girls would step out-- and just start wailing on a solo in improv, but the rest of the band is kind of just vamping on chords. They're just playing something that's well established.
And Miles was frustrated because he wanted to find a way to get that entire team to improvise together. Fascinating idea, and he had experimented with it on a previous record with a single track. And he loved the result, so he wanted to try to create an entire record of just that.
Again, the instrumentalists had no idea what they were going to play when they got there. The first time they make it-- from start to finish on a single track-- that's what's on the record. So they were given basically just a sheet of modal scales when they walked in. That's it-- a scale for each song.
And these tracks were conceived just moments before they were recorded. It's really an incredible thing what he did. Too much structure would have put him back in the same hard bop problem. Not enough structure would have meant that they probably wouldn't have ever gotten from start to finish on a track.
And I want to-- would it be OK if I played a little of this for you quickly? OK, thank you. So here's the opening track.
[MUSIC - MILES DAVIS, "SO WHAT"]
It's called "So What." You can hear Bill Evans, who's the piano player on most of the tracks here. So it's sort of hesitant, right? Not quite sure what's going on [INAUDIBLE] Can we find something that will get us started?
Bass takes over here. Now he's like, OK, there's something we can work with. It's back and forth, bass and piano. And the rest of the band hears this and they're kind of like, yeah, we can do that. [INAUDIBLE] same group.
This whole album just ebbs and flows. And you can tell they're just trying to figure out how to do this. It's a constant awareness of the rest of the band. What is everybody else doing? It's a fascinating record.
And I found myself a year ago or so sitting in a hotel room at another conference, and I was supposed to speak the next day. And I had just had dinner with a guy who was going to talk about the exact same thing that I was going to talk about. And I'm like, hm.
So I'm sitting in the hotel room. I'm listening to this record, because it's one that I listened to often. And I was just flipping through the liner notes. And up to that point, I hadn't really read these.
I'm going to read this from Bill Evans. He said, "Group improvisation is a challenge. Aside from the weighty technical problem of collective coherent thinking, there's a the human, even social need for sympathy from all members to bend for the common result."
And I read this, and I thought, man I wonder if Bill Evans is a web designer? This felt like it could be written about what we do every day. And he talks about two distinct challenges-- collective coherent thinking. How do we get our teams to think as a single unit? The challenge of the group.
And he also talks about the need for sympathy from all members to bend for the common result. This is the challenge of the individual. As an individual on a team, in order to participate in this kind of thing, there are certain characteristics that you need to embody.
If I'm just completely open and honest with you, the process that we use to build stuff on the web these days is that. Every project is different. Every client is different. Every team that we put on it is different. Every budget, every timeline.
There are so many factors. For us to think that we can create a perfect diagram that encompasses all of those challenges and tides it up beautifully, to stick it into a Keynote presentation and give it to you, I think that's just not possible. Instead, we try to find ways to embrace this idea of group improvisation.
So what kind of person do you need to be to participate in this? I think there's a handful of characteristics, honestly. And we talked earlier about fluency. That's very critical.
If you think about the players Miles had in his band, had he just brought in some average musicians, that record would not be something I'm playing for you today. Instead, he had been playing with these guys for years, and they're some of the most-- they're just giants. They're fantastic musicians.
And for us, this is about creating a culture of learning in our organization where people are constantly striving to be better. But not only fluent. Fluent is important, but humility is important.
Now think about that, right? I want people who are really good at what they do, and I want them to be humble. Those two things don't always go together so well, do they? So this is a real challenge.
And we were talking in the workshop yesterday about, how do you find these people? And I kind of maybe suggested that we need to hire for humility, and then we can make people more fluent. We can teach people to do things, but you can't make somebody humble.
You need to be willing to give critique. You need to be willing to receive critique. One of my friends at another conference said, if you can't say no, it's not collaboration.
I love that statement. It's so simple, and it's so true. And it's true as we interact with clients.
If you find yourself in a situation with a client where you're just not allowed to say no. Every time you say no, they just say, sorry, that's not it, go this way. Or likewise in a situation where you find yourself never willing to hear the word "no" from your client. It's also true in teams-- individuals being able to say, I don't think that's the best idea, let's try something different. That means you've got to have parties on both ends that are very humble, willing to hear that kind of feedback.
And I realize I'm speaking to a bunch of you user experience people, and the word "empathy" is probably overloaded for all of you. This word, everything I read about experience now talks about this, with this idea. I'm not talking about empathy for our users.
I'm talking about empathy for your team. And I think that's different, and it's also incredibly critical. If you're not aware of what your peers are going through on a project, there's no way for you to help make decisions that will improve the group as a whole.
So you've got to be aware of what's happening in the other disciplines. This silo of user experience versus a silo of development-- that's not going to work. You need empathy with development. Development needs empathy with you.
So these three characteristics-- fluency, humility, and empathy-- I think are the kinds of things we need in the individuals we're looking for on our teams. But that's not enough. What about the environment where this stuff happens? How your organization works, what's happening in your office every day.
I want to tell you another story. Sorry, I like to tell stories. A little dark to see, but this little is a Google satellite view of a building right here.
This is the school that my kids go to. I have two kids-- a five-year-old and a four-year-old. They both go to the same school. And it's my job every morning to get them into that door.
So I have a truck that I load them up in in the morning, and I come down this road, and I drive in the parking lot here. And I gotta get them, I gotta get parked, I gotta get them out of the truck, get the lunch boxes, hold the hands, and get them in the door. And as soon as we get in, get them to their classrooms, everything's good. That's my job every morning.
All year last year, I did that. No problem. Everything was good.
I'm going to zoom in quickly for us right on this little part of our parking lot. So the first day of school this year, same thing happens. We get the kids up, get the lunches packed, get them into the truck, get over there. And I come in, and this is what I see.
These are the largest speed bumps you will ever see in your life. I think they're about three feet tall, and I spill my coffee every morning if I drive over these things. I was like, wait, really?
So I came in that first morning of this year. Kids in the back of the truck-- not the way back. It's a big cab.
And I pull up, and I stopped. I was like, wait, seriously? Really? Like, you had to put speed bumps in here?
All of the people who bring their kids to school here have kids here. We're aware of what's at stake. Nobody's speeding through the parking lot. I was like, screw that, I'm going around.
And what's funny is that it wasn't just me. Every single parent did the exact same thing. Nobody wanted to drive over those speed bumps.
And what's funny-- what's even more beautiful about this whole situation-- is that we devised a system. None of us talked to each other, but all of the parents in their separate cars devised a little system. If you were coming in, that meant you would get priority because you needed to get your kids in to get them to school on time.
If you were coming out, you had already dropped the kids. Not a big deal. So we coming out would sort of wait right over here. The parents coming in would get right of way, and they'd come right around. And then we'd be like, zoop, out we go.
It worked beautifully. For about one week, it worked beautifully. And then I came in-- the first day of the second week-- and this is what I saw. Two teachers-- I assume they're teachers-- every morning since that day have parked their cars right at the end of both speed bumps. So now I can't drive around them.
Now, why do we have speed bumps? Anybody-- give me an answer. Why do we create speed bumps? Anybody, c'mon.
To slow people down. Thank you. Do we create speed bumps so that people will drive over them? No, we don't do that.
If I was going to translate this in some obscure way to what we do every day, I would say create guidelines instead of rigid process. If you have a list of boxes that you expect to be checked, and that is how you define success, then you might be doing it wrong. Instead, we need to be evaluating the end product, and whatever methods we can use to get there, if it's good work, we've done it right.
So I think we need to shift away from this idea of super rigid process and move into more of a improvisational approach. Now that's not something you can just do overnight. It takes time.
Here's my theory-- my latest theory-- on web process. "The amount of process required is inversely proportional to the skill, humility, and empathy of your team." As those three things are demonstrated and increase with your team, you can slowly remove some of the very rigid process, and allow room for experimentation. That's the only way that you're going to solve problems in a way that's outside of what's the norm. So you have to encourage that kind of thing.
The way I see it, we have two options. We can do this-- create the perfect, fully documented, all-encompassing web design development process. I've tried to do that. If you want to try it, good luck.
Or, we can chill out and develop our people. People are the ones making these decisions every day, and if we give them space and help them become better, encourage empathy and encourage humility, they're going to start to do amazing things. In general, I would say invest in your people instead of your process. I hope some of these things have shed a little bit a light on how we work, and maybe will be a few things you can take back to your team. And I thank you so much for listening.
Audience Member: So I work in a big corporation that has lots of big corporation kinds of process. And within the executive team, they're all saying, we want to go lean, we don't want these big heavy deliverables. But there's so much pushback from the development team, development management, the line managers. And I'm wondering if you have any ideas for how to make it happen when you got this big machine that feels like it needs feeding with big, giant deliverables.
But a lot of you probably find ourselves in large-- how many of you identify with that question? Wow. Look around.
Yeah, so the only thing that I've seen work well in that situation is to find a small project somewhere that's a little bit below the radar, and to kind of hand select a team like this, full of people that have that humility and empathy and fluency, and let them do something really amazing in a much shorter time span without that rigid process. And oftentimes, that kind of a win-- getting that kind of win early-- will help you say, look, guys, this is real. We can actually work this way. Here's an example. That's one thing we've seen.
I think to start with, also, just-- yesterday, I talked a little about this idea of putting people together who you wouldn't normally have work together on a team. If you've got a problem specifically with the development part of the organization, then get one of those devs to come work with your team, or vice versa. Send one over.
And they don't have to do anything other than sit there with the people, and just engage with them while they're doing their job. A lot of times, just that collaboration sparks a little bit of an interest in finding other ways to work. So I've seen that help, as well. Yeah?
Audience Member: So I work for a small distributed organization. Do you have any suggestions or advice for people that don't work in the same building, or even in the same city?
Yeah, honestly, we do this all the time with our customers, too. I didn't really get into it, but I believe that if you're going to be an organization that talks about collaboration, that needs to filter through every part of your business. So we do things like collaborative estimation. I don't write estimates anymore. I work with my customers to come up with those estimates-- that kind of thing.
So that's filtered through everything, but that means that our clients are involved with our project as much as my team is-- at least that's the goal. So we find ourselves oftentimes sort of working with a remote team even though it's not my team. And we use Google Hangouts.
There are actually specific-- I can never remember the names of them. There's a couple specific tools that are designed for doing pairing. They're kind of pair programming design, but it's just really screensharing and a little bit of a voice channel at the same time. So we do that a lot.
I think that when you have a distributed team, the times where you do have an opportunity to be together are very critical. And you need to make time in those opportunities for people to do more than just work together. They need to eat together and go have some drinks, and there needs to be that connection-- that personal connection.
And that will go a long way toward allowing those people to work together when they're not physically in the same space. That's a good question. Anybody else?
Audience Member: Really, more just like a comment on the last question than a question of my own. That is, I just wanted to echo what you said. I work on a distributed team where we're all over the world, and having video chat and IRC day to day.
But making sure we have time to sync up every month and a half or so is really invaluable. It's kind of like high altitude training when you're kind of away from each other. And then you get together, you're intensely, intensely productive.
Audience Member: Do you have any recommendations for training up your organization on humility and fluency? Because a lot of times, we can't really choose who we get to involve in our projects.
Now, we do things like we run an apprenticeship. I run an apprenticeship, and we're in our third session of apprenticeships now. And it's different than an internship.
It's very, very intentional. Six months long. They're paid full-time. They don't do any billable work. They're there only to learn.
But a lot of the reasons that we do that are not only to help raise up a level of the folks in our area in terms of what they understand, all those kinds of things, but also to really to require my team to teach. Teaching makes you smarter, and so does writing. Everybody on my team is required to write.
We have our little blog called The Foundry. Every week, there's something out there. And every single person on my team write on that blog. And it's something that some of them love, some of them aren't so happy about it.
And pretty much all of them think they don't have anything to offer. That's what they all think. And pretty much everybody thinks that.
But the truth is there's always somebody much smarter than you, and there's always somebody who's a little bit behind you. So the things that you're learning now are gold for somebody else, I promise you. And so, we just believe in this idea of-- for me specifically, when I write something, if I write an article, I probably read 20 or 30 in order to write that one.
When I write about something, I want to understand the context of that subject. I want to go understand what's been written, what's been said about this already. That process of writing makes me much more intelligent about that subject than I was when I first had the idea for the thing I wanted to say.
So writing, encouraging people to speak and teach. Even if it's just at a local meet up, that's great. That's an opportunity for somebody to really dig in and learn some new thing.
The apprenticeships do so much of this for us. One of the things that we require of the apprentices is that they spend two or three hours every week pairing with one person in the office. So they pick a person that they think has a level of fluency in something where they're lacking, and they'll just go sit with them for an hour.
And the questions that somebody who has no idea about this industry asks are very poignant questions. That challenges how we work every day. And it also gives my people an opportunity to teach those young students. And that's been something that's completely changed the dynamic of our organization. Our culture has shifted dramatically since we started that. It's been a huge help.
So I would-- especially all of you here-- I know Jared has told me about the kind of people that come to this conference. I know you're all very smart, so you need to be teaching young people about how to do this stuff. They really need it.
Good question. There's one in the back there. What's up, Jason? How you doing?
Audience Member: You touched upon the collaborative effort, which helps you guys be more efficient and deliver quicker, but also create that culture of everybody matters, everybody's valued in this process. Do you have any input on breaking down those silos at work? Like say your technology team's downstairs, the designers are upstairs, and everyone's-- that kind of culture where it's just passing stuff back and forth. Do you have any suggestions on how to help break that down a little more?
But I think there's a lot of people who have said that this stuff works. This is not-- not all of this is my idea. The Agile Manifesto-- you guys are familiar with this, right? I love the concepts in that stuff.
And they're talking about getting all these people in the same room. And to the gentleman or lady who was asking about documentation earlier, those writings talk about prototypes prove documentation. Working code trumps documentation.
That stuff has been said. It's been proven to be more effective. So I think the data is out there to support it. That doesn't mean that the people in your organization will buy into it.
We get push back with this sometimes when I tell clients that we do a lot of pairing, because they think, well, I don't want to pay whatever an hour for two of your people to do the same thing. But honestly, we're more efficient when we pair. We come up with a better solution, because it's two minds bouncing ideas around.
We also are less distracted. Like I'm not tempted to go check my email 30 times every minute because there's a person sitting with me, and we're working on this problem. So there's a ton of ways that it's more efficient. So I think efficiency is another one.
I still come back to this idea of finding an opportunity to do something small where it's a little bit under the radar, and you can kind of hand pick some individuals to be on this team to demonstrate internally that it's better. And I think that-- you can't be that. The proof is in the pudding. If you can show it and demonstrate it, that can really help.
I don't know if that helps. Who else? Right in the middle there.
Audience Member: Hi. You'd mentioned something about UX and usability earlier, and said maybe we could talk about it later if we're interested. So I'm wondering how things like IA and flows and all that stuff into your process.
And I realize those two are very interrelated. We kind of do separate out this idea of establishing the aesthetic as a thing that we do early, but we do that establish idea with everything early. So at the same time that we're doing style comparisons or style prototypes or style tiles or any of those kinds of things, we're also doing content audits, and trying to figure out what's missing in their content, and organizing that content in some fashion.
So there's a lot of this stuff that's happening together. Pretty much all of the things that we do to establish the design aesthetic, we actually-- you might hate me for this-- but we actually remove content from those so we can do them very early in the process without the actual content. All we're doing at this point is translating a brand-- translating their brand to the web. How's this going to work online?
And then when we start to get into actually thinking through the system, that's when we need the content to be able to understand the actual stuff that we're designing. So there's this constant back and forth. We use things like-- we do some interactive wireframing, but we also do-- one of the things that we found is-- and Luke is going to talk later. He wrote this book called Mobile First, and if you haven't read it, you should probably read it.
And we love the idea of this. And so, most of our updates that we do in terms of UX and content are focused on priority. What I've learned, at least, in the past year or so is that one of the biggest challenges when you shift from thinking about large view ports to small view ports is that you lose a ton of the methods that you use to communicate priority when you get to such a small amount of real estate.
There's only one place at the top. I can't put three things up at the top. So we've shifted a lot of the way that we work in terms of planning-- for architecture planning, for interaction-- to be more about understanding the real priority, and maintaining priority across view port widths.
And so that means we do something called a content priority guide, where it's kind of like a content model but is a super simple version. We do it in a Google Document so that our client can edit it with us in real time. And that helps us just really prioritize the kinds of things that are really important to the customer. It's very linear, so they can't put anything-- there is one number one, and one number two, and one number three.
We do the same thing if there's a more interactive kind of experience that we're trying to build. I know there's a million wireframing tools out there. We actually use Keynote for ours because it's so fast to work in, there's simple little libraries, and I can make it interactive by just adding little clicks to it. I can do some really simple things with it.
So we've used that a lot. And we create small view port width files in Keynote. And they're incredibly awkward to work with. They're like that wide and that tall.
But it forces the priority conversation very early in the process. And so, we do that oftentimes. We do something called the content prototype, which is a lot like the style prototype, but it's real content in markup.
And I talked about this idea that if you're a designer, you probably need to learn some code. Well, I believe if you're going to be a content person on the web, you should probably learn some markup, right? And so our content strategist and our director of usability writes a ton of markup. That's one of his jobs, because he and our constant strategist understand the content and the functionality better than the rest of my team early in the process.
So I want them to write that markup so we've got sort of that pure view of the code to start with. And then we take that, and we realize that we can't work with purely semantic markup in a system that has to be built and maintained and is massive, so we add to it-- certainly during development.
But I don't know if that answers it. We can talk more over a beer or something if you want to. Mic over here, Kelly, I think.
Audience Member: I know you didn't touch on this too much here because it's a little bit broad, but at what point do you incorporate user testing? And what types of tools do you recommend for that?
So I'm not a big fan of doing a ton of testing with wireframes and stuff, honestly. That's my personal opinion. I just feel like the data we get is better after there's a layer of style that's applied.
So we've used Envision app to do a lot of that kind of testing. We've used-- I don't know, we've used a handful of things. There's an organization in Dayton that has a gentleman who's very, very skilled in this area, so he does a lot of-- if it's a bigger customer, we usually bring him in to handle a lot of that kind of stuff.
I've got a whole deck that I could share with you on just a bunch of stuff we've learned from testing small screen navigations. And it's like so juicy, like all this stuff. And I feel like that's one of the areas where I think there's the most need for real, real testing to be done. and one of the people in our workshop yesterday has done some testing, as well, and basically was like, yes, we're seeing the same thing. But he and I had both expressed that we're seeing-- when you hide your navigation behind an icon of some kind, like a hamburger icon or even the word "menu," when you do that, if you look at your analytics, you're going to see a massive drop off on the number of people who actually use the navigation, because users don't expect to have to trigger something to bring that nav on-screen.
Those are the kinds of things we're learning just by-- like we didn't know that. We made of a ton of assumptions. I'm hoping to write a little bit more about how we did some usability testing with the Lenovo website. Lenovo's Australian website is their first rollout of a responsive project for them. We did a little bit of work with them on that, and that's been-- we sent a team over to Australia to do a bunch of testing there, and got a ton of really just amazing data.
So we tend to do it once we have templates. That's kind of where we go. And we're very fluent in the templating work so we're able to make changes quickly as we go. It's a really iterative approach. If we see a pattern emerge on person four, we may make some adjustments, and then retest those things, see if we can fix it right there.
The question is, is it fixed into the process for every project? And are there budgets allocated? It's not, unfortunately.
It's something that I think we need to be doing more. One thing that we're doing or experimenting with is the idea of having a group of people that are just once a week, two or three folks constantly in our office, so that whether I put a line item in it for a budget or not, everything is getting tested. And just recently, I've reached out to a few folks in the area with a disability so that we can do some accessibility testing, as well. I think that's really important, too.
So these are areas where I think where we need to improve. We should talk more about it. Another question over here, Kelly, I think at the same table. Hi.
Audience Member: On the same line of testing, I feel like for mobile devices, we feel challenging are testing multiple devices at the same time, so synchronous browsing is something. You mentioned page reflow, but it has some iffy things, like some things work, some doesn't work in different browsers. So do you recommend any other tools or any preferred tools that you have?
Audience Member: No. It is synchronous browser kind of navigation. So if you are browsing in your desktop, same thing you can see in my multiple devices.
If you don't want to spend any money and you have an Apple, you can use Safari and plug in your-- at least your iOS devices-- if you plug them right in, you can literally do inspection with those devices right there without buying anything. So if you happen to have an Apple system. There's a ton of tools to do this stuff.
Honestly, we've been a little frustrated with all those tools, because it seems like-- there just seems to be some inconsistencies in the way that they work. Like we'll try to load up a page, and 75% of the devices will load it up, but a couple of them won't. And it's a pain, because you're over there trying to type all that stuff in on a tiny keyboard.
Testing is one of the reasons that it takes a lot more time to do this work. There's so many devices, and there's just new ones coming out every day. And so, partly we've mitigated that by being very intentional about testing while we develop.
So the devs, while they're writing code, oftentimes have a slew of devices on their desk, and they're working with them right there while they're testing things or while they're writing code. We also are pretty particular about building patterns of our code, like a pattern library sort of thing. And that gives you-- that's a really helpful thing in terms of testing, because if you know about CSS, you understand that cascade can be dangerous, too. Powerful but dangerous.
And if you make a little change, sometimes that change can ripple through and cause all kinds of problems. So a pattern library gives you an opportunity to, once you've made some changes, to quickly do a smoke test. Did I mess anything else up? All the modules exist in this one place, so I can go quickly look at them instead of having to navigate the entire experience to get to see what I did.
So that's helpful. That's all I can think of at this point. Anything else? Other questions before we wrap it up?
Audience Member: So sometimes when we present our designs to development just to see-- to collaborate and understand what's possible-- sometimes those designs are frowned upon. So what would you recommend?
Audience Member: So do you have any advice on how to collaborate a little better, or understand what the right design path is? Is it through usability testing? Is it showing that here are three design concepts, and we've tested these designs with our users. We want to solve the problem together. But how do you overcome that?
Audience Member: Yeah. I mean, it's not completely done, but it's just here's some ideas, here are concepts.
I have to be careful about it, and I need to recognize-- I need to be the kind of person that realizes that my work will be better if I work with the design team. But that needs to also come from you. You need to reach out to those individuals before you're done designing.
And I know you're not saying you're not done. But earlier in the process, get them into a room where you're sketching stuff on the wall. That's totally legitimate.
Their tendency upfront may be to say, we can't do that, we can't do that. Just say, OK, that's fine. Can you explain why? Start that conversation. Keep it positive.
And what will happen-- what I've seen, at least-- is that developers, they just want to be part of it. And so when they're included earlier, they're going to give you much more valuable feedback later. And honestly, developers oftentimes have the kind of input that can save you and your client so much time.
It's like the designer may be stuck on this one thing doing it in this exact way, and a developer might look at that and say, well, yeah, we can do that, but it's going to take a week. Like if we just did this slightly different thing, it'll take a day. Is that OK?
So that's the kind of give and take that you need. So I would say I would encourage you to try to get them involved sooner. I don't know if that helps.
Audience Member: Thank you.
Audience Member: Those little cameras that some of us got that did the early registration, I think, can really help with the remote collaboration. You can sketch with those things and share across offices. I'm really looking forward to working with those.
And I think to Ben's point, the sooner you can get development involved-- I think a lot of designers, we feel like we want to protect our work because, hey, we're the designers, they're not. And that silo needs to be broken down just as much as us being able to get in and--
--write some HTML and CSS.
We've got to let them into our little design universe, and not be so protective or feel like we lose our worth or value if we're collaborating with development.
That's that humility and empathy, right? Humility-- being willing to let other people into that process; and empathy-- understanding how the things that you do are going to impact the rest of the team. So that's critical stuff. Anything else?
Audience Member: One of the challenges we face-- we've got a fairly small team-- but one of the challenges we face is that selling the concept of kind of a lean process, of getting everybody together early on and kind of going over a lot of it this and surfacing a lot of it to everybody else is a very difficult sell to some of the upper management only because it is a small team and everyone's extremely. So you could say, hey, I'd love to get these guys in a room for an hour maybe, or half an hour or 15 minutes even. But it's a very difficult sell to a lot of upper management.
And they say, no way. These guys are busy. They're doing really, really important dev work. They're not-- really, we can't pull them away. Any suggestions on how I might be able to sell something like that?
So I think it's got to be that balance between if you're just content with where we are, then maybe we can just keep going like we are. If you want to do something better, if you want to like push for something that's extraordinary, then we need to start working together. You have to. You can't do it on your own. It's a rare person that can do it on their own.
Anything else? Awesome. You guys have been fantastic. Thank you so much for the engaging questions. Thank you.