Content planning and wireframing. Many clients don't want to hear about this?

Question

Sometimes I'm faced with clients who run away or avoid the content planning or wireframing. I hate to work with lorem ipsum, I need the content, I need to plan everything to design it, isn't this what is all about?

Most of website designs require a plan, however, I feel like some clients don't like to be charged for wireframing.

Should I just skip these clients, or is there an approach of convincing the client that having, planning and wireframing the content is the foundation of website design?

I rarely had clients who told me "I appreciate your professional way of dealing with this".

Most responses that I get when submitting wireframes are "Fine with me, let's proceed." and no other comments. It's to no surprise later that they require stupid layout changes.

How do you cope with this?

Answer 1

I'm not 100% certain this is related to "freelance" as much as it is to workflow. But...

I find wire framing critical. But it needs to often be explained to the client. At the very least the level of importance needs to be explained to clients.

• This is the skeleton or backbone of your site. It shows relative size and positioning for the general areas of content we've discussed.
• Approval of this structure for content will be the basis of further design.
• Changes requested at a later date which deviate from this backbone may incur additional costs and time to complete.

If a client passes it off with an "okay let's proceed." then later, when they want layout changes, it's my job to point to the wireframe and explain "you approved this" along with "there will be additional costs incurred".

Answer 2

I see two potential problems:

1: Your sales process and articulation of the value proposition.

2: Possibly your annotation and markup of the wireframes

Firstly you are separating wireframing and design, but they are both types of design. Secondly, if a client can't understand a wireframe then you haven't explained it well enough. We understand wireframes because we are used to them, but to a client it will be dry. You could use something like Lucidcharts to build a wireframe which is navigable - I use this and it's like Visio on the web for a hundred bucks a year.

When you pitch the job the first process is wireframing because this defines the layout and usability (both parts of the design) and, as Scott says in his answer, allows you to track deviations from the backbone of the proposed site.

Don't treat wireframing as something that is not necessary. I've moved away from calling it wireframing (i.e. the word 'wireframing' doesn't appear on the quote) and instead make it part of the design concepts phase. Clients seem more able to understanad the phrase 'design concepts' (you can still explain it will contain just the form and structure of the site).

Answer 3

I would agree. I find the answer to this is most often that they are paying an external service provider (freelance or agency) to take the time and responsibility away from themselves. They do not want to be part of the process as that is what they believe they are paying you for.

So in a way it is more that wireframing and UX are really agile parts often presented back into a waterfall process. You need to try and sell agile to them, and not that you have to do the whole iterative process all the way. Just that if they are part of the process at some stages then the product will grow around them and be a much better fit and sell better to customers.

I have seen this as a freelancer and as a contractor to an agency in the last 3 years. The bit that is a gamble on a project is will you get a good product owner at the client. Will you get someone who has the time to give you 1-3 days a week to do, not their normal job (which is often key, this project is not paying their bills or job description).

So I try to get better at taking small steps in with the person or people from the client at seeing if they get the concept and have the time. Some people who set up the contract are not the people who will use it and have no interest apart from getting a good price so it does not matter what process you give them the most they will do is regular visual briefings and sign off.

If you can sell agile scrum with Release planning meetings and then sprint planning meetings you know they will at least divote some time to planning with you and so may be open to understanding what ux and wireframes are. Most clients do not have the time or the vocabulary to deal with it. For example when as ask them to weight page blocks to a total of 10 they are just happy I do it.

So go with that you keep the wireframing as a cost and be happy they dont engage and that you have had them pay for more up front thinking by you. Or you keep it all in house and dont charge for it. Give clients 10 years more and some might be more into the process.

Answer 4

I like the way Scott answers defines what wireframes are in simple terms.

However, it might still have very little meaning to the customer.

Like many new things, because if you never show an example, the customer might understand/interpret it "his own way". For instance, when presenting the wireframe to the customer, this person will think it is "the design" (whatever it means for the customer).

Hence, I feel that the best way to explain is to simply show a past project (or fake project) going through all the steps: from ideas/brainstorming, to specs, to wireframes, to more specs, to updated wireframes, to photoshop, to code implementation. Each of the steps should be illustrated by the relevant documents (screenshots).

I also like to emphasize something like "Keep in mind that the mockup phase is as important as the coding phase, if not more, as it sets the foundations for all the rest of the project."

As mentioned by Scott, this should also be part of the contract with statement such as "changes requested at a later date which deviate from this backbone may incur additional costs and time to complete (if going over the agreed maximum number of revisions)". You can kindly remind the client of this statement, explaining that it protects both parties from deviations in the project (for the client: unexpected/unjustified overtime hence bill. for you: change of spec in complete contradiction with vague UX/UI requirements).

Here is an example for Amazon's product details page

The Mockup

The Design