Designers vs PMs: Who creates proofs in your org?

[Ryan_McGee]

We are rolling out Proof and are looking at how other firms have their process running. I've seen two main flavors in reading other threads: 1) Designer uploads document to project, and creates proof/triaging. Edits comes back to them via the decisions. 2) Designer uploads doc to project, and PM creates proof/triaging. Edits filter through PM to designer as a task or external process. My instinct is that #1 is the smoothest path, but am willing to hear other thoughts from existing users! Ryan McGee

[JustinWh]

We use Proof quite a lot, and path #1 is the one we take. This reduces touch points for us, and keeps the feedback direct. Project Managers only get involved with a proof if things are not staying on track. Justin White

[KRISTINEPU]

#1. The only difference here is that the Traffic Manager/PM is also a Reviewer/Approver. Kristine Punga

[feleqyan]

Are you using Adobe apps? If so, I'd recommend to take a look at "https://exchange.adobe.com/creativecloud.details.14393.html" Workfront's extension for Adobe CC . With this integration, designers can upload docs and create proofs right from within Photoshop, Illustrator or InDesign. Hayk Falakyan

[MargaretSt]

Our project managers generate the proof, send it to appropriate stakeholders and notify Traffic when all revisions/comments are final. Traffic then adjusts the schedule as needed and the designer accesses the proof to implement the revisions. We have such a high volume of projects and daily deadlines that the designers would constantly be bombarded with notifications regarding all the changes and also feel like they have to work on those projects even though they don't have a task for it yet. It's just too distracting for the team. One of the responsibilities of Traffic is to buffer and minimize the distractions so they can concentrate on their work. Margaret Stanek Tech Data

[JillAc]

Hi I'd like to jump in on this topic because we have a couple issues with this too and I'm hoping for additional experience from people. Sometimes (ie "the exception") the PM creates the first proof when it is a revise of something old with changes to communicate to the designer, and in that case the PM is by default the "owner" of the proof, and that ownership stays with them even when a new version is uploaded on top of the original PDF – ie ownership is always based on the first person to upload the proof throughout the life of the proof. The owner can not get a custom message notification when shared (in this case the PM), unless the ownership is manually changed back to the Designer when the Designer uploads V2. That has proven difficult to train on because it is an exception when that situation is in play. Confusion all around. We have another issue I'm grappling with – because the Designer is the owner of the proof, the proof can never be shared with them (ie they are the owner, so it is already technically shared) and so when a round of edits is complete and the designer is notified via Update that it's time for make the edits and post the next version there is no way to set a deadline in Workfront to keep track of when that next round of edits is due. We can't make tasks for every round of edits in the Project, that is just cumbersome and overwhelming as most projects go through 5-10 rounds and you would need up to 20 additional tasks to track every single round of backs and forths. So the question is – how do people keep track of the "owner" – ie the Designer's -- due dates? "https://www.expeditions.com/"> Jill Ackerman Lindblad Expeditions, Director, Product Marketing 96 Morton Street | New York, NY 10014 Ph. 212.261.9080 jilla@expeditions.com | "http://www.expeditions.com/"> www.expeditions.com "https://www.facebook.com/LindbladExpeditions"> "http://instagram.com/lindbladexp"> "http://twitter.com/LindbladExp"> "http://www.youtube.com/user/lindbladexpeditions">

[CalvinFold]

Our design/production users created the PDF for proof routings (from Adobe apps), which are then provided to the Project Manager. PM reviews, then uploads and manages the proof routing; Design/Production is not involved in the proof routing. The Project Manager will go through the comments made on the proof routing, provide feedback/direction, and provide a PDF back to design/production to work offline. They basically serve as managers as well as a filter for the feedback (resolving conflicts in changes needed, etc.). Design/Production makes changes and re-provides a PDF to the PM. A new proof routing is started. We keep each "round" separate and don't recycling proof routings via versioning. This keeps the paper trail clear for all parties involved. It may make a difference that we're a consumer packaged goods company; Legal and Regulatory compliance require a fair bit of checking, double-checking, clarifying, and being sure at every stage with a clear trail of responsibility. I suspect we'll try to streamline in the future, but we're new to Workfront and it was much cleaner to adapt our current process requirements. Baby steps. Probably will wait until PHQ reporting into WF is much, much more robust. I really don't see us going with Designers uploading/managing proof routings; they do best when not shackled to managerial stuff and left to do what they do best-create. Kevin Quosig

[KRISTINEPU]

Jill, We have tasks for each round of proofing. That way the schedule is set and the Traffic Manager only moves dates if the proof is late or the proof feedback is late from the client. Everyone knows the schedule and what is expected going in to the first proof. Kristine Punga

[KRISTINEPU]

Kevin, Regarding #5 - interesting about a new proof each time. I love the feature of side by side versions of proofs so I can make sure all the comments are addressed. Our clients like it too. Do you ever run into issues with that? Kristine Punga

[CalvinFold]

Hi Kristine, Right now, features like versioning would cause more confusion than help, especially amongst reviewers (who are mainly not part of our group: Sales, Brand, Legal, Regulatory, and so on). Folks often keep previous versions on their own (PDF and prints). We also have a dedicated Proofreading team that not only proofreads, but verifies changes from the previous round are made. PM also verifies changes are made before uploading the next round revised PDF. I'm sure some might find versioning useful, and as we all grow into the system, it's certainly an opportunity for streamlining. Part of the problem we have right now, which will be a roadblock to "getting fancier" with PHQ, is the awful reporting back to WF. Our users do not have access to doing reports in PHQ, and the data available from PHQ-to-WF is severely lacking to use WF's reporting (goodness knows I have tried, as have Support and our WSA). So we're already straining to do proper tracking and reporting to meet the needs of PMs and Reviewers; versioning opens up another headache we can't add to the Heap of Confusion. ;-) Due to the nature of our design work (and the level of redundancies), there is still alot of paper involved, so generally not an issue, even if it looks inefficient. Kevin Quosig

[JillAc]

Side by side reviewing is a key reason our staff likes Proofing and are now rejecting PDFs being emailed. Unfortunately we have too many people and staff and no dedicated traffic person to keep up with all those extra tasks that would have to be created to track each round, and they can go on for so long and so many times, and getting people to mark their tasks done is a serious problem so that would just add to the frustration. But this is a real problem for us, the inability to set a deadline in Proof when alerting the designer (ie proof owner). Also we don't have the Designer doing any sharing other than with the PM –the designer is responsible for uploading it into Proof and sharing only with the PM who then manages the approvals process by sharing it out to the right people and then managing the comments before telling the designer it's time for the next round via Update. Having the designer upload the proof eliminates a step of emailing a PDF.