How PSDs get you into trouble.
In our industry we commonly provide clients with some form of high-fidelity visual prototype of what they want to build. We use these prototypes to guide the discussion and gain feedback. However, these visual assets (often Adobe Photoshop Documents (PSDs)) can have both favorable and unfavorable consequences.
To be clear, a PSD can mean any high-fidelity visual representation of screens, regardless of software. Over the years we’ve learned the communications pitfalls, and as a result, the best practices for using PSDs.
It’s A Trap
For projects where we build real, functioning applications, our designers map out the pages we need with guidance from the client. They sketch out these screens and the related interactions on pen and paper or a whiteboard. Once they feel confident about their direction, they move to Photoshop or other tools to build low fidelity wireframes. We show these wireframes to the client to get feedback, and make tweaks as needed. If style or brand guides don’t already exist, we work with the client to develop these as well. We can run into problems when we start to add the visual styles to the wireframes in Photoshop.
So What’s the Problem?
PSDs provide a snapshot of a point in the evolution of your product, but they have little value as product documentation. Your app may look like the PSDs when you first release, but your app will change as your product evolves.
Constantly updating the PSDs to match the software changes wastes valuable time that designers could use to design new features or improve the actual code. Using screenshots from the actual software provides better documentation.
Rather than spending your client’s valuable time building PSDs, spend that time building something deliverable in the actual application. As an agency, we want to provide as much value as possible for a given client at (or under!) their budget. This means we spend as much time as possible delivering working software. You can’t incorporate much of the output of a PSD into the actual working software. Building a simple and static HTML/CSS mockup of a functional page gives you code that you can use in the working product, while also effectively communicating how the page will look.
Additionally, adding a component to a high-fidelity design does not reflect the effort required to add that same component and associated underlying functionality to the real software. Even when we build our wireframes, we carefully prune them to make sure they do not imply more functionality than the client requested. While it may take one minute to add a button, it may take a month to build the functionality implied by that button. If you do not explicitly call out that addition (and its addition to your scope and budget), assume the client will expect that implied functionality. This must be communicated at the time of delivery, or you risk client dissatisfaction.
Unknown Implementation Challenges
Finally, PSDs don’t help you and your team identify potential implementation pitfalls. At the point you build a PSD, you can’t see the development challenges you will encounter while trying to deliver that design in working code. If it turns out that you can’t implement the design as shown in the PSD, expect disappointment from your clients. We learned this the hard way, when on one of our clients hung the printed out PSDs in his office as soon as we delivered them; he told everyone he met that MojoTech was building those. You can imagine his disappointment when certain things did not exactly match the PSDs, even though the software we built delivered the same value to his users. However, we failed to communicate the intended purpose of the PSD, and thus we learned a valuable lesson. Even if your final software has a better user experience than the original PSDs, your client may still express dissatisfaction. Expectations have a powerful effect.
Avoiding The Trap
Given these potential pitfalls, how do we minimize this risk and make sure we have happy clients? We use a few different delivery and communication strategies to make our projects run smoothly.
Deliver Low-Fi Wireframes
We deliver low fi wireframes to give our clients the concept for the layout and pages that we’ll build. This way, we begin our journey to a working product on the right track. At the same time, it ensures that we spend minimal time delivering work that doesn’t translate directly into working code. We use these wireframes to gather feedback and make sure that our initial product will have the right screens and features.
Give Clients a Style Guide
We create a style guide which abstractly communicates the intended visual design. This shows the client that we have fully specified the initial version of the product we will build. We have communicated the layout of the screen using the wireframes, and we have specified the visual styles of the product using this style guide. However, we ensure that our clients don’t have the powerful expectations that PSDs (especially those hung on an office wall) convey.
Apply Styles in Code
Perfect the Right Thing
Since our designers can code, they wait to make things pixel perfect until we know we’ve built the right thing. Near the end of the project, once our clients express satisfaction with the functionality we’ve built, we save some time for our designers to go fix the design debt that has accumulated throughout development. This way, clients get not only a product that meets all of their functional requirements, but also a product that looks great.
In our experience here at MojoTech, following these communication and delivery strategies will enable you to better manage expectations, build great products, and keep your clients happy.
~ Drew Jankowski, Product Manager (@JankYourChain)