Po zakupie pliku: od zamówienia do działającego pobrania

Klient kupił szablon dekoracji i zamknął kartę z potwierdzeniem. Wieczorem wraca do pracy. Wiadomość znalazł w poczcie, lecz zawarty w niej przycisk otwiera logowanie do konta, którego przy zakupie nie zakładał. Plik istnieje, zamówienie istnieje, a papierowa dekoracja pozostaje wyjątkowo cyfrowa.

To fikcyjny sklep sprzedający zestawy do samodzielnego wydrukowania. Dostawa kończy się dla klienta dopiero wtedy, gdy odnajdzie właściwy zasób i może z niego skorzystać. Projekt strony powinien przeprowadzić go przez dostęp do zakupionego pliku, przerwę w pobieraniu oraz późniejszy powrót. Sama elegancka karta produktu nie opisuje tej drogi.

Zamówienie, uprawnienie i plik gotowy do pobrania

Rozpisz, co powoduje udostępnienie zasobu. Zapis zamówienia może poprzedzać potwierdzenie wymagane przez sklep. Plik może też czekać na ręczne przygotowanie, na przykład przy zamówieniu personalizowanego szablonu. Wtedy przycisk „Pobierz teraz” nie powinien pojawiać się tylko dlatego, że przeglądarka wróciła na stronę podziękowania.

WooCommerce uzależnia moment udostępnienia pobrań od ustawień produktu i zamówienia. Opcja nadania dostępu po płatności pozwala udostępniać pliki, gdy zamówienie jest jeszcze w realizacji, bez czekania na oznaczenie go jako zakończone. To reguła konkretnego systemu. W komunikacie sklepu należy opisać skutek dla klienta, zamiast przenosić wewnętrzną nazwę statusu bez wyjaśnienia.

W naszym przykładzie mogą wystąpić dwa jasne widoki. Pierwszy potwierdza przyjęcie zamówienia i wskazuje, gdzie pojawi się informacja o pliku. Drugi pokazuje gotowy zestaw oraz możliwość pobrania. Gdy plik wymaga przygotowania, trzeba ustalić rzeczywisty dalszy krok. Nie zastępuj brakującej reguły zdaniem „Już prawie gotowe”, powtarzanym bez końca.

Strona z gotowym zasobem powinna wskazywać pozycję zamówienia. Klient kupił dekorację Liście w formacie do druku A4, więc właśnie tę nazwę i wariant powinien zobaczyć. Wspólny przycisk „Pobierz plik” przy kilku różnych zamówieniach sprzyja pomyłce. Jeżeli zestaw zawiera kilka elementów, pokaż, czy przycisk pobiera całą paczkę, czy pojedynczy materiał.

Nazwy, format i wersja pomagają później rozpoznać plik na komputerze. Te informacje opisuje także projekt centrum materiałów do pobrania. W dostawie po zakupie dochodzi jednak wskazanie, do którego zamówienia należy zasób i dlaczego konkretny klient ma prawo go pobrać. Publiczna biblioteka i realizacja zakupu wymagają innych przejść.

Przy zakupie kilku plików nie utożsamiaj gotowości jednego z gotowością całego zamówienia. Zestaw standardowy może być dostępny od razu, a personalizowana karta czekać na przygotowanie. Widok powinien pokazać oba stany przy odpowiednich pozycjach. Klient nie powinien uznać brakującej karty za błąd archiwum tylko dlatego, że główny nagłówek mówi „Wszystko gotowe”.

Uzgodnij także rolę wiadomości. Może potwierdzać zamówienie, przekazywać gotowy plik albo informować o aktualizacji. Wiadomości transakcyjne sklepu powinny rozróżniać te zdarzenia w temacie i treści. Nie wysyłaj dwóch niemal identycznych podziękowań, z których dopiero drugie zawiera istotny przycisk, bez rozpoznawalnej informacji o gotowości.

Właściciel procesu powinien wiedzieć, kto usuwa problem, gdy zamówienie jest przyjęte, ale plik się nie pojawia. Może zawieść powiązanie wariantu z zasobem, przygotowanie pliku albo wysłanie powiadomienia. Strona dla klienta powinna pokazywać potwierdzony stan i drogę pomocy, która zachowa numer właściwej sprawy.

Jeszcze przed projektem pobierania rozróżnij dostawę kopii od wejścia do zasobu w innej usłudze. Shopify Digital Products opisuje oba warianty: plik wgrywany do sklepu oraz odnośnik do treści utrzymywanej u zewnętrznego dostawcy. W drugim przypadku logowanie i uprawnienia do treści ustawia się u tego dostawcy. Sam zakup nie wyjaśnia więc całej drogi otwierania.

W naszym przykładzie kupowany jest plik do druku. Gdyby sklep zamiast niego sprzedawał dostęp do edytowalnego projektu w innym serwisie, musiałby wcześniej pokazać wymagane konto oraz drogę wejścia. Przycisk „Pobierz PDF” nie pasowałby do takiego działania. W podsumowaniu zakupu zachowaj obiecaną postać zasobu. Klient nie powinien po fakcie odkryć, że aby otrzymać kopię, musi jeszcze użyć osobnego programu albo uzyskać dostęp do projektu w innym systemie.

Powrót bez konta i odzyskanie pobrania

Zakup bez rejestracji wymaga także powrotu do zakupionego zasobu. Konto może ułatwiać odnalezienie historii, ale nie powinno niespodziewanie stać się warunkiem dostawy w ścieżce, która go nie przewidywała. Zapisz, jak uprawniony klient dotrze do pliku po zamknięciu pierwszej strony.

W sklepie z dekoracjami może to być wiadomość z odnośnikiem do konkretnego zamówienia. Odbiorca powinien rozpoznać nadawcę, nazwę zestawu i cel przycisku. Jeśli link wymaga dodatkowego potwierdzenia, wyjaśnij ten krok w miejscu użycia. Gdy klient nie może skorzystać z pierwotnego adresu pocztowego, potrzebuje osobnej drogi wyjaśnienia, zgodnej z faktycznym procesem firmy.

Nie projektuj odzyskania jako dowolnego wpisania numeru zamówienia i natychmiastowego wyświetlenia pliku. Numer pomaga odnaleźć sprawę, ale sam nie musi potwierdzać prawa osoby pytającej. Zakres sprawdzenia ustala się z odpowiedzialnym zespołem. Interfejs powinien pokazać następny krok bez ujawniania przypadkowej osobie cudzej historii zakupów.

Dokumentacja Shopify Digital Products opisuje ponowne wysłanie wiadomości z tymi samymi linkami, z zachowaniem wcześniejszego zużycia limitu. Ponowienie wiadomości i zwiększenie dostępnej liczby pobrań są zatem różnymi czynnościami w tej aplikacji. Własny ekran pomocy powinien rozróżnić utraconą wiadomość od wyczerpanego dostępu.

Przy ponowieniu pokaż adres docelowy w zakresie, który jest odpowiedni dla tej ścieżki. Literówka z zakupu może sprawić, że kolejne wiadomości trafiają wciąż w złe miejsce. Zmiana adresu to jednak inna czynność niż ponowne wysłanie. Wymaga właściwego sprawdzenia uprawnienia oraz potwierdzenia nowego kontaktu zgodnie z procesem sklepu. Obsługa powinna widzieć, czy poprawiono dane, czy tylko ponowiono wysyłkę. Użytkownik otrzymuje wtedy konkretną informację o wykonanej pomocy, zamiast ogólnego „wysłaliśmy ponownie” bez zmiany przyczyny problemu.

Podobnie rozdziel link wygasły, dezaktywowany, limit wyczerpany oraz błąd pobierania. To nie cztery sposoby powiedzenia „spróbuj później”. Przy wygasłym uprawnieniu może być potrzebne przywrócenie przez obsługę. Przy błędzie połączenia sensowny będzie powrót do tej samej dostępnej pozycji. Komunikat ma wynikać z potwierdzonego stanu, który system rzeczywiście potrafi rozpoznać.

Przed rozpoczęciem podaj obowiązujące ograniczenia. Jeśli dostęp ma określoną ważność, pokaż ją przy zasobie i w odpowiedniej wiadomości. Gdy obowiązuje limit, ustal, co go zużywa w używanym rozwiązaniu: rozpoczęcie żądania, zakończony transfer czy otwarcie odnośnika. Klient nie powinien dowiadywać się dopiero po przerwie, że jego nieudana próba została policzona.

W naszej fikcyjnej ścieżce osoba otwiera wiadomość na telefonie, ale chce drukować z komputera. Taka praca wymaga przemyślanego przejścia z zadaniem na drugie urządzenie, zachowując rozpoznawalne zamówienie i zasób. Przyciski nie powinny sugerować, że samo otwarcie strony na telefonie zakończyło już pobranie na komputer.

Dostępu do kupionego pliku nie zastępuj bez wyjaśnienia ogólnym linkiem dla każdego odbiorcy. Projekt świadomego udostępniania rozróżnia adres dla uprawnionych osób od szerszego obiegu. W pomocy po zakupie chodzi o odzyskanie właściwego zasobu dla kupującego. Szybkie obejście może zmienić grono odbiorców, choć rozwiązuje pozornie tylko problem jednej wiadomości.

W Aeneia Design można połączyć stronę po zamówieniu, wiadomość i drogę odzyskania pobrania w jeden przewidywalny proces. Materiałem do projektu są rzeczywiste ustawienia sklepu oraz przykłady wyjątków. Dzięki temu teksty przy przyciskach opisują dostępne działania, a obsługa nie musi za każdym razem wymyślać sposobu dostarczenia kupionego zestawu.

Co pobrano i co będzie dostępne po poprawce

Kliknięcie przycisku uruchamia próbę pobrania. Nie potwierdza, że plik znalazł się w wybranym folderze i otworzył w potrzebnym programie. Na stronie można pokazać rozpoczęcie pobierania oraz instrukcję odnalezienia go w przeglądarce, ale komunikat o zakończeniu wymaga odpowiedniej podstawy. Nie zapisuj „Twój zestaw jest już na komputerze”, gdy strona zna wyłącznie kliknięcie.

MDN opisuje nagłówek Content-Disposition, który wskazuje wyświetlenie treści w przeglądarce albo pobranie jej jako załącznika i może sugerować nazwę pliku. To ustawienie odpowiedzi serwera. Projekt powinien odróżniać przyciski otwierające podgląd od tych, które rozpoczynają dostawę kopii, oraz sprawdzić rzeczywiste zachowanie używanego rozwiązania.

Przy odbiorze zamówienia testowego przejdź także otwarcie pobranej paczki. Zestaw Liście powinien zawierać właściwe arkusze oraz instrukcję, jeśli należy do zakupionej pozycji. Zapisz wersję i porównany wariant. Nie traktuj technicznie poprawnego transferu niewłaściwego zestawu jako udanej dostawy. Klient nie zamówił przecież dowolnego pliku o poprawnym rozszerzeniu.

Jeśli paczka ma trzy elementy, odbiór powinien objąć każdy z nich: okładkę, arkusze do druku oraz instrukcję. Otwarcie okładki PDF nie potwierdza obecności arkuszy do druku i osobnej instrukcji. Zapis próby może wskazywać, które pozycje otwarto, na jakim urządzeniu i co porównano z ofertą. Przy błędzie jednego elementu droga pomocy powinna zachować nazwę zestawu oraz wadliwego pliku. Zespół może wtedy poprawić odpowiedni zasób, zamiast prosić klienta o ponowne opowiedzenie całego zakupu.

Zmiana zasobu po zakupie wymaga znanej reguły. Czy poprawiony plik zastępuje wcześniejszy pod tym samym dostępem? Czy jest nowym elementem przyznawanym odrębnie? Czy kupujący ma otrzymać informację o zmianie? To decyzje o realizacji konkretnej oferty; nie należy odgadywać ich z faktu, że w panelu pojawił się przycisk „Dodaj plik”.

WooCommerce rozróżnia zmianę istniejącej pozycji pliku od dodania nowej: pierwsza aktualizuje linki dawnych zakupów, druga nie nadaje im automatycznie nowego pobrania. Według dokumentacji przy zmianie istniejącego wiersza system zachowuje termin ważności oraz pozostałą liczbę pobrań. Te szczegóły trzeba uwzględnić przy projektowaniu aktualizacji w tym systemie.

Jeżeli sklep poprawił błąd w szablonie, sama podmiana pliku może więc nie rozwiązać sprawy osoby z wygasłym lub wyczerpanym dostępem. Zespół potrzebuje drogi dostarczenia aktualnej wersji zgodnie z ustalonymi zasadami. Wiadomość o poprawce powinna prowadzić do zasobu, który odbiorca faktycznie otworzy, zamiast ponownie kończyć się komunikatem o braku dostępu.

W próbie aktualizacji uwzględnij klienta, który pobrał dawną wersję, oraz osobę, która jeszcze nie rozpoczęła pobierania. Zapisz oczekiwany rezultat dla obu. Przygotuj też przypadek wcześniejszej wiadomości otwieranej po zmianie zasobu: do której wersji ma wtedy prowadzić jej adres? To pozwala odebrać rzeczywisty obieg poprawki. Samo sprawdzenie świeżo wygenerowanego przycisku w panelu administracyjnym pomija stare odnośniki nadal obecne w skrzynkach kupujących.

Przy wielu wydaniach pokaż, które zostało pobrane i do którego prowadzi aktualny przycisk, w granicach danych dostępnych w sklepie. Wewnętrzna historia serwera nie zawsze mówi, czy klient zachował i otworzył konkretną kopię. Ułatwiaj rozpoznanie przez nazwę oraz wersję, bez przypisywania systemowi wiedzy o dalszej pracy na cudzym urządzeniu.

Na odbiór wybierz jedno zamówienie gościnne, zamknij początkową kartę i wróć do pliku tak, jak zrobi to kupujący. Potem przejdź przypadek utraconej wiadomości oraz udostępnionej poprawki. Dostawa działa, kiedy odbiorca dociera do właściwego zasobu z zachowaniem swojego uprawnienia. Dopiero wtedy może zająć się papierem, zamiast studiować organizację sklepu.