This is a transcript for The Dirt episode, “Design Process and When to Abandon a Tool”
Steve: Oh, I want to talk about it so much. Let’s watch it right now.
Tim Wright: Hello, and welcome to The Dirt. I am your host, Tim Wright, and
I am here with Mark Grambau.
Mark Grambau: Good morning
Tim: And Steve Hickey.
Steve Hickey: Howdy.
Tim: And, as always, we are reminding you that when someone at work calls you passionate, they really mean you’re an asshole.
Steve: That explains so much about how I’m treated.
Tim: Today, we’re going to be talking about a piece of the design process that I know Steve and Mark are active in currently, when to actually move from tool to tool. So we have different, not clear-cut, phases. We have a sketching phase, a wire frame phase when you jump into Photoshop or Fireworks, or if you go straight to prototyping, and then production code. And we want to talk about when you move from one to the other. Yeah, Steve.
Steve: So I gave a talk at Future of Web Design in October, and one of
Tim: That was kind of douchey, but go ahead.
Steve: Thanks, Tim, valuable set up. [SS}
Tim: Hey, not to talk. Okay, okay, so, okay, we’ll wrap up to make it sound like Steve [inaudible 0:01:16]. So, hey, Steve actually gave a talk that’s sort of relevant about this, the future of web design. Steve, do you want to talk a little bit about that?
Mark: Yeah, Steve, give us the run down.
Steve: Yeah, let me start over again.
Tim: If you want to mention the book that I wrote, too.
Steve: Yeah. No, I don’t want to talk anything you did. So I gave a talk at Future of Web Design in October, and one of the things I said during my talk was that I didn’t advocate for a use this tool, then use this tool, then use this tool kind of process, where by the time you hit code, why would you ever go back to Photoshop? And that was one of the things I got the most questions about afterwards, like, “What do you mean?”
I mean that sometimes when you’re working in one tool, you find a
problem that’s more easily solved in a different tool, and you should not avoid going to that different tool just because you’re in code at that point.
Mark: Yeah, I agree. I think that folks get really pigeonholed, or it’s really self-imposed. You’re very pigeonholed if I have to keep doing this in the thing that I’m doing, regardless of its strengths and weaknesses. And the important thing to remember with all these tools, be them coding, languages, mark up languages, or pieces of Web or desktop software, is that they are all going to excel in certain places and have holes in others, by design, and that makes a good product. They’re not all meant to be all things for all people, and it’s important to note when you are pushing against the walls of a piece of software or a tool to your detriment. There’s a point where it’s good, because you’re getting so much out of something, but then there’s a great point. I think Photoshop is really guilty of this as a tool, and part of the process where you’re using it and you’re using it, and you’re doing more iterations from the client, more changes, and as the file grows and grows and grows, it becomes cumbersome to apply stylistic changes across the board. That’s changing with CC, with some of the cascading styles that you’re able to do for type, as well as the very recent update they did to update how smart objects work, where they carry over like symbols across documents, but there is a natural wall that you start to hit.
Tim: Have you guys ever thought of trying McCaw for something like that?
Steve: McCaw doesn’t have symbols.
Steve: That’s all I have to say. So Mark and I are both working on an interactive mapping project right now, and we’re running up against one of
those walls, basically yesterday we’ve hit it, where I’ve been working in Photoshop for about a week and a half, and we’re talking about making
changes to elements, and it would be massively easier to just apply those across a style sheet instead of me going back through every layer and every folder in my file to do it. So basically when Photoshop starts costing you time, that’s probably a good time to move into code. And when any of your tools start costing you time, it’s time to move into another one, might be a good barrier.
Tim: Yeah, I think using the best tool that will communicate the message more efficiently. Like, we were doing The Dirt page, we’re redoing The Dirt page on the website, and I was in Fireworks doing it, and part of it I just wouldn’t be able to build in code fast enough to say like, “Hey, take a look at this and see what you think.” Yeah, there’s an in line player that’s like a pie chart closing in. It would take me much longer to build that than to just put a little thing in there and explain it.
Mark: Draw a triangle and some circles?
Tim: Yeah because it’s not like a weird thing. It’s like, oh, you hit play, and the thing goes around.
Steve: Some ideas flow better in a visual editor workflow idea, and other ideas flow better when you’re just pounding some code out. Like, I really appreciate the idea of design in the browser, and it’s a part of my workflow at times now, but the guys who sit there and say, “Don’t ever touch a visual editor, just do everything in the browser,” they’re deliberately depriving themselves of a tool that is actually incredibly valuable for solving a lot of problems.
Mark: Yeah. To your point, Tim, about the way that the idea is best communicated, it’s important to remember that communication is a two-way street. In a situation like what you were talking about, where you’re mocking up The Dirt, you were showing it to me and showing it to Steve and showing to Neil, our design director, just to get some feedback, and you’re sending it to an audience of people who know what you’re trying to say, because we are savvy enough to understand how this is going to work in code. You don’t need to communicate the behavior to us, at least not at that stage.
While on the project that Steve and I are working on, we’re also working with one of our outstanding developers, Sarah Caneso [SP], working on showing the behavior of this application we’re building. And, Steve, what you’ve been working on is really aesthetics and design system, but we also know that animation and movement and the dynamism of this application is important to communicate. We could’ve been trying to code both the design and the animation right from scratch from the get go altogether on the browser, but it is limiting, and so Sarah has been able to focus on doing demonstrations of how the application behaves and feels. You focus on the design, and then it’s up to us to communicate properly to the client about what each of these pieces is meant to communicate, so that we can show them something very early on to communicate how it will all come together later.
Tim: And I think there’s a difference in team dynamics versus just one person working on something.
Tim: And I almost feel like design in the browser is this is the designer, and this is the person who’s going to do all the front end code for it.
Tim: If you have a design, like on the map project, you have a design team, and then you bring a developer in, those documents that you produced are very important to communique. And then that’s when I think the wire framing, the Photoshop and everything is a communication tool.
Steve: There’s a huge difference between how a single person works and how three or more people work. There’s just the division of tasks.
Tim: I work with no pants on, and I have to wear pants when I come into the office.
Steve: Yeah, it’s a real problem, being forced to wear pants in public.
Tim: Honestly, it itches all day.
Mark: That’s a sacrifice we’re all forced to make, pants.
Steve: Yeah. And another thing that I think is worth pointing out is that we advocate a process that is heavy on prototyping at the end, where we produce a prototype for people, and the most confused aspect of that process seems to be that when I talk about it, people assume I am saying “the prototype,” and what I really means is “a prototype.” It doesn’t mean the product of a design process is always a single monolithic thing at the end, like, “I started a prototype after I did enough other work, and here’s the prototype three weeks later.”
So you might prototype individual pieces of behavior. Maybe you
prototype just how one aspect of the application behaves, or you prototype another piece. It’s more thinking of the pieces you build during your process as studies rather than monolithic pieces. It’s like you can do a design study and come up with little chunks of visual form and then start fitting them together, and then do the same thing with code, and all work towards, at the end, finally assembling one thing that works.
Mark: Yeah. And we work with clients where we have a WordPress shop that we work with, if our project requires WordPress sometimes, and we’ll hand off many prototypes to them. Like, if we have some card flipping interaction,
or we designed a new form of a modal on a project that should be launching pretty soon. And it was tough to describe, because we haven’t really seen it in the wild before. So we built a little prototype, and we sent it to them, and they used the code for it, which was really nice, and that was a great communication tool. It was more than a communication tool, because they actually used the code for production, but that style of prototype is also the style of prototype where you can throw the code away, that it’s purely for communication.
Steve: Yeah. There are things that you can write how something works in code faster than you can write several paragraphs describing to somebody how it works, where something will be lost in translation. Just handing
somebody a snippet is great for that, like, something like CodePen [SP] is really good for that, too.
Tim: Yeah, CodePen’s nice.
Mark: We had a similar situation, if you’ll recall, Steve, about a year ago, working on a gaming project that is currently on our home page as a case study. This product, called Incantor, a game. We’re not game designers, we’re experience designers, but they want us to work on this because of our just sort of open eyes and general experience knowledge. And this was something where we were doing design, we were doing development, and we were doing sort of structural and story design, but we were also working on animation. One of our great apprentices had some After Effects experience and mocked up some of the animations that were really key to the experience to make it deliverable and show the clients, saying, “We’re just coding sort of a style guide and concepts and helping you build the idea
here. We’re not making the production code for you, but this will help
explain how this is going to function.”
Mark: Yeah. And lastly, I want to talk about, Salesforce has a really great sort of interactive style guide for their Salesforce One application, and we’ll throw a link to this in the show notes, that has built a traditional style guide. It’s listing out hex codes for the various brand colors and whatnot, and typography, but it’s also semi-interactive, in that you’re taking chunks of code and animation and showing how an experience is supposed to occur, and it’s a really great interactive way of communicating both the design you’re trying to say, as well as little chunks of functional elements. I think it’s a nice combination of using the design, where it’s helpful in communicating animation or behavior, where it’s helpful.
Tim: That is a nice little style guide.
Mark: Yeah, they did a neat job with it, talking about all the parameters. So this is a little outside of our main topic here, I understand, of when to push against tools, but I think it’s a nice result when you understand that balance properly.
Tim: Yeah. So I think the summary of when to move from tool to tool is when you can communicate better, or when you start to feel things getting tedious in one tool, then just kind of jump to another one. And basically it’s all about communication. You have good communication… [SS]
Steve: Don’t do Photoshop just because you think it’s Photoshop time, is basically how that works.
Mark: Oh, agree. Yeah, some of these tools get hampered by their names. People think Photoshop, I have to only do graphical things, or Illustrator, I can only do illustrations. The fact is that Illustrator is really great at combining complex vector shapes, so maybe build your vectors in Illustrator, then bring them into Photoshop or save them as an .SVG.
There’s a lot of options.
Tim: Know your tools. Know what they’re good at, what they’re not good at, and know when to abandon them and pick them back up again.
Tim: That’s good. So we have an event coming up here at Fresh Tilled Soil. It’s called Experience: Dev. It is a one-day conference for managers and C-level folks and whatnot about development and relationships on managing development and design teams. It’s going to be super cool. February 27. Tickets are on sale. They’re super cheap, so there’s no excuse for you not to come.
Mark: Why aren’t you here already?
Tim: Why aren’t you here, indeed. It’s here at the Watertown office. You can get more information at freshtilledsoil.com/experience-dev. As always, you can get us on Twitter at The Dirt show, and, for the love of God, please review us on iTunes.
Mark: Or else Steve might be forced to just do things he just doesn’t want to do.
Tim: If you review us on iTunes, Steve, will show up to the conference shirtless.
Mark: And if you don’t . . .
Steve: That’s how I come into work every day.
Mark: Good point.
Tim: Yeah. So I think that’s all we have for today. Thank you listening, and we will try and do better next time.
Tim: Think of a story, think of a story. Feeling… for some reason, I have Smurfs in my head. Smurfs eating mushrooms, Smurfs getting high…
Gargamel. That’s all I have.