Developer's Brief through the eyes of the customer
Are you satisfied with your brief on the development of sites? He gives answers to all your questions, everything is familiar and familiar in him, and it seems that you can’t think of anything better. But you understand, it is important that the customer was satisfied. Sometimes it is worth a critical look at your brief: is it really understandable to the customer and adequate to his needs and abilities?
We asked customers who place tenders on our portal what they like and what annoys in the developers' briefs.
')
Content of brief
According to customers, in addition to all sorts of technical details, the brief should clarify:
Brief should not have a marketing, design or technical skew. Not every company has a mission and values, not everyone knows the advantages of competing products. And why are they a developer who is not ordered content?
The customer is not obliged to know in advance the hierarchy of nesting of pages and the connection between them - for this, you just need a developer who understands usability issues and all sorts of different things that the customer does not even suspect.
Sometimes the questions of the brief are so complicatedly worded that the customer needs a translation from IT to Russian to answer them. By the way, the developer’s contacts in case something is not clear from the brief’s text should always be in the brief’s footers.
Scope and structure
Don't get too into details. If the brief exceeds 10 pages, it scares the customer.
Well, when the questions are structured into logical blocks, and do not go one endless list. Some developers make separate briefs for design, but this is already superfluous (if you are just not a design studio), because The customer is interested in the final product - site. Or another extreme - to include in the brief on the site questions on the development of corporate identity or company logo. After all, the visual identity of the brand is a completely different story, which requires completely different competencies than when creating a website. If the developer puts the development of the logo on a par with the creation of the site, the question immediately arises how much he can do both of them ...
Visibility and closed questions
It is easier to judge customer preferences by evaluating other sites. Let the customer say what he specifically likes or dislikes in each given example. This will help to understand whether his preferences are aesthetic or if he was attracted by some functionality, technical solution or the ability to solve his practical tasks.
The developer looks unprofessional when he asks the customer to draw a sketch of the expected project in the brief (yes, it happens !!!) If you are interested in how the customer sees the website page, you can ask questions about the ratio of graphics and text, the position of the main menu, the number of columns, etc. The skeleton layout of the main and secondary pages of the site even before the designer starts working will help to discuss the layout of the main elements of the page.
Conveniently, when the brief contains options for answering questions. The customer, perhaps for the first time in his life, makes a website, and it is difficult for him to figure out what types of websites there are, what basic modules he may need. You can add your answer if necessary, but more often it is enough to put a “tick” (active content in Word to help - who is not afraid to use it!) On the other hand, developers may be too creative in this. For example, in one brief, rather controversial pictograms are used to determine the customer’s visual preferences:
Rereading your brief with a fresh look never hurts: soberly assess the content of the brief, volume, structure and visibility. Let the grandmother read it and ask if it is understandable to her.
We asked customers who place tenders on our portal what they like and what annoys in the developers' briefs.
')
Content of brief
According to customers, in addition to all sorts of technical details, the brief should clarify:
- list of materials provided by the customer;
- wishes to the functionality of the site;
- the contents of the main page;
- availability of language versions of the site;
- the need to develop content;
- lead times;
- indicative budget.
Brief should not have a marketing, design or technical skew. Not every company has a mission and values, not everyone knows the advantages of competing products. And why are they a developer who is not ordered content?
The customer is not obliged to know in advance the hierarchy of nesting of pages and the connection between them - for this, you just need a developer who understands usability issues and all sorts of different things that the customer does not even suspect.
Sometimes the questions of the brief are so complicatedly worded that the customer needs a translation from IT to Russian to answer them. By the way, the developer’s contacts in case something is not clear from the brief’s text should always be in the brief’s footers.
Scope and structure
Don't get too into details. If the brief exceeds 10 pages, it scares the customer.- Firstly, it suggests that the developer does not know how to highlight the main thing;
- Secondly - that he shifts his tasks to the customer;
- Sometimes a diligently filled brief turns into a real problem for the developer himself, because some requirements are difficult or incompatible with each other;
- In the end, you need to keep yourself a little freedom for creativity!
Well, when the questions are structured into logical blocks, and do not go one endless list. Some developers make separate briefs for design, but this is already superfluous (if you are just not a design studio), because The customer is interested in the final product - site. Or another extreme - to include in the brief on the site questions on the development of corporate identity or company logo. After all, the visual identity of the brand is a completely different story, which requires completely different competencies than when creating a website. If the developer puts the development of the logo on a par with the creation of the site, the question immediately arises how much he can do both of them ...
Visibility and closed questions
It is easier to judge customer preferences by evaluating other sites. Let the customer say what he specifically likes or dislikes in each given example. This will help to understand whether his preferences are aesthetic or if he was attracted by some functionality, technical solution or the ability to solve his practical tasks.
The developer looks unprofessional when he asks the customer to draw a sketch of the expected project in the brief (yes, it happens !!!) If you are interested in how the customer sees the website page, you can ask questions about the ratio of graphics and text, the position of the main menu, the number of columns, etc. The skeleton layout of the main and secondary pages of the site even before the designer starts working will help to discuss the layout of the main elements of the page.
Conveniently, when the brief contains options for answering questions. The customer, perhaps for the first time in his life, makes a website, and it is difficult for him to figure out what types of websites there are, what basic modules he may need. You can add your answer if necessary, but more often it is enough to put a “tick” (active content in Word to help - who is not afraid to use it!) On the other hand, developers may be too creative in this. For example, in one brief, rather controversial pictograms are used to determine the customer’s visual preferences:
Rereading your brief with a fresh look never hurts: soberly assess the content of the brief, volume, structure and visibility. Let the grandmother read it and ask if it is understandable to her.
Source: https://habr.com/ru/post/124626/
All Articles