Tsilli Pines & Mark Hoffmann

Digital Creative Director, and Director of Interactive Technology at FINE

Tsilli Pines & Mark Hoffmann

Digital Creative Director, and Director of Interactive Technology at FINE Episode 28 Part 1

Episode Notes

Episode Transcript

Gary:
Hello, and welcome to Part One of Episode Twenty-eight of Design Edu Today, the podcast series discussing topics concerning the state of interactive design education at institutions of higher learning. I am your host, Gary Rozanc, Assistant Professor of Graphic Design at the University of Maryland, Baltimore County.

In part one of this episode we will be discussing design workflow and in part two we continue the conversation by discussing responsive web design and the web as a medium in contrast to print design.

Today we have two guests, Tsilli Pines is the Co-Founder and Director of Design Week Portland, the Host of CreativeMornings in Portland, and the Digital Creative Director at FINE. She’s been working as a designer for over 15 years and is passionate about the value of design and the power of creative discourse, and Mark Hoffmann, the Director of Interactive Technology at FINE. He has been coding for the web since 1995, when all the links were blue. He is also a cat enthusiast and occasional game developer.

All right, first I’d like to welcome Mark and Tsilli; thanks for joining us today.

Tsilli:
Thanks for having us.
Mark:
Hi, thanks.
Gary:
Before I dive into the questions, I want to give my guests and the listeners the impetus of this and the next few episodes of this podcast. Currently, I’m working on re-vamping the curriculum of two courses this summer: a standard Design Technology course where students learn the Adobe Creative Suite and a Beginning Responsive Web Design course. So, while the questions are going to be specific to Design Technology workflow and critiquing and testing Responsive Web Design, I feel a lot of my fellow design educators are struggling to find the right balance themselves with this stuff and I think that we’ll find this line of questioning useful. So, instead of teaching the Adobe Creative Suite, because there’s tutorials out there, everywhere from Lynda.com to Skillshare. I want to, instead of teaching that, I want to teach things that are much harder to find online, like workflow, which I define as everything from how you name files and use version control to using project management and communication tools. So, my first question is about design workflow. How prepared or under-prepared are entry-level designers when it comes to the basics like properly naming files, their naming conventions and do they use any kind of version control when you get them?
Tsilli:
On the design side, we don’t actually use version control here; we do use it on the development side. We do have a very structured way of managing files on our server and typically we give new designers the run-down on how we structure those folders; they’re basically organized by client and then by project and then within each project folder, we have all the phases of work so that’s usually administration that’s kind of broken out, discovery, which is the phase where we’re defining the project; design, production and post-launch edits. The production folder doesn’t have much to do with code because all of our code is managed in version control; it’s more production files on the design side, so here we have a process where we typically have three designers working on a new project, so the deepest area of the file management challenge here is in that design folder, within the project, and there we break things out to include original assets so that we can keep those organized and separate to rounds of creative, and within each one of those rounds we break it out the way that it makes sense, so often, in the first round like I said, we have three designers, so within that first round you’ll see three folders that are named for the designers because that’s how we keep things straight here: we know who worked on which direction for a client so we can see their original files there. As we move into later phases of work, it’s usually only one designer, so it starts getting organized a little bit more by the structure of the site and then, like I said, for the production piece, we’re usually just keeping final files.

We also have a production guide that we put together for hand-offs with developers, which I’m sure we’ll talk about later, and then final fonts, prep, PSDs for assets if they have some kind of special moves that make it easier to batch in its own Photoshop file, and post-launch edits get organized by basically the scope of work, so if there’s an addition of a section or something like that, then it has its own folder with its own PSDs. Each designer has their own method for doing version control on their own work, so, often you’ll see designers naming their files based on the client, the project and the phase of work, so we call the first round R1 and so files tend to get appended with R1 and then you’ll see some designers getting into a letter system where it’s R1A, R1B, R1C. Every round of feedback has a stopping point that you could go back to if you wanted to reference an earlier phase of work. We typically have a very, very well-defined critique structure around that first round of work so files tend to end up falling in line with that. The first meeting that we have is usually based on research and mood boards and so those files are their own flavor and then once we get into the actual development of the concept, there are three core critiques, usually unless we need a fourth, which sometimes does happen, and designers tend to keep files for the winning design in whatever they presented in that meeting gets put into the directory for posterity and so we usually have three versions until presentation.

Gary:
I have…thanks for that: that was a crazy thorough response. I love it! I do have one question about…it could be any kind of file but I’ll just use the fonts as an example. You’ve got a bucket of fonts sitting on your computer. Do you dump…so they’re sitting on the computer, but do you also then throw them into the assets folder that’s sitting with the client project, so now you have two copies of it, so those fonts then move along?
Tsilli:
We do. The ideal scenario is that we have a central repository of fonts that the studio owns on our client server, which are a resource for all of our designers, although now of course there’s Typekit and there are all these other ways to access fonts through the Creative Suite which we also utilize, but for the core assets of the studio, we have those organized centrally, then designers do have some local fonts and then also use Typekit and when we close out a round of creative, the ideal scenario is that the typeface and any other core assets depending; we’re talking specifically right now about digital, so this is less of a thing, but with some of the print work that we do, you could have all of the original files for the links that you’re using in an in-design file or whatever supporting files that you need for it to be self-contained because for us there’s commonly a project that resuscitates from the dead a designer who worked on it originally is either no longer at the studio or is busy doing something else and someone else needs to jump into it and it basically needs to be this self-contained universe that can translate directly to a new designer and give them everything that they need to work on the project without any of those holes where you’re searching for a typeface or you’re searching for an asset; it kind of needs to all be there.
Gary:
Great, because I struggle with that with the students and the other one that came to mind is photos. So, they all have their photos sitting in iPhoto, or however they manage it and then they end up using one for their piece but then they have to re-crop it and then they can’t find it so I just wanted to see how everybody handled that, so that’s good.
Tsilli:
For us, there’s often a central, like I said, a central repository of client assets and that’s both what we get delivered to us, because often the clients have developed an asset library of their own and then, in addition, we keep a folder of anything that we’ve purchased for them, the original resolution that we purchased so that you’re not ever hunting for that kind of stuff in a Photoshop file or losing the original resolution of that image.
Gary:
All right. So, I want to ask another question, and this is when I personally assign a project. I give students a design brief with project details and deadlines and all kinds of requirements and I neatly type all that up and put it on a blog-post for them. When you start working with a client, I’m pretty sure they don’t do that for you!
Tsilli:
That’s right.
Gary:
How does this process work at Fine? Is there a Project Manager or an Art Director that’s using something like Basecamp to start this? How does that work?
Tsilli:
We do have a whole phase of work called Discovery that is essentially, its purpose is to define all of the things that you are defining for your students and eventually to come up with a core strategy and a brief. We have a couple of folks who are on the front lines of new project and they tend to be either the Partners or senior level folks in the studio and they, in initial sales conversations, will be starting to define roughly what the shape of the project is. And then there’s a whole process by which they start pulling in the core team at the front end which includes the original person that brought in the business, so that’s typically again a Partner or Strategist that has already been kind of starting to wade into the shape of things and put a scope of work together; they pull in a Project Manager, a Creative Director gets pulled in and often a senior level Tech person when there’s an exotic new thing about the project that is something maybe outside the level of familiarity that a Creative Director or a Strategist might have. We do have some pretty confident types of projects that repeat; not necessarily in creative product but in the scope and the technical configuration that we’re expecting and so there’s not always necessarily super-exotic technical stuff to be sussing out at the front end, but when there is, then the full range of disciplines is on board. And then we start doing interviews with the client to understand all of the various things that they’re trying to solve and this is a really mushy part of the process where a client can think that they’re coming to you for something but in fact, as you start digging into things with them, you’re uncovering all kinds of other dead bodies in the closet and realizing that the scope of the project is actually probably different than what they themselves conceived and then it becomes sort of a sales process of trying to essentially act as a consultant and advise them on the most strategic way to use their money. And then the portion that you’re talking about where you’re defining the brief for a designer to start on is something that the Creative Director gets involved with and together with the strategist, they’re understanding the opportunities and the challenges of the project and understanding the competitive frame for the project and basically coming up with a plan of attack.

Writing the creative brief is itself a really interesting challenge because I’ve gone back and forth with how specific to be about the strategy versus how much room to give people to inject their own ideas into it; being really specific means that you get to something a lot closer to your vision as a Creative Director based on what you understand of the client problem but it also means that if you have three designers working on something, you might have less diversity between the concepts. Leaving it more open is a risk in some ways because you may be going back and forth quite a lot with designers about whether they’re hitting the strategic goals of the project because they have less…they just have less nuanced understanding of the client challenges because they haven’t been in all those initial conversations at our studio at least; sometimes in some studios, designers are involved. Here, because we’ve found it to be really inefficient to have that many bodies involved, we tend to do a little bit of interpretation so yes, there’s basically a task-force at the front end of a project that’s doing all of that and it’s sort of the consultative and strategic side of the project before you even start thinking about design; you’re kind of getting your arms around what you might be designing and how you might have some opportunities to differentiate a client.

Gary:
Thanks. Again, I can’t tell you how helpful this is right now, to hear some of this. So that gives me…I want to ask a follow-up question to something you mentioned earlier, but also…I hand the brief to the students. I’d probably be better served as an educator going into class and saying, here’s my problem, this is what I think the solution is and then let the students then pitch me the brief.
Tsilli:
Yeah; it sort of depends on what you’re trying to train designers to do. Here, the skill of coming up with the brief is really left to the senior staff and it’s something you end up working your way up to and shadowing. Somebody who’s walking through the doors who’s recently graduated from a design program is not expected to have had any exposure to that whatsoever: their special move is way more on the side of they’ve been handed a brief, and what do they do with it? But if you have students that are interested in strategy then yeah, absolutely, that would be an amazing exercise and I think it would also give them a lot more empathy for what their senior staff is going through, to hand them something that neatly packaged. I do find that there’s a bit of a mystery for some people around, how does that brief come to be, and it’s taken for granted to some degree. So yeah, it would be an interesting exercise, for sure.
Gary:
All right, so the follow-up that I wanted to ask was, you mentioned after the discovery phase, you start pulling your teams together, whatever those teams are. How do you communicate in those team? Do you use Slack? Is it all internal? Do you have some kind of Project Management system you use?
Mark:
Slack it is actually; we wind up having…well, we’ve got a lot of company-wide Slack channels depending on the office you’re in or the type of job you have within the company, but then each project will get its own Slack channel that people can jump in and jump out of or just lurk in if they want to and we try and have as much discussion in there as we can for everyone to see if possible, unless you’re gathering for a meeting elsewhere so that if somebody’s heads down working, the Slack channel can just compile this information for them and they can come back later, read through the discussion that somebody else had and benefit from it that way, without having been interrupted beforehand, so I’m not sure whether or not something like Slack can scale or if it can be used in a scenario if you’re not able to trust the entire workforce to not just be in there all day having a great time but for us, it’s been great and has been a really natural sort of progression of communication techniques over the years, starting with the most basic of IM and how we were trying to use that in a very similar way: slack really fills that role for us.
Gary:
The reason I asked that question is, Graphic Design had this ebb and flow; at one point it used to be like, there’s a conductor and there was an orchestra and you had to have people setting type and manipulating images and doing paste-up and so it was this big conglomeration, but then it became like the solo rock-star, once the computer came out. Now it’s going back out again where it’s a team sport and right now in design education, we’re still stuck in that team…in that solo rock-star mode and anything I can do to make students work together as a team or understand the team concept of design is basically what I’m trying to do.
Tsilli:
Yeah, that’s great. We don’t actually use a lot of pre-baked tools for project management; we have this very custom put-together series of processes where a lot of stuff happens in Google Drive: a lot of stuff happens in Slack and then we also have a few supplementary tools that help us track time and resource, so it’s this bubblegum and tape system a little bit because we found that no tool like Basecamp was actually meeting our needs, so anything that is considered for posterity or really hinging around feedback is put in a channel outside of Slack and the two channels that we use are Google Docs, where we keep the briefs and all of the client surveys and all of the stuff that you want the whole team to be able to access that is not the kind of file that needs to live on a server but is either text based or is spreadsheet; we have project trackers that show where we are in the phase of work and break-out roles and tasks so that everyone can keep up on when stuff is due. And then the other channel that we use is Redmine which is JIRA, it’s basically just an issue-tracking system and what that’s good for is when there’s feedback rounds, it’s helpful, I would say, in design to just keep a central source of truth for a piece of feedback that came back and how it was circulating back and forth between a project manager and a designer but where it really becomes super, super helpful is in production when design is interacting with development, where all of our QA is done through this ticketing system that allows us to create a queue for people to be working through. And again, also provides the history of what happened with a particular issue and how it was addressed.
Gary:
I’m glad you read my mind because that was one of the questions that I actually forgot to ask was, how do you record feedback and so thanks for reading my mind on that one, I appreciate it!

That’s all we have time for today on part one of episode Twenty-eight of Design Edu Today. I want to thank today’s guests, Tsilli & Mark for being so generous with their time. I want to thank the audience for listening and I want to thank the Design Edu Today hosting sponsor DigitalOcean and CDN sponsor Fastly for making the hosting and distribution of these podcasts possible. Finally, I want to thank the AIGA and the AIGA Design Educators’ Community for their generous support of my research that lead to this podcast series.

If you want to discover more about the Design Edu Today podcast and read the session notes and transcripts, visit us on the web at designedu dot today. You can also follow us on twitter at @designeudtoday, like our Facebook page or subscribe to this podcast through the iTunes or Google Play store. Thank you for listening to Design Edu Today.