Ένα σωστό brief κατασκευής ιστοσελίδας δεν είναι λίστα με χρώματα και σελίδες. Είναι το έγγραφο που εξηγεί ποιο επιχειρηματικό πρόβλημα πρέπει να λύσει το νέο site, ποιοι άνθρωποι θα το χρησιμοποιούν, ποιες ενέργειες πρέπει να ολοκληρώνουν και με ποια κριτήρια θα παραληφθεί το έργο. Όσο καθαρότερα αποτυπώνονται αυτά πριν ζητηθεί προσφορά, τόσο πιο συγκρίσιμες γίνονται οι προτάσεις και τόσο λιγότερες κρίσιμες αποφάσεις μεταφέρονται βιαστικά στη μέση της ανάπτυξης.

Το brief δεν χρειάζεται να υπαγορεύει την τεχνική λύση. Χρειάζεται να καθορίζει το αποτέλεσμα, τους περιορισμούς και τις ευθύνες. Έτσι ο υποψήφιος συνεργάτης μπορεί να προτείνει αρχιτεκτονική, τεχνολογία και διαδικασία με βάση πραγματικές ανάγκες, ενώ η επιχείρηση μπορεί να εντοπίσει τι περιλαμβάνεται και τι μένει εκτός προσφοράς.

Αν το έργο αφορά αντικατάσταση υπάρχοντος site, είναι χρήσιμο να προηγηθεί η ερώτηση αν χρειάζεται πράγματι ανακατασκευή ιστοσελίδας και ποια προβλήματα πρέπει να διορθώσει. Ένα redesign χωρίς καταγεγραμμένο λόγο κινδυνεύει να αλλάξει την εικόνα χωρίς να βελτιώσει τη λειτουργία.

Τι πρέπει να μπορεί να απαντήσει το brief

Πριν σταλεί σε εταιρείες ή επαγγελματίες, το έγγραφο πρέπει να επιτρέπει σε έναν άνθρωπο που δεν γνωρίζει την επιχείρηση να απαντήσει στα εξής:

  • Γιατί γίνεται το έργο τώρα και ποια αλλαγή αναμένεται να επιφέρει;
  • Ποιοι είναι οι βασικοί χρήστες και τι προσπαθεί να κάνει ο καθένας;
  • Ποιες σελίδες, λειτουργίες, γλώσσες και συνδέσεις με άλλα συστήματα απαιτούνται;
  • Ποιος παρέχει, εγκρίνει και συντηρεί το περιεχόμενο;
  • Ποια δεδομένα θα συλλέγονται και ποιοι ρόλοι χρειάζονται πρόσβαση;
  • Τι παραδίδεται στην επιχείρηση και πώς θα ελεγχθεί η ορθή λειτουργία;
  • Ποια στοιχεία είναι υποχρεωτικά για την πρώτη έκδοση και ποια μπορούν να ακολουθήσουν;

Αν μια απάντηση δεν είναι ακόμη γνωστή, το brief μπορεί να το δηλώνει ρητά ως θέμα διερεύνησης. Αυτό είναι προτιμότερο από μια αθέατη παραδοχή που αργότερα θα μετατραπεί σε αλλαγή αντικειμένου.

Ξεκινήστε με ένα σύντομο επιχειρηματικό πλαίσιο

Η πρώτη ενότητα δεν χρειάζεται εταιρικό ιστορικό πολλών σελίδων. Περιγράψτε με λίγες παραγράφους τι πουλά η επιχείρηση, σε ποιους απευθύνεται, σε ποιες αγορές λειτουργεί και ποιος είναι ο ρόλος του website στη διαδρομή του πελάτη. Για παράδειγμα, ένα B2B site μπορεί να υποστηρίζει τη διερεύνηση πριν από μια σύνθετη πώληση, ενώ ένα e-shop πρέπει να βοηθά στην επιλογή, την αγορά και την εξυπηρέτηση μετά την παραγγελία.

Καταγράψτε τον βασικό στόχο με τρόπο που να μπορεί να ελεγχθεί. Το «σύγχρονο site» είναι αισθητική επιθυμία. Το «να μπορεί ο επισκέπτης να βρίσκει τη σωστή υπηρεσία ανά κλάδο και να στέλνει πλήρες αίτημα» είναι λειτουργικός στόχος. Το «να μειωθούν οι τηλεφωνικές ερωτήσεις για διαθεσιμότητα μέσω ενημερωμένης πληροφορίας» περιγράφει πρόβλημα και επιθυμητή συμπεριφορά, χωρίς να υπόσχεται αυθαίρετο ποσοστό βελτίωσης.

Σημειώστε επίσης τι δεν περιλαμβάνει το έργο. Αν η νέα εταιρική ταυτότητα, το φωτογραφικό υλικό, η μετάφραση ή η σύνδεση με ERP θα γίνουν ξεχωριστά, η πληροφορία αλλάζει τη σειρά εργασιών, τις εξαρτήσεις και το κόστος.

Περιγράψτε χρήστες μέσα από πραγματικά σενάρια

Οι γενικές personas συχνά είναι λιγότερο χρήσιμες από συγκεκριμένα σενάρια. Αντί για «ο πελάτης μας είναι 35–55 ετών», γράψτε τι γνωρίζει, τι αμφιβολία έχει και τι θέλει να ολοκληρώσει. Ένας υπεύθυνος προμηθειών μπορεί να χρειάζεται τεχνικά έγγραφα και διαδικασία αιτήματος προσφοράς. Ένας υπάρχων πελάτης μπορεί να αναζητά οδηγίες ή στοιχεία υποστήριξης. Ένας υποψήφιος εργαζόμενος χρειάζεται διαφορετική πληροφορία και διαφορετική φόρμα.

Για κάθε βασικό σενάριο καταγράψτε:

  1. την αφετηρία του χρήστη, όπως αναζήτηση, διαφήμιση, άμεση επίσκεψη ή σύνδεσμος συνεργάτη,
  2. την πληροφορία που πρέπει να βρει για να προχωρήσει,
  3. την κύρια ενέργεια που θέλετε να ολοκληρώσει,
  4. τι συμβαίνει μετά την ενέργεια και ποιος την αναλαμβάνει εσωτερικά,
  5. τι θα θεωρηθεί αποτυχία, όπως ασαφές μήνυμα, αδιέξοδο ή φόρμα που δεν φτάνει στον σωστό παραλήπτη.

Αυτά τα σενάρια βοηθούν να σχεδιαστεί η αρχιτεκτονική του website γύρω από αποφάσεις και εργασίες, όχι γύρω από το οργανόγραμμα της εταιρείας.

Ορίστε το περιεχόμενο και την ευθύνη του

Πολλά έργα καθυστερούν όχι επειδή λείπει κώδικας, αλλά επειδή το περιεχόμενο δεν έχει ιδιοκτήτη. Το brief πρέπει να περιλαμβάνει έναν αρχικό κατάλογο τύπων σελίδων: αρχική, υπηρεσίες, κατηγορίες, προϊόντα, έργα, άρθρα, εταιρικές πληροφορίες, επικοινωνία, πολιτικές και ό,τι άλλο απαιτεί το συγκεκριμένο μοντέλο.

Για κάθε τύπο σημειώστε αν το υλικό υπάρχει, χρειάζεται επιμέλεια ή πρέπει να παραχθεί από την αρχή. Ξεχωρίστε κείμενα, φωτογραφίες, βίντεο, τεχνικά αρχεία, μεταφράσεις και δεδομένα προϊόντων. Δηλώστε ποιος τα παραδίδει, σε ποια μορφή και ποιος έχει την τελική έγκριση. Αν υπάρχουν νομικά ή κανονιστικά κείμενα, η επιχείρηση πρέπει να ορίσει τον κατάλληλο υπεύθυνο ελέγχου· ο web συνεργάτης δεν πρέπει να θεωρείται αυτομάτως πηγή νομικής συμβουλής.

Καταγράψτε και το πλάνο μεταφοράς από το παλιό site. Δεν μεταφέρεται κάθε παλιά σελίδα μηχανικά. Χρειάζεται απόφαση για διατήρηση, ενημέρωση, συγχώνευση ή απόσυρση και, όταν αλλάζουν URLs, χαρτογράφηση ανακατευθύνσεων. Ο έλεγχος redirect map πριν από website migration προστατεύει χρήσιμες διαδρομές και μειώνει τα αδιέξοδα.

Μετατρέψτε τις λειτουργίες σε σαφείς απαιτήσεις

Μια λειτουργική απαίτηση περιγράφει τι πρέπει να μπορεί να κάνει ένας ρόλος και ποιο αποτέλεσμα περιμένει. Το «χρειαζόμαστε φόρμα» είναι ατελές. Πιο χρήσιμο είναι: «ο επισκέπτης επιλέγει υπηρεσία, επισυνάπτει αποδεκτό τύπο αρχείου, λαμβάνει επιβεβαίωση και το αίτημα αποθηκεύεται και δρομολογείται στη σωστή ομάδα».

Για κάθε σημαντική λειτουργία δηλώστε κανόνες και εξαιρέσεις. Σε ένα e-shop αυτά μπορεί να αφορούν παραλλαγές προϊόντων, διαθεσιμότητα, φόρους, τρόπους αποστολής, επιστροφές και ενημέρωση παραγγελίας. Σε ένα portal μπορεί να αφορούν ρόλους χρηστών, δικαιώματα, έγκριση εγγραφής και πρόσβαση σε αρχεία. Σε μια πλατφόρμα κρατήσεων χρειάζονται κανόνες διαθεσιμότητας, ακύρωσης και συγχρονισμού.

Μην θεωρείτε τη διαχείριση περιεχομένου αυτονόητη. Περιγράψτε ποιοι εσωτερικοί ρόλοι θα δημιουργούν ή θα εγκρίνουν περιεχόμενο, ποια πεδία πρέπει να μπορούν να αλλάζουν χωρίς developer και αν χρειάζεται ιστορικό αλλαγών ή ροή έγκρισης.

Καταγράψτε integrations και ροές δεδομένων

Η φράση «σύνδεση με CRM» μπορεί να σημαίνει από απλή αποστολή μιας φόρμας έως αμφίδρομο συγχρονισμό πελατών, προϊόντων και σταδίων πώλησης. Στο brief ονομάστε το σύστημα, τον ιδιοκτήτη του, το διαθέσιμο περιβάλλον δοκιμών και, αν είναι γνωστό, τον επίσημο τρόπο σύνδεσης. Περιγράψτε ποια δεδομένα κινούνται, προς ποια κατεύθυνση, πότε και τι πρέπει να συμβαίνει σε αποτυχία.

Αν απαιτούνται analytics, consent management, newsletter, πληρωμές, ERP, live chat, σύστημα κρατήσεων ή εξωτερικό feed, καταγράψτε τα ξεχωριστά. Δεν χρειάζεται να βάλετε μυστικά κλειδιά στο brief. Χρειάζεται να ορίσετε ποιος παρέχει τις προσβάσεις, ποιος εγκρίνει τη ρύθμιση και ποιος θα έχει την ευθύνη μετά το launch.

Για τη μέτρηση, ορίστε τις σημαντικές ενέργειες και όχι μόνο την εγκατάσταση ενός εργαλείου. Η ολοκλήρωση φόρμας, το τηλεφώνημα, η λήψη τεχνικού αρχείου ή η αγορά μπορεί να έχουν διαφορετική αξία. Η μελλοντική βελτιστοποίηση χρειάζεται να συνδέεται με πραγματικές αποφάσεις, όπως εξηγεί και η προσέγγιση ενός CRO audit για leads και πωλήσεις.

Μην ξεχάσετε τις μη λειτουργικές απαιτήσεις

Οι μη λειτουργικές απαιτήσεις περιγράφουν την ποιότητα με την οποία πρέπει να δουλεύει το site. Εδώ ανήκουν η απόδοση, η ασφάλεια, η προσβασιμότητα, η συμβατότητα, η διαθεσιμότητα, τα αντίγραφα ασφαλείας και η δυνατότητα συντήρησης. Αποφύγετε απόλυτες φράσεις όπως «να φορτώνει ακαριαία παντού». Ορίστε ποια πρότυπα σελίδων είναι κρίσιμα, σε ποιες συσκευές και συνθήκες θα ελεγχθούν και ποια εργαλεία ή μετρήσεις θα χρησιμοποιηθούν.

Η προσβασιμότητα πρέπει να μπαίνει στις απαιτήσεις και στα κριτήρια παραλαβής, όχι να προστίθεται την τελευταία ημέρα. Η επίσημη καθοδήγηση του W3C Web Accessibility Initiative για τον σχεδιασμό προσβασιμότητας συνδέει ρητά την πολιτική, τις ευθύνες, το procurement και το acceptance testing. Το brief πρέπει να αναφέρει το επίπεδο συμμόρφωσης ή τις εσωτερικές απαιτήσεις που ισχύουν για τον οργανισμό, χωρίς να αντιμετωπίζει έναν αυτόματο έλεγχο ως πλήρη απόδειξη.

Για ασφάλεια και προστασία δεδομένων, περιγράψτε κατηγορίες δεδομένων, ρόλους και ανάγκες διατήρησης σε συνεργασία με τους αρμόδιους της επιχείρησης. Μην αντιγράφετε γενικές λίστες συμμόρφωσης που δεν έχουν ελεγχθεί για το συγκεκριμένο έργο.

Δηλώστε ownership, προσβάσεις και παράδοση

Πριν από την προσφορά πρέπει να είναι σαφές ποιος θα κατέχει domain, hosting, κώδικα, design files, άδειες, analytics properties, media και λογαριασμούς τρίτων. Η επιχείρηση χρειάζεται λειτουργική πρόσβαση στα στοιχεία που της ανήκουν και διαδικασία ασφαλούς διαχείρισης ρόλων. Οι προσωπικοί κωδικοί ενός εργαζομένου δεν είναι βιώσιμη υποδομή.

Ζητήστε να περιγραφούν τα παραδοτέα του launch: παραγωγικό site, πηγαίος κώδικας όπου προβλέπεται, τεκμηρίωση, λίστα λογαριασμών, αντίγραφο ασφαλείας, οδηγίες διαχείρισης, εκπαίδευση και περίοδος υποστήριξης. Διαχωρίστε την αποκατάσταση σφαλμάτων από νέες απαιτήσεις που προκύπτουν μετά την παραλαβή.

Γράψτε κριτήρια αποδοχής πριν ξεκινήσει η ανάπτυξη

Το κριτήριο αποδοχής είναι παρατηρήσιμο. Αντί για «η φόρμα να λειτουργεί σωστά», γράψτε: «με έγκυρα στοιχεία δημιουργείται μία καταχώριση, αποστέλλεται επιβεβαίωση, το αίτημα φτάνει στην κατάλληλη ομάδα και το συμβάν καταγράφεται χωρίς διπλοεγγραφή». Για μια σελίδα υπηρεσίας μπορεί να απαιτείται σωστή εμφάνιση του εγκεκριμένου περιεχομένου, λειτουργία σε συμφωνημένα breakpoints, προσβάσιμη πλοήγηση με πληκτρολόγιο και έλεγχος τίτλου και canonical URL.

Τα κριτήρια πρέπει να συνδέονται με περιβάλλον δοκιμών, υπεύθυνο ελέγχου και τρόπο καταγραφής προβλημάτων. Συμφωνήστε ποια ευρήματα εμποδίζουν το launch και ποια μπορούν να μπουν σε επόμενο κύκλο. Έτσι η παραλαβή δεν μετατρέπεται σε ασαφή διαφωνία προτιμήσεων.

Υποθετικό παράδειγμα: brief για εταιρεία B2B υπηρεσιών

Το ακόλουθο παράδειγμα είναι υποθετικό. Μια εταιρεία τεχνικών υπηρεσιών θέλει νέο site επειδή οι επισκέπτες δυσκολεύονται να καταλάβουν ποια λύση ταιριάζει στον κλάδο τους και τα αιτήματα φτάνουν χωρίς βασικές πληροφορίες.

Πεδίο Καταγραφή στο brief
Κύριος στόχος Σαφής επιλογή υπηρεσίας ανά κλάδο και πληρέστερο αίτημα αξιολόγησης.
Βασικοί χρήστες Τεχνικός υπεύθυνος, υπεύθυνος προμηθειών, υπάρχων πελάτης.
Κρίσιμα σενάρια Σύγκριση λύσεων, λήψη τεχνικού αρχείου, αποστολή αιτήματος με απαιτήσεις.
Περιεχόμενο Δώδεκα υπηρεσίες, έξι κλάδοι, τεχνική βιβλιοθήκη και συχνές ερωτήσεις.
Integration Δημιουργία lead στο CRM με πηγή, υπηρεσία και συγκατάθεση· ειδοποίηση σε αποτυχία.
Παραλαβή Έλεγχος διαδρομών, φόρμας, analytics events, προσβασιμότητας και redirects.

Το παράδειγμα δεν επιλέγει CMS ούτε προκαθορίζει design. Δίνει όμως αρκετές πληροφορίες για να εκτιμηθούν αρχιτεκτονική, περιεχόμενο, ανάπτυξη, έλεγχοι και ευθύνες. Οι υποψήφιοι συνεργάτες μπορούν να εξηγήσουν διαφορετικές λύσεις πάνω στο ίδιο πρόβλημα.

Τι να αφήσετε στον υποψήφιο συνεργάτη

Ένα υπερβολικά λεπτομερές brief μπορεί να κλειδώσει πρόωρα μια λανθασμένη λύση. Αν δεν υπάρχει τεκμηριωμένος λόγος, μην επιβάλλετε framework, plugin ή έτοιμο template μόνο επειδή χρησιμοποιήθηκε σε άλλο έργο. Περιγράψτε τους περιορισμούς που είναι πραγματικοί: υπάρχουσα υποδομή, δεξιότητες της ομάδας, πολιτικές IT, απαιτούμενες συνδέσεις και προϋποθέσεις συντήρησης.

Ζητήστε από την προσφορά να εξηγεί τη μεθοδολογία, τα στάδια, τις παραδοχές, τους ρόλους, τις εξαιρέσεις και τους κινδύνους. Μια καλή απάντηση στο brief δεν επαναλαμβάνει απλώς τις απαιτήσεις· εντοπίζει ασάφειες, προτείνει προτεραιότητες και περιγράφει πώς θα ληφθούν οι αποφάσεις που παραμένουν ανοικτές.

Checklist πριν στείλετε το brief

  • Υπάρχει ένας κύριος στόχος και λίγοι δευτερεύοντες, χωρίς αόριστες υποσχέσεις;
  • Έχουν περιγραφεί οι βασικοί χρήστες και οι κρίσιμες διαδρομές τους;
  • Υπάρχει inventory περιεχομένου και ονομασμένος υπεύθυνος για κάθε κατηγορία υλικού;
  • Οι λειτουργίες περιγράφουν κανόνες, εξαιρέσεις και αποτέλεσμα;
  • Έχουν καταγραφεί integrations, ιδιοκτήτες συστημάτων και ροές δεδομένων;
  • Περιλαμβάνονται προσβασιμότητα, ασφάλεια, απόδοση, συμβατότητα και συντήρηση;
  • Είναι ξεκάθαρα ownership, λογαριασμοί, άδειες, τεκμηρίωση και υποστήριξη;
  • Υπάρχουν κριτήρια αποδοχής και διαδικασία ελέγχου;
  • Έχει ξεχωρίσει το απαραίτητο για το launch από τις επόμενες φάσεις;
  • Έχουν δηλωθεί οι άγνωστες παράμετροι που απαιτούν discovery;

Το brief κατασκευής ιστοσελίδας είναι εργαλείο κοινής κατανόησης. Δεν εξαφανίζει κάθε αλλαγή, αλλά κάνει τις αλλαγές ορατές και διαχειρίσιμες. Όταν στόχοι, σενάρια, περιεχόμενο, τεχνικές εξαρτήσεις και κριτήρια αποδοχής έχουν συμφωνηθεί, η προσφορά παύει να είναι μια αυθαίρετη τιμή για «ένα site» και γίνεται πρόταση για συγκεκριμένο έργο.

Η VNG μπορεί να οργανώσει μαζί σας το discovery και να μετατρέψει τις επιχειρηματικές ανάγκες σε εφαρμόσιμο brief, αρχιτεκτονική και πλάνο υλοποίησης. Η ουσία δεν είναι να προστεθούν περισσότερες σελίδες, αλλά να συμφωνηθεί τι πρέπει να πετυχαίνει η καθεμία και πώς θα το γνωρίζουμε.