What’s your company’s design process?
Maybe a stakeholder says, I want this, or we need that. Maybe there’s some market research or looking at analytics; probably not. The designers then jump into Photoshop, making what the stakeholder asks for page by page, comping each page in full each time. The stakeholders have a few random comments, but generally approve it since its exactly what they asked for. Then its handed to developers as a complete package with little explanation, where they sort of make it look like the comps but there’s many unresolved questions about the functionality or reusability. And most of the time, too many problems arise in fleshing out requirements and getting it through testing and it never launches, or it launches months later than it should and no one’s entirely happy with it.
User experience research and using a more lean, agile model can ease these problems. Making something look good is important, but making something that helps users meet their goals and is developed and iterated on quickly is even more important.
Maybe you can’t get user experience research buy-in. Usability testing, why would we need that? There’s another way to stop the pain, and tends to be easier to get people to bite.
Stop making full-page comps.
Does this seem counterintuitive to you? Stakeholders often want to “see” the fully developed product before “handing” it off to development, because development resources are highly limited and expensive. But it costs more to do it this way in the end and is very frustrating for everyone involved. Just outline the problems this system is causing, if you are using this system I’m sure you’re already well aware of the issues it causes. Maybe 90% of people are doing full-comps still, but does that really justify the practice?
Instead, try this. Comp up a single library of reusable components and modules. Shocking! The developers will almost immediately jump onboard. Why? Because making things consistent is much easier to program.
You probably already have an existing site or project. How do you transition? First, go through the project and start just making a list of components that exist repeatedly. Need a starting place? Look at something like Twitter Bootstrap or the Mailchimp. Then, make a single styleguide and component library in Photoshop or your design tool of choice. (Or even HTML/CSS!) Then, as you add new features or change things on the site, just update the component library. For each new or updated feature, add new components, remove components no longer being used, change components and show changes that need to be made to existing to components.
But then how do the developers know how to build it, you ask? I mean, you are wireframing, drawing flow diagrams, and listing out acceptance criteria, right? If you aren’t, start getting into that practice. With wireframes, flow diagrams, the acceptance criteria, and the component library, the developers will know how to combine those things to produce the product.
But what if I need a special graphic for this situation? Okay, take a screenshot, or make a rough comp of the external elements, and build that graphic. This isn’t all or nothing, its about changing the main habit.
What if I need a change? Just add it to the component library after the ‘main’ component.
But what if a stakeholder insists on seeing a full comp? Fake it. Focus on making the component library the true source, and build out the full comp as quickly as possible. They probably don’t want to see a full comp for every page in reality, just the big pieces. So then just fake it for those parts. After all, they aren’t looking to see a demonstration of Photoshop skills. They are looking for a visual of what their idea would look like.
Cut down your own work down to a third. Cut development time down in half. Be more agile. Smooth communication. Deliver wireframes, diagrams, visual component libraries, acceptance criteria, and the occasional graphic or comp. And in the process, accidentally integrate some of the agile and user experience processes into your team’s workflow.
Questions, comments? Let us know!