Ιστοσελίδες SaaS από μέσα προς τα έξω: Γιατί οι τιμές και η τεκμηρίωση προηγούνται

Περίληψη

Οι περισσότερες συμβουλές για ιστοσελίδες SaaS ξεκινούν από την αρχική σελίδα και αφήνουν τις τιμές, τα έγγραφα και τις συχνές ερωτήσεις ως δευτερεύουσες σκέψεις — γι' αυτό και αυτές οι σελίδες καταλήγουν να αντιφάσκουν μεταξύ τους. Αυτό το άρθρο υποστηρίζει το χτίσιμο από μέσα προς τα έξω: ξεκινήστε με τη σελίδα τιμών και την τεκμηρίωση API, όπου βρίσκονται οι πραγματικοί περιορισμοί του προϊόντος, και αντλήστε όλα τα υπόλοιπα από αυτά. Παρουσιάζει ένα πλαίσιο έξι βημάτων: συγκεντρώστε τους περιορισμούς, φτιάξτε τη σελίδα τιμών ως σκελετό, αντιμετωπίστε τα έγγραφα API ως επιφάνεια προϊόντος, αντλήστε την προβολή χαρακτηριστικών από τις ροές εργασίας, συλλέξτε τις συχνές ερωτήσεις από πραγματικές συνομιλίες και ολοκληρώστε με έλεγχο συνέπειας. Η προσέγγιση αυτή είναι φτιαγμένη για εταιρείες που χρειάζονται μια επαναλήψιμη διαδικασία σε διαφορετικούς πελάτες. Περιλαμβάνει επίσης επισημάνσεις για το πότε το πλαίσιο είναι υπερβολικό και πώς να διαχειρίζεστε τις προσδοκίες των πελατών.

Οι περισσότερες συμβουλές για τη δημιουργία ιστοσελίδων SaaS είναι ανάποδες. Σας λένε να ξεκινήσετε από την αρχική σελίδα — το hero, τον τίτλο, το στιγμιότυπο οθόνης του προϊόντος — και να αντιμετωπίσετε τις τιμές, την τεκμηρίωση και τις συχνές ερωτήσεις ως σελίδες που συμπληρώνετε αφού εγκριθεί το σχέδιο. Έπειτα, εβδομάδες αργότερα, προσπαθείτε να συμβιβάσετε την υπόσχεση του τίτλου για «απεριόριστα πάντα» με τα πραγματικά όρια χρήσης της σελίδας τιμών, και το τμήμα χαρακτηριστικών παρουσιάζει περήφανα μια δοκιμαστική λειτουργία που ούτε καν αναφέρεται στα έγγραφα API. Αυτή η σειρά λειτουργεί μόνο όταν το προϊόν είναι αρκετά απλό ώστε να μην χρειάζεται συμβιβασμός, κάτι που σπάνια ισχύει. Αυτό που πραγματικά λειτουργεί — ειδικά όταν το κάνετε επανειλημμένα για εντελώς διαφορετικούς πελάτες — είναι να χτίσετε τον ιστότοπο από μέσα προς τα έξω: ξεκινήστε με τις πιο περιορισμένες, λιγότερο εντυπωσιακές σελίδες (τιμές και έγγραφα API) και αφήστε τις να δημιουργήσουν την αρχική σελίδα, την προβολή χαρακτηριστικών και τις συχνές ερωτήσεις. Ορίστε ένα πλαίσιο έξι βημάτων για να το κάνετε αυτό, και στην πορεία θα επισημάνω πού γίνεται άβολο, γιατί όντως γίνεται.

Ένας γρήγορος χάρτης της διαφοράς, γιατί όλο το επιχείρημα βασίζεται σε αυτό:

	Πρώτα η σελίδα (πιο συνηθισμένο)	Πρώτα οι περιορισμοί (αυτό το πλαίσιο)
Από πού ξεκινάτε	Hero και οπτικά της αρχικής σελίδας	Σελίδα τιμών και έγγραφα API
Τι καθοδηγεί το κείμενο	Ιστορία μάρκας και σχεδιασμός	Πραγματικά όρια και ροές εργασίας του προϊόντος
Προβολή χαρακτηριστικών	Απαριθμεί όλα όσα κάνει το προϊόν	Ακολουθεί διαδρομές που ακολουθούν οι πραγματικοί χρήστες
Συχνές ερωτήσεις	Γράφονται τελευταίες, από εικασίες	Συλλέγονται από υποστήριξη και πωλήσεις
Αποτέλεσμα κατά την κυκλοφορία	Ασυνεπείς ισχυρισμοί, κρυφές αντιφάσεις	Οι σελίδες διαβάζονται ως ένα ενιαίο προϊόν

Βήμα 1 — Διαβάστε τη σελίδα τιμών προτού γράψετε λέξη.

Ένας πελάτης σου δίνει μια λίστα χαρακτηριστικών, ένα παρουσιαστικό της μάρκας και έναν σύνδεσμο demo, και ζητά μια αρχική σελίδα. Μέχρι το τέλος της πρώτης κλήσης, συζητάτε το κείμενο του hero και τους συνδυασμούς χρωμάτων. Δοκίμασε να το επιβραδύνεις. Ζήτα τη σελίδα τιμών και τα όρια των πακέτων — ακόμα κι αν είναι απλώς ένα Google Doc με σημειώσεις — και θα διαπιστώσεις ότι ολόκληρο το έργο αλλάζει.

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

Ορίστε ένα τυπικό σενάριο. Ο πελάτης είναι ένα εργαλείο παρακολούθησης χρόνου: Δωρεάν πακέτο, Επαγγελματικό πακέτο, Εταιρικό πακέτο. Το παρουσιαστικό πωλήσεων λέει «επεκτείνεται σε οποιαδήποτε ομάδα». Η σελίδα του Pro λέει «απεριόριστα έργα». Αλλά η ομάδα υποστήριξης επιβεβαιώνει ότι οι λογαριασμοί Pro έχουν στην πραγματικότητα ανώτατο όριο τα 10 ενεργά έργα ανά χώρο εργασίας, και τα έγγραφα API λένε ότι ένα έργο μπορεί να έχει το πολύ 50 μέλη. Η αρχική σελίδα δεν γράφεται ποτέ έως ότου κάποιος το επιλύσει αυτό, γιατί τα «απεριόριστα έργα» είναι πλέον νομικό ζήτημα, όχι ζήτημα κειμένου. Αν είχες ξεκινήσει με την αρχική σελίδα, θα είχες γράψει «απεριόριστα έργα» στο hero και θα ανακάλυπτες τη σύγκρουση δύο εβδομάδες αργότερα, αφού το σχέδιο είχε εγκριθεί. Ξεκινώντας με τους περιορισμούς, η σύγκρουση εμφανίζεται την πρώτη εβδομάδα, όταν η διόρθωση δεν κοστίζει τίποτα.

Τι ακριβώς πρέπει να συγκεντρώσεις σε αυτό το βήμα; Τους ορισμούς των πακέτων και όποιον συγκριτικό πίνακα χαρακτηριστικών ανά πακέτο. Την τεκμηρίωση API, ή τουλάχιστον μια λίστα με το τι μπορεί και τι δεν μπορεί να κάνει το API. Τις πιο συνηθισμένες ερωτήσεις της ομάδας υποστήριξης (περισσότερα για αυτό στο Βήμα 5). Το παρουσιαστικό πωλήσεων, με την προειδοποίηση ότι εκεί ζει η φαντασία. Και το ίδιο το προϊόν, ανοιγμένο ώστε να δεις τις σελίδες ρυθμίσεων όπου επιβάλλονται τα όρια — γιατί το ίδιο το προϊόν είναι η τελική αυθεντία. Μια οθόνη ρυθμίσεων που λέει «Μέγιστο 10 έργα» υπερισχύει οποιουδήποτε υπολογιστικού φύλλου.

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

Βήμα 2 — Χτίστε τη σελίδα τιμών ως τον σκελετό ολόκληρου του ιστότοπου.

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

Πάρτε το εργαλείο παρακολούθησης χρόνου. Τρία πακέτα: Δωρεάν, Pro, Enterprise. Ο πίνακας χρειάζεται στήλες που αντικατοπτρίζουν τον τρόπο που το προϊόν πραγματικά κατηγοριοποιεί — αριθμός έργων, ενοποιήσεις, βάθος αναφορών. Για κάθε κελί, χρειάζεστε την ειλικρινή αξία, όχι την επιθυμητή. Αν το Pro περιλαμβάνει 10 ενεργά έργα, το κελί λέει 10 ενεργά έργα, με σύνδεσμο προς τις συχνές ερωτήσεις τιμών που εξηγούν τι σημαίνει «ενεργό» και τι συμβαίνει όταν φτάσετε στο όριο. Μία από τις πιο δύσκολες αποφάσεις εδώ είναι τι να πείτε για το πακέτο που θέλετε περισσότερο να αγοράσουν οι επισκέπτες. Πολλές σελίδες τιμών κάνουν το βασικό πακέτο προφανές — επισημασμένο, με ένα σήμα «Πιο δημοφιλές» — και το κείμενο γύρω του εξηγεί γιατί είναι η σωστή επιλογή για αυτόν τον επισκέπτη. Για το εργαλείο παρακολούθησης χρόνου, το Pro είναι το βασικό: εκεί ξεκινούν πραγματικά οι ενοποιήσεις και το βάθος αναφορών, οπότε η σελίδα πρέπει να το υποστηρίξει ρητά αντί να υποθέσει ότι ο επισκέπτης θα διαβάσει τον πίνακα και θα καταλήξει μόνος του.

Εδώ αποφασίζετε επίσης ποιοι όροι θα είναι κανονικοί σε ολόκληρο τον ιστότοπο. Αν το προϊόν αποκαλεί τις ομάδες «χώροι εργασίας» στη σελίδα τιμών αλλά το διαφημιστικό κείμενο λέει «ομάδες», κάθε επόμενη σελίδα κληρονομεί την ασυνέπεια. Το να γράψετε πρώτα τη σελίδα τιμών σας αναγκάζει να επιλέξετε το λεξιλόγιο, και θα πρέπει να επιλέξετε ό,τι χρησιμοποιεί το ίδιο το προϊόν — γιατί το προϊόν και τα έγγραφα πρέπει να ταιριάζουν, και ο διαφημιστικός ιστότοπος είναι αυτός που μπορεί να λυγίσει.

Μια σελίδα τιμών χρειάζεται και τις δικές της συχνές ερωτήσεις. Οι ερωτήσεις που ανήκουν εκεί είναι αυτές που συνδέονται με τους συγκεκριμένους μηχανισμούς των πακέτων: τι θεωρείται θέση, τι συμβαίνει όταν υποβαθμίζετε, αν η χρέωση είναι ετήσια ή μηνιαία, τι σημαίνει «ενεργό» για ένα έργο. Υπάρχει μια καλά ανεπτυγμένη πρακτική για τη δομή των σελίδων τιμών με στόχο τη μετατροπή, και οι μηχανισμοί αξίζουν να μελετηθούν. Αλλά σε αυτό το πλαίσιο, η δουλειά της σελίδας τιμών δεν είναι μόνο να μετατρέπει — είναι να κλειδώνει τις πραγματικές αποφάσεις που θα υπακούουν όλες οι άλλες σελίδες. Αν θέλετε τους βαθύτερους μηχανισμούς, αυτός ο οδηγός για τη διόρθωση σελίδων τιμών SaaS τους καλύπτει λεπτομερώς.

Βήμα 3 — Αντιμετωπίστε την τεκμηρίωση API ως επιφάνεια προϊόντος, όχι ως εγχειρίδιο.

Ένας προγραμματιστής αξιολογεί το εργαλείο παρακολούθησης χρόνου. Η εταιρεία του χρειάζεται να τραβά αυτόματα τα χρονοδιαγράμματα σε ένα σύστημα μισθοδοσίας. Τα έγγραφα είναι οργανωμένα αλφαβητικά ανά τελικό σημείο: /projects, /reports, /timesheets, /users. Ο προγραμματιστής δεν έχει ιδέα με ποια κλήση να ξεκινήσει, και η ενότητα «Αυθεντικοποίηση» προϋποθέτει γνώσεις που δεν έχει — τα έγγραφα δεν εξηγούν ποτέ ότι δημιουργείτε ένα κλειδί API στη σελίδα ρυθμίσεων στην ενότητα «Ενοποιήσεις». Ο προγραμματιστής κλείνει την καρτέλα, πεπεισμένος ότι το προϊόν δεν θα ενοποιηθεί ομαλά. Ωστόσο, κάθε απαραίτητη πληροφορία ήταν παρούσα στα έγγραφα· ήταν απλώς οργανωμένη με τη σειρά που θα χρησιμοποιούσε ένα εγχειρίδιο αναφοράς, όχι με τη σειρά που θα χρησιμοποιούσε ένας άνθρωπος.

Η τεκμηρίωση οργανωμένη ανά ροή εργασίας θα είχε αλλάξει αυτό το αποτέλεσμα: «Γρήγορη εκκίνηση», «Αυθεντικοποίηση», «Λήψη χρονοδιαγραμμάτων», «Δημιουργία έργου», «Webhooks και συγχρονισμός». Κάθε ενότητα ξεκινά με τη δουλειά και στη συνέχεια δείχνει το τελικό σημείο. Η γρήγορη εκκίνηση μπορεί να διαρκέσει πέντε λεπτά και να παράγει μια επιτυχημένη κλήση API — που είναι το αντίστοιχο της δωρεάν δοκιμής στην τεκμηρίωση. Για ένα προϊόν που απευθύνεται πρώτα σε προγραμματιστές, αυτή είναι η πιο πειστική σελίδα στον ιστότοπο.

Για οποιοδήποτε SaaS έχει API, η τεκμηρίωση είναι μια σελίδα του ιστότοπού σας είτε το έχετε προγραμματίσει είτε όχι. Το σημείο αναφοράς του κλάδου — που έχει τεθεί από εταιρείες όπως η Stripe, το GitHub και το Twilio — είναι τεκμηρίωση που διαβάζεται σαν προϊόν: εξηγεί τη δουλειά που προσπαθεί να κάνει ο προγραμματιστής, όχι μόνο τα διαθέσιμα τελικά σημεία. Η αρχή είναι ότι τα έγγραφα API αποτελούν μέρος της εμπειρίας προϊόντος και θα πρέπει να ακολουθούν την ίδια λογική από μέσα προς τα έξω με τον υπόλοιπο ιστότοπο: ξεκινήστε με τις δουλειές που μπορεί να επιτελέσει ο προγραμματιστής και μετά αποκαλύψτε τους μηχανισμούς.

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

Βήμα 4 — Αντλήστε την προβολή χαρακτηριστικών από τις ροές εργασίας, όχι από τη λίστα χαρακτηριστικών.

Ο πελάτης σας στέλνει ένα υπολογιστικό φύλλο με 40 χαρακτηριστικά και ζητά μια σελίδα χαρακτηριστικών. Η εύκολη απάντηση είναι ένα πλέγμα: 40 στοιχεία, το καθένα με ένα εικονίδιο και μια λεζάντα. Το αποτέλεσμα δείχνει εξαντλητικό αλλά διαβάζεται ως θόρυβος, γιατί το πλέγμα δεν έχει ιστορία. Κανείς δεν επισκέπτεται έναν ιστότοπο SaaS για να μάθει κάθε χαρακτηριστικό· επισκέπτεται για να μάθει αν αυτό το προϊόν κάνει τη μία δουλειά για την οποία ήρθε. Έτσι, η προβολή θα πρέπει να χτιστεί από ροές εργασίας, όχι από τη λίστα χαρακτηριστικών.

Δουλέψτε το παράδειγμα. Η πιο συνηθισμένη επιτυχημένη διαδρομή του εργαλείου παρακολούθησης χρόνου, σύμφωνα με την ομάδα υποστήριξης του πελάτη, είναι ένας επικεφαλής ομάδας που εγγράφεται, προσκαλεί τρεις συναδέλφους, δημιουργεί ένα έργο και τρέχει μια αναφορά στο τέλος της εβδομάδας. Αυτή είναι η ροή εργασίας. Η προβολή χαρακτηριστικών θα πρέπει να την ακολουθεί: μια ενότητα για την πρόσκληση της ομάδας σας (καλύπτοντας θέσεις και ρόλους), μια ενότητα για τη ρύθμιση ενός έργου (καλύπτοντας πρότυπα και ρυθμίσεις έργου), μια ενότητα για τον πίνακα αναφορών (καλύπτοντας τα γραφήματα και τις επιλογές εξαγωγής). Κάθε ενότητα δείχνει ένα στιγμιότυπο από εκείνη ακριβώς τη στιγμή στο προϊόν, όχι ένα περικομμένο στιγμιότυπο ενός πάνελ ρυθμίσεων που σπάνια χρησιμοποιείται. Ο επισκέπτης βλέπει τη δική του διαδρομή, και τα χαρακτηριστικά που βλέπει στην πορεία είναι αυτά που έχουν σημασία για εκείνον.

Η επόμενη ροή εργασίας, για έναν ελαφρώς διαφορετικό επισκέπτη, είναι το στέλεχος που δεν χρησιμοποιεί ποτέ το ίδιο το εργαλείο: εγκρίνει χρονοδιαγράμματα και εξετάζει την εβδομαδιαία αναφορά. Η προβολή μπορεί να προσθέσει μια ενότητα για αυτόν τον επισκέπτη στο τέλος — «Για διευθυντές» — χωρίς να σπάσει την αφήγηση. Δύο ροές εργασίας είναι συνήθως αρκετές για να ξεκινήσετε· δεν χρειάζεστε μία για κάθε προσωπικότητα.

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

Βήμα 5 — Συλλέξτε τις συχνές ερωτήσεις από την υποστήριξη και τις πωλήσεις, όχι από τη φαντασία σας.

Έχετε δύο ημέρες πριν την κυκλοφορία του ιστότοπου και οι συχνές ερωτήσεις είναι ακόμα κενές. Το ένστικτο είναι να γράψετε δέκα ερωτήσεις σε ένα απόγευμα — συνήθως τις ερωτήσεις που θα θέλατε εσείς να απαντά το προϊόν, αντί για αυτές που κάνουν πραγματικά οι πελάτες. Αυτό είναι ανάποδο. Οι συχνές ερωτήσεις έχουν μια συγκεκριμένη δουλειά: να απομακρύνουν τις τελευταίες αμφιβολίες ανάμεσα σε έναν επισκέπτη και μια εγγραφή. Οι αποτελεσματικές σελίδες συχνών ερωτήσεων, όπως αυτές που βλέπετε από το HubSpot, το Slack και το Zendesk, λειτουργούν επειδή είναι οργανωμένες γύρω από πραγματικά ερωτήματα, αναζητήσιμες και συνοπτικές. Είναι προϊόν ακρόασης, όχι επινόησης.

Το ρεαλιστικό σενάριο: είστε στη σελίδα τιμών και ξέρετε ότι ο μεγαλύτερος λόγος απόρριψης για το εργαλείο παρακολούθησης χρόνου είναι η ενοποίηση: «Δουλεύει με το QuickBooks;» Μια ανασκόπηση των αρχείων υποστήριξης δείχνει ότι αυτή είναι η πιο συνηθισμένη ερώτηση προ-πώλησης. Αυτή η ερώτηση, με την απάντησή της, ανήκει στις συχνές ερωτήσεις της σελίδας τιμών. Η δεύτερη πιο συνηθισμένη, από τις κλήσεις πωλήσεων, είναι «Τι συμβαίνει με τα χρονοδιαγράμματά μου αν ακυρώσω;» Αυτή ανήκει επίσης εκεί. Κάθε απάντηση συντομεύει τον κύκλο πωλήσεων και μειώνει τον φόρτο υποστήριξης, γιατί ένας επισκέπτης που βλέπει την απάντηση γραπτώς εμπιστεύεται το προϊόν περισσότερο από έναν επισκέπτη που πρέπει να ρωτήσει.

Ο κανόνας για την εταιρεία: μην γράψετε ούτε μία απάντηση συχνών ερωτήσεων προτού εξετάσετε τα εισιτήρια υποστήριξης, τις σημειώσεις κλήσεων πωλήσεων και τα email ενσωμάτωσης. Ποιες είναι οι ερωτήσεις που πραγματικά επαναλαμβάνονται; Αυτές μπαίνουν. Όλα τα υπόλοιπα πάνε στη σελίδα χαρακτηριστικών ή πουθενά. Και καθώς ο ιστότοπος εξελίσσεται, επανεξετάστε τις συχνές ερωτήσεις — κάθε αλλαγή τιμής ή κυκλοφορία χαρακτηριστικού δημιουργεί νέες ερωτήσεις, και οι συχνές ερωτήσεις είναι το φθηνότερο μέρος για να τις πιάσετε.

Υπάρχει επίσης λόγος να σκεφτείτε τη δομή των συχνών ερωτήσεων, όχι μόνο το περιεχόμενο. Μια μακριά, με κύλιση λίστα ερωτήσεων είναι δύσκολο να σαρωθεί· η ομαδοποίηση ανά κατηγορία (Χρέωση, Ενοποιήσεις, Διαχείριση λογαριασμού) με έναν πίνακα περιεχομένων στην κορυφή την καθιστά πραγματικά χρησιμοποιήσιμη. Η λειτουργία αναζήτησης βοηθά όταν η λίστα ξεπεράσει ένα ορισμένο μέγεθος — αυτό είναι το μέρος της σελίδας όπου ο σχεδιασμός έχει τόση σημασία όσο και το κείμενο, γιατί ένα FAQ χωρίς αναζήτηση είναι ένα FAQ που δεν διαβάζεται.

Κάτι ακόμα, που είναι το άβολο μέρος: το FAQ είναι συχνά η πιο ειλικρινής σελίδα του ιστότοπου, γιατί είναι η μία σελίδα όπου απαντάτε στην ερώτηση που ο επισκέπτης φοβάται να κάνει. Αν μια ερώτηση σας κάνει να νιώθετε άβολα — «Μπορώ πραγματικά να ακυρώσω ανά πάσα στιγμή;» «Το δωρεάν πακέτο δείχνει διαφημίσεις;» — αυτό το άβολο συναίσθημα είναι απόδειξη ότι ανήκει εκεί, όχι λόγος να την απορρίψετε. Ο επισκέπτης έχει αυτήν την ερώτηση είτε την απαντήσετε είτε όχι· αν δεν την απαντήσετε, θα συμπεράνει μια απάντηση, και η απάντηση που θα συμπεράνει θα είναι χειρότερη από την αλήθεια.

Βήμα 6 — Ενοποιήστε και ελέγξτε την ποιότητα σε κάθε σελίδα, προτού δείξετε το αποτέλεσμα στον πελάτη.

Πρόκειται να δείξετε στον πελάτη τον ολοκληρωμένο ιστότοπο. Πριν το κάνετε, ανοίξτε τη σελίδα τιμών και τη σελίδα χαρακτηριστικών δίπλα-δίπλα. Ελέγξτε κάθε όνομα χαρακτηριστικού: ταιριάζουν; Ελέγξτε κάθε αριθμό: η σελίδα τιμών λέει «10 έργα», η σελίδα χαρακτηριστικών λέει «έως 10 έργα» και η αναφορά API λέει «μέγιστο 10» — είναι όλα τα ίδια; Ελέγξτε κάθε υπόσχεση: υπάρχει «απεριόριστα έργα» κάπου στον ιστότοπο, και αν ναι, ισχύει; Στη συνέχεια, αναζητήστε το δικό του λεξιλόγιο του προϊόντος: λέει «χώροι εργασίας» παντού ή γλιστράει σε «ομάδες»; Εδώ είναι που πιάνετε ότι η αρχική σελίδα λέει «δεν απαιτείται πιστωτική κάρτα» ενώ η διαδικασία εγγραφής ζητά πράγματι πιστωτική κάρτα στη δωρεάν δοκιμή — ακριβώς η κατηγορία ασυνέπειας που σκοτώνει την εμπιστοσύνη.

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

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

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

Τα επιφυλακτικά σχόλια που διατηρούν την ειλικρίνεια.

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

Δεύτερον, το χτίσιμο από μέσα προς τα έξω παράγει αργή ορατή πρόοδο στην αρχή. Ο πελάτης ζήτησε μια αρχική σελίδα και εσείς παραδίδετε έναν πίνακα τιμών και ένα έγγραφο περιορισμών. Θα αντιδράσουν, γιατί η αρχική σελίδα είναι αυτό που μπορούν να δείξουν σε επενδυτές και στην ομάδα τους. Η διαχείριση αυτής της προσδοκίας — δείχνοντάς τους πώς οι αποφάσεις της σελίδας τιμών διαμορφώνουν ό,τι ακολουθεί — είναι μέρος της δουλειάς, όχι αποτυχία της. Ένας τρόπος να διατηρήσετε τη δυναμική είναι να δημιουργήσετε νωρίς ένα πρόχειρο προσχέδιο της αρχικής σελίδας, σαφώς χαρακτηρισμένο ως δοχείο που περιμένει περιεχόμενο, ώστε ο πελάτης να δει τον προορισμό ενώ χτίζετε τον σκελετό.

Τρίτον, η λίστα περιορισμών αλλάζει. Οι τιμές αλλάζουν, τα API μεγαλώνουν, τα πακέτα πολλαπλασιάζονται. Το πλαίσιο υποθέτει ότι διατηρείτε το έγγραφο περιορισμών ενημερωμένο μετά την κυκλοφορία, γιατί ο ιστότοπος θα φθίνει τη στιγμή που θα πάψει να αντικατοπτρίζει τα πραγματικά όρια του προϊόντος. Αυτό είναι το κόστος συντήρησης της προσέγγισης από μέσα προς τα έξω: η πηγή αλήθειας είναι αληθινή μόνο αν κάποιος την κατέχει.

Συμπέρασμα.

Η πιο συνηθισμένη αποτυχία στα έργα ιστοσελίδων SaaS δεν είναι το αδύναμο κείμενο ή ο κακός σχεδιασμός — είναι οι σελίδες που διαφωνούν μεταξύ τους, επειδή χτίστηκαν με τη λάθος σειρά. Ξεκινήστε με τη σελίδα τιμών και την τεκμηρίωση API, όπου ζουν οι πραγματικοί περιορισμοί του προϊόντος· αντλήστε την προβολή χαρακτηριστικών από πραγματικές ροές εργασίας· συλλέξτε τις συχνές ερωτήσεις από πραγματικές συνομιλίες· και ολοκληρώστε με έναν έλεγχο συνέπειας που επαληθεύει αντί να διασώζει. Κάντε το σε μερικούς διαφορετικούς πελάτες και θα διαπιστώσετε ότι είναι λιγότερο δημιουργική διαδικασία και περισσότερο γραμμή παραγωγής — που, σε μια εταιρεία, είναι ακριβώς αυτό που θέλετε. Η δημιουργική δουλειά εξακολουθεί να υπάρχει· απλώς εφαρμόζεται εκεί που έχει τη μεγαλύτερη μόχλευση.