HTML Preload i HTTP/2 Push w praktyce

Bardzo prostą metodą na istotne polepszenie ładowania strony jest preloadowanie i pushowanie danych w trakcie jej pobierania. Celowo wymieniam preload i push osobno, gdyż często uznawane, za tożsame, a jednak są między nimi różnice.

HTTP/2 Push przede wszystkim możesz wysłać jeszcze przed „nadaniem” response do przeglądarki, użytkownik otrzyma je więc bardzo szybko, zanim jeszcze dotrze do niego dokument HTML ze stroną. To różnica względem HTML Preload, który jest przesyłany wraz z Response, a więc w praktyce nieco później.

Tu poznasz szczegóły jak wysłać:

Co w praktyce daje preloadowanie/pushowanie danych?

Dostarczenie danych poprzez push spowoduje, że przeglądarka będzie miała do nich dostęp dużo szybciej. W ten sposób:

  • ograniczasz zjawisko render-blocking w niektórych JavaScript jak i CSS
  • minimalizujesz łańcuch krytycznych zapytań
  • przyspieszasz First Paint

Czy powinieneś więc pushować wszystkie zasoby dostępne na stronie?

Nie.

Ogranicz się do arkuszy z krytycznym CSS, obrazów pojawiających się above-the-fold i przede wszystkim fontów (pamiętaj o użyciu font-display: swap). Pozostałe zasoby ładuj tradycyjnymi metodami.
Inaczej możesz uzyskać efekt odwrotny od oczekiwanego.

Jak przekazać projekt UX/UI i zachwycić developerów

Ostatni rok w Autentice, to znaczący wzrost liczby projektów, w których jesteśmy odpowiedzialni wyłącznie za etap projektowania UX/UI. Wymagało to od nas nowego podejścia do momentu przekazania efektów pracy zewnętrznemu zespołowi.

“Czym to się różni od projektu, w którym wdrożenie robicie sami?” – zapytasz. Przede wszystkim –  komunikacja, a w zasadzie jej mocno utrudniona wersja, gdy nad projektem pracują niezależne zespoły. Dwie firmy (trzy z klientem!), nieznani sobie ludzie, inne procedury, brak wspólnych doświadczeń i kontaktu w czasie rzeczywistym. Tu nie ma miejsca na pozostawienie niedopowiedzeń na kolejne etapy, liczenie na błyskawiczne konsultacje w razie wątpliwości. Wiedza musi być możliwie kompletna tu i teraz. Co więcej, wiedza usystematyzowana i podana w sposób, który nie sprawi problemu osobom stykającym się pierwszy raz z naszą pracą.

Mają do nas nie dzwonić!

Wiem, brzmi dziwnie i oczywiście potraktuj to z przymrużeniem oka. Taki jednak cel postawiliśmy sobie, układając w głowie plan na zawartość finalnie przekazywanej “paczki”. Chcemy wyjść naprzeciw oczekiwaniom developerów i dostarczyć maksymalnie bogaty zestaw materiałów i informacji. Koniec z prośbami “Który ekran mamy wyświetlić po rejestracji?”, czy  “Dajcie mi ikony z tego ekranu”. Jako projektanci jesteśmy stale do dyspozycji, ale niech to nie będą pytania, które stawiają nasze kompetencje w złym świetle!

Co ważne, całość miała być do bólu powtarzalna po naszej stronie. Niezależnie od projektanta i projektu, każdy ma jasną instrukcję co i jak ma wytworzyć.

Do rzeczy! To co tam dajecie?

#1 Etap poznania

Na początku tworzymy kartę projektu. Zbiera ona informacje o celach biznesowych, ich miarach i sposobach mierzenia sukcesu. Przedstawia również zespół oraz interesariuszy. Sam projekt jest opisywany w postaci wysokopoziomowego zakresu, taki “helicopter view”. Wymienione są ryzyka i ograniczenia. Wreszcie pojawia się uzgodniony harmonogram oraz budżet i model rozliczeń.

Część “mięsną” nazywamy kartą produktu. Przy jej tworzeniu kierujemy się metodologią User Centered Design. Przygotowujemy charaktersytykę grupy docelowej wraz z jej problemami, motywacjami i obawami. Produkt opisany jest przez pryzmat sposobów na rozwiązanie problemów użytkowników, a także istniejących do produktu alternatyw. Tę część podsumowuje określenie przewag konkurencyjnych planowanego przedsięwzięcia oraz unikatowej wartości – korzyści jaką odniesie użytkownik, korzystając z produktu.

Rozdział dotyczący rynku to opis branży oraz lokalna i zagraniczna konkurencja. Najczęściej towarzyszy temu szczegółowa analiza konkurencji, która sama w sobie może być kilkusetstronicowym opracowaniem.

Podczas rozmów o warstwie technologicznej projektu, zbieramy informacje dotyczące środowiska, w jakim będzie funkcjonował: urządzeń, systemów, oprogramowania. Szczególnie interesuje nas ich wpływ na możliwości i ograniczenia dotyczące obszaru UX/UI.

Na tym etapie analizujemy również badania prowadzone przez klienta w przeszłości. Dane z Google Analytics, Hotjara czy badań jakościowych są przekuwane na konkretne wnioski, które pomogą nam podjąć właściwe decyzje na etapie projektowania. Tu często pojawiają się rekomendacje kolejnych metod analizy potrzeb i zachowań użytkowników.

Ostatnia część karty produktu to język komunikacji. Zapoznajemy się z marką klienta, jej znakiem i księgą identyfikacji, stylem języka pisanego,  a także design systemem, choć to wciąż rzadkość nawet w korporacjach. Badamy również osoby decyzyjne pod kątem preferowanego stylu graficznego (tzw. draftest, autorska metoda).

Ku pamięci zapisujemy większość pytań i odpowiedzi z przeprowadzonych z klientem wywiadów. Często w przebiegu projektu wygodnie jest do nich wrócić i przypomnieć stanowisko zamawiającego w danej kwestii.

#2 Etap idei

Zakres funkcjonalny rozwiązania najpierw dzielimy na obszary, moduły. Pozwala to stworzyć szkielet, w którym łatwo odnaleźć interesujący nas proces (stąd nazwa “Mapa procesów”). Tym bardziej, że od początku narzucamy uporządkowany model numerowania. Dla przykładu:

01. Aktualności
01.01 Administracja aktualności
01.01.01 Dodawanie aktualności

Przebieg każdego z procesów przedstawiamy obrazowo na diagramie. W jasny sposób pokazuje on początek, kolejne kroki aż po wynik danego scenariusza.

Czytanie i zrozumienie diagramów nie wymaga technicznych kompetencji.

Diagramy pozwalają nam sprecyzować konkretne wymagania dotyczące widoków do zaprojektowania. Dzięki temu otrzymujemy “Mapę widoków” składających się na kompletny interfejs projektu. Kontynuując porządek narzucony w Mapie procesów, ekrany otrzymują numerację dziedziczoną z procesu, do którego należą:

01. Aktualności
01.01 Administracja aktualności
01.01.01 Dodawanie aktualności
01.01.01.01 Aktualności – Administracja – Dodawanie – Formularz
01.01.01.02 … – Formularz – Walidacja

Stąd już prosta droga do…

#3 Etap projektowania

Paczka plików powstających w fazie projektowania to rynkowy standard:

  • makiety wysokiej szczegółowości każdego z widoków wraz ze stanami (walidacja, interakcje). Oczywiście w wersji desktop i mobile,
  • projekty graficzne przygotowane na podstawie makiet,
  • źródłowe pliki .sketch makiet i grafik z uporządkowaną organizacją artboardów i warstw,
  • prezentacja projektu w Invision wraz z historią komentarzy z etapu recenzowania ekranów,
  • UI Kit – zbiór  elementów graficznych wraz ze stanami i interakcjami składającymi się na interfejs systemu,
  • klikalny prototyp (jeśli wymagany) w Invision,
  • animacje, przedstawiające zachowanie interaktywnych elementów,
  • fonty użyte w projekcie,
  • assety, czyli materiały graficzne wchodzące w skład zawartości strony (ikony, zdjęcia, ilustracje), najczęściej wyeksportowane do formatu .svg, .png, .jpg

I tu, gdzie wielu projektantów kończy swoją pracę, my dorzucamy porcję solidnego mięsa dla zespołu wdrożeniowego…

#4 Etap idei, ciąg dalszy – wymagania

Tak, wracamy do Mapy procesów, dokumentu którego fundament położyliśmy wcześniej. Bogatsi o decyzje podjęte na etapie projektowania, musimy uzupełnić widoki o część opisującą szczegółowo wymagania.. Grafika, choć mówi wiele, nie daje poglądu na to, co dzieje się poza ekranem, od strony systemu, zarządzania.

Procesy uzupełniamy o wymagania funkcjonalne i pozafunkcjonalne (jakościowe, wydajnościowe). Wraz z diagramem tworzą kompendium wiedzy o każdej funkcji systemu.

W uzupełnieniu opisujemy mikrointerakcje, często linkując do powstałych animacji.

 Każdy formularz jest rozkładany na czynniki pierwsze do formy gotowej do wdrożenia.

Nazwa procesu, label, typ, wymóg, placeholder, captio, tooltip, komunikaty błędów i sukcesu, interakcje, zakres danych, formatowanie specjalne, limit liczby znaków ze spacjami, uwagi. Tak opisujemy każde pola formularza.

Opcjonalnie, w zależności od zakresu naszej odpowiedzialności, rekomendujemy podstawowe parametry ekranów procesu: konstrukcję URL, Tag Title, Tag Desc, OG: tytuł, OG: opis, OG: obraz.

TL;DR

W naszym rozumieniu dopiero taka paczka stanowi rzetelną bazę, na której może pracować zewnętrzny zespół developerów. Podsumujmy więc:

Etap poznania

Karta projektu

Karta produktu

Badania

Analiza konkurencji
Etap idei

Mapa procesów

Diagramy procesów

Mapa widoków

Wymagania procesów
Etap projektowania

Makiety

Prototyp klikalny

Projekt graficzny

UI Kit

Animacje

Fonty

Assety

Mamy cichą nadzieję, że niejeden Project Manager i programista z satysfakcją zaklnie pod nosem i stwierdzi, że “Ci w Autentice to znają się na rzeczy”. 

A Ty, w jakiej formie dostałeś/-aś ostatnio projekt do wdrożenia?

Sprzedaj produkt, zanim go wyprodukujesz, czyli jak stworzyć skuteczne MVP

Masz pomysł na rewolucyjny produkt lub usługę i czujesz w kościach, że to się sprzeda. Odpuszczasz więc sobie badanie rynku i potrzeb potencjalnych klientów. Już na starcie angażujesz duże siły i środki w realizację Twojego projektu. Zanim ujrzy światło dzienne, chcesz, żeby był dopracowany w każdym szczególe. W dniu premiery mocno zaciskasz oczy i… 

…nie dzieje się zupełnie nic. Sprzedajesz mało, pierwsi klienci są sceptyczni i wytykają Ci wiele błędów. Poprawki pożerają kolejne transze z zaplanowanego budżetu aż w końcu tracisz motywację do dalszego działania i zwijasz biznes. 

To scenariusz, który nie tak rzadko ma miejsce w rzeczywistości. A szkoda, bo rozwiązanie tego problemu jest stosunkowo proste i tanie, a jego clou zawiera się w trzech literach – MVP.

MVP – nie podbijaj świata. Na początek wystarczy kilka umysłów

MVP to skrót od angielskiego wyrażenia minimum viable product, czyli minimalna wersja produktu lub usługi, dzięki której zmierzysz poziom zainteresowania klientów. 

Najprościej mówiąc, zamiast od razu pompować pieniądze w gotowe rozwiązanie, na początek oceń wartość swojego pomysłu, wypuszczając na rynek wersję realizującą jedynie najważniejsze założenia.

Ba! Nie musisz nawet przygotowywać gotowego prototypu. Czasami wystarczy landing page czy podlinkowana makieta. Od tego zaczynał Uber (pierwsza aplikacja była dostępna w jednym mieście), Facebook (portal zrzeszał wyłącznie studentów Harvardu) czy Dropbox (twórcy wypuścili filmik prezentujący możliwości tej usługi).

Marzy ci się aplikacja do adopcji psów w stylu Tindera? Twoim początkowym MVP może być zabawny profil na Facebooku ze zdjęciami i podpisami utrzymanymi w tej konwencji. 

MVP co do zasady ma być szybki i tani w realizacji. Jego zadaniem jest bowiem sprawdzenie, czy istnieje zapotrzebowanie na nasz produkt, a także dostarczenie nam cennych informacji zwrotnych od potencjalnych klientów. 

To ponadto dobry sposób na zbudowanie bazy kontaktów do osób, które są zainteresowane projektem. Gdy będzie już gotowy, wystarczy jedno kliknięcie myszki, by dotrzeć do konsumentów z tą wiadomością.   

Jak stworzyć skuteczny MVP? Cały proces można zamknąć w trzech krokach.

Stwórz hipotezy

W MVP chodzi o to, żeby zyskać jak najwięcej wiedzy w jak najszybszym czasie. Aby jednak wiedzieć, gdzie i czego szukać, na początek należy stworzyć hipotezy dotyczące produktu. Warto zacząć od potrzeb rynku, to znaczy zdefiniować problem, który nasz projekt rozwiązuje. 

Drugim ważnym elementem hipotez jest analiza konkurencji. Jakie rozwiązania proponują inni? Które z nich możemy zaimplementować, a które usprawnić?

Trzecią istotną sprawą jest określenie grupy docelowej. Tutaj nie wystarczą ogólniki. Jasno sprecyzowane persony pozwolą nam lepiej zrozumieć oczekiwania użytkowników oraz ich bolączki. 

Coraz więcej mężczyzn towarzyszy swoim partnerkom podczas porodów. Wpadłeś na pomysł aplikacji, która pomogłaby im przygotować się do tego wydarzenia. Twoim idealnym użytkownikiem mógłby być więc: trzydziestokilkulatek, mieszkaniec dużego miasta, dobrze zarabiający manager, entuzjasta zdrowego stylu życia, który interesuje się naturalnym rodzicielstwem i jest liderem wśród fanów na profilu Blog Ojciec.   

Kiedy już zbierzemy teorię w całość, pora na sprawdzenie, czy nasze założenia znajdują odbicie w rzeczywistości.

Przetestuj swoje założenia

Hipotezy mają to do siebie, że czasami nie są trafione. Może się bowiem okazać, że nasza grupa docelowa nie potrzebuje danego produktu lub proponowane rozwiązania są mało skuteczne. Jak to sprawdzić? Jak mówi “stare polskie przysłowie” – jak najszybciej 🙂 

Sposobów na przetestowanie założeń jest wiele. Można zacząć od rozmów ze specjalistami, wrzucania postów na grupy Facebookowe, zadawania pytań na forach czy przeprowadzania ankiet. 

Do samej prezentacji produktu przydadzą się landing page, blog, film czy makieta zrobiona w narzędziu typu Invision. Na różnych etapach można także wykorzystać testy A/B, reklamę na Facebooku lub w Google oraz założyć zbiórkę na portalu crowdfundingowym. 

Wymyśliłeś aplikację, której zadaniem jest monitorowanie i zwiększenie efektywności pracy freelancerów pracujących zdalnie. Po rozmowach z różnymi grupami docelowymi okazało się, że chętnie skorzystaliby z niej także maturzyści i studenci, którzy mają problem ze skupieniem uwagi na nauce. To dla Ciebie ważna wskazówka, która może nakierować projekt na inne tory.

Celem tych wszystkich działań jest zbadanie, kto tak naprawdę interesuje się naszym produktem i w jaki sposób go udoskonalić, aby faktycznie rozwiązywał problemy klientów.

Ucz się i zmieniaj 

W tej fazie posiadamy już wiedzę, która pozwoli nam stworzyć m.in. mapę pain and gain, w której określimy, jakie bolączki mają realni odbiorcy i jakie są ich cele. To także dobry czas na dopracowanie journey map, czyli szczegółowego opisu styczności użytkownika z usługą, w którym krok po kroku przedstawimy, co dzieje się na każdym etapie tego procesu.

Warto jest również określić priorytety – zdecydować, które elementy trafią do MVP, nad którymi trzeba się zastanowić, a które od razu odrzucamy. Możemy ponadto dokonać analizy, ile nas będzie kosztowało dotarcie z produktem do grupy docelowej, jaki będzie zwrot i kiedy można się go spodziewać. 

Po fazie testów okazało się, że z Twojej aplikacji do wyszukiwania szpitali zajmujących się terapią konkretnych schorzeń oraz nowotworów chętniej skorzystaliby ludzie młodzi, którzy walczą o zdrowie swoich rodziców. Postanawiasz więc rozbudować jej funkcje, dodając praktyczne rady dla osób towarzyszących.  

Design Sprint, czyli przetestuj swój pomysł w 5 dni 

W Autentice stworzyliśmy wiele produktów, które zaczynały się wyłącznie od idei. Lata doświadczeń pozwoliły nam wypracować proces do testowania pomysłów i szybkich MVP. Czerpie on zazwyczaj z dwóch metodologii: The Lean Startup oraz Design Sprint. 

Zwykle dla swoich klientów organizujemy warsztat, który pomaga nam zebrać i uporządkować wiedzę, a także określić cele. Przy odpowiednim zaangażowaniu obu stron, ramy MVP możemy zaplanować zaledwie w 5 dni! Tydzień wystarczy, by ocenić, czy Twój pomysł faktycznie ma potencjał i warto inwestować w niego kolejne środki.

Czy Twoja firma potrzebuje aplikacji mobilnej?

Aplikacje mobilne nigdy wcześniej nie były tak istotną częścią codziennego życia jak teraz. W ciągu ostatniej dekady powszechność i dostępność urządzeń mobilnych doprowadziła do tego, że korzystanie z aplikacji stało się oczywistością. Ułatwia to nawiązywanie i podtrzymywanie kontaktów z klientami, a także przyciąganie i zdobywanie uwagi nowych. Ale czy jest to jednak wciąż narzędzie zarezerwowane dla największych graczy?

Czy aplikacja jest naprawdę potrzebna?

Aplikacje mobilne z pewnością nie są dla wszystkich. W Google Play i App Store znajdziemy ich miliony, jednak badania pokazują, że przeciętny użytkownik korzysta z 25 aplikacji miesięcznie, ale przez znaczącą większość czasu skupia się tylko na 10 z nich.  Czy to przekreśla sens tworzenia nowych aplikacji dla firm i instytucji? Absolutnie nie, ważne jednak, żeby pamiętać o kilku kluczowych warunkach.

  • Przede wszystkim warto jasno określić grupę docelową i cel aplikacji. Czy aplikacja ma służyć do użytku wewnętrznego czy ma być publiczna? Czy będzie z niej korzystać niewielka, określona liczba pracowników czy będzie ona otwarta? A jeśli tak – to czy dobrze znamy grupę ludzi, którzy mogą być nią zainteresowani?
  • Jaka będzie wartość aplikacji dla użytkownika? Dlaczego miałby zdecydować się ją pobrać i czy później znajdzie się ona wśród tych, do których będzie regularnie powracać?
  • Czy aplikacja będzie w jakiś sposób reklamowana? Jakimi sposobami potencjalni użytkownicy będą mogli się o niej dowiedzieć? Czy będą w jakiś sposób zachęcani, czy będzie się to dla nich wiązać z jakimiś przywilejami?
  • Czy wdrożenie aplikacji może przynieść firmie wymierne korzyści?

Kiedy stworzenie aplikacji mobilnej ma sens?

Aplikacje mobilne mogą być jednym z najpotężniejszych narzędzi do kontaktu z obecnymi i potencjalnymi klientami. Ważne jednak, żeby były one dobrze przebadane, przemyślane i zaprojektowane, bo kiepska aplikacja może się szybko okazać gorszym wyborem niż jej brak. Jakie korzyści może jeszcze nieść taka inwestycja?

Lojalność i zaangażowanie

Aplikacje, które budują i nagradzają lojalność oraz zaangażowanie klientów są jednymi z najpopularniejszych i najbardziej lubianych w Polsce – pozwalają gromadzić punkty, wymieniać je na nagrody czy przekazywać na cele charytatywne. Mogą także dawać inne przywileje – jak na przykład szybsze zamówienie jedzenia czy ominięcie kolejki.

Widoczność i rozpoznawalność marki

Aplikacje pozwalają znacznie zwiększyć świadomość marki – chociażby przez częsty kontakt z jej logiem i komunikacją firmy. Ważne jest jednak, aby nie epatować użytkowników naszym brandem. W centrum uwagi musi być odbiorca, a nie nasze logo. 

Aplikacje są kanałami bezpośredniej komunikacji z klientem

Aplikacje mogą uczyć się gustów klientów i bazując na tym informować o cenach, promocjach, nowościach, ułatwiać rezerwację czy składanie zamówienia. Jednocześnie mogą wysyłać wiadomości push, które są skuteczniejsze niż smsy i emaile, a także zawierać komunikator do bezpośredniego kontaktu klienta z firmą.

Aplikacja może pomóc wyróżnić się wśród konkurencji

Dobrze dopasowana do potrzeb klientów aplikacja może pełnić funkcje narzędziowe i być w ten sposób dyskretną reklamą firmy. Przykładem takiej aplikacji może być narzędzie wspomagające obliczenia konstrukcyjne na potrzeby prac budowlanych wypuszczone przez firmę szalunkową. Dla firm wytwarzających różnego typu sprzęty czy maszyny aplikacja może zmieniać urządzenie mobilne w panel sterowania, co może okazać się nie tylko oszczędnym, ale dużo wygodniejszym rozwiązaniem.

Aplikacje wewnętrzne dla firm – kiedy warto się nimi zainteresować?

Osobnym tematem wartym poruszenia są aplikacje do wewnętrznego użytku w firmie. Może być to przydatne narzędzie szczególnie dla pracowników nie mających ciągłego dostępu do komputera, na przykład w terenie lub w magazynie. Tego typu aplikacje klasy enterprise mogą przydać się w firmach produkcyjnych (na przykład ułatwiając nawigację wózkami widłowymi w celu szybszej realizacji wydawania zamówień z magazynu), biurze podróży (gdy posiadają niezbędne narzędzia dla pilotów wycieczek – od list uczestników po wysyłanie zbiorczych wiadomości z informacjami) czy w wypożyczalni samochodów lub rowerów (do zgłaszania usterek czy dokumentowania stanu). Tak naprawdę – ile firm, tyle pomysłów na usprawnianie funkcjonowania firmy z wykorzystaniem wewnętrznych aplikacji mobilnych.

Kiedy stworzenie aplikacji na pewno nie będzie dobrym pomysłem?

Nie warto jednak decydować się na tworzenie aplikacji mobilnych kierując się tylko modą. Efektywna i dobrze prowadzona aplikacja mobilna musi być ciągle rozwijana i udoskonalana, a także aktywnie reagować na zmiany rynku. Nie ma sensu więc zlecać jej tworzenia, kiedy firma nie planuje rozwijać produktu mobilnego w przyszłości. Jednocześnie najważniejsza rzecz, o której trzeba pamiętać może wydawać się dosyć banalna – końcowy produkt powinien czemuś służyć. Nie warto się na nią decydować, jeśli jej stworzenie ma być tylko pustą reklamą bez realnej korzyści dla klienta i mierzalnej korzyści dla firmy.

Warto pamiętać także o najważniejszym – niezależnie, czy celem stworzenia aplikacji mobilnej jest rozwiązywanie wewnętrznych problemów czy efektywna komunikacja z klientem, aplikacja powinna przyczyniać się do rozwoju firmy. Decydując się na nią warto skonsultować się z doświadczonymi specjalistami, którzy będą w stanie ocenić, czy i jaka forma aplikacji miałaby największy sens.

Hello World!

Aplikacje webowe, mobilne, e-commerce. Badania, projektowanie graficzne i UX, programowanie. To i pewnie jeszcze więcej znajdziecie na naszym blogu. Tak, w 2020 roku otwieramy blog i, ba, jeszcze się tym chwalimy!

Brzmi może śmiesznie, bo większość firm IT ma swoje blogi od wielu lat. Co więcej, część z nich z różnych przyczyn zdążyła je już pozamykać. “Po co więc to robicie?” – zapytasz. Przyczyn jest kilka, ale w skrócie, czujemy, że mamy sporo do opowiedzenia o rynku, projektach, metodach i narzędziach, których używamy na co dzień. Ostatni rok to znaczący wzrost liczby osób w naszej Grupie (jest nas niemal 30-tka!), więc rąk i umysłów nie braknie. A to, jak wie każdy, kto porwał się na prowadzenie bloga, jest najczęstszym problemem niepowodzenia takich przedsięwzięć. Czujemy, że to dobry czas, by podzielić się naszą wiedzą i ponad 14-letnim doświadczeniem.

Kim jesteśmy? My, to Grupa Autentika, czyli 3 marki zajmujące się tworzeniem oprogramowania:

Zasadniczo, mamy więc kompetencje w produkcji niemal wszystkiego, co może działać w przeglądarce lub natywnie na telefonie.

Bez lania wody

Będziemy pisać szczerze, starając się w każdym poście dawać konkretną wartość czytelnikowi. Od liczby odwiedzin bardziej interesuje nas Twoja opinia, więc postawimy na “mięso”.

A pisać zamierzamy o wszystkim na czym się znamy i za co cenią nas nasi klienci. Inspiracje i tematy wpisów będą pochodziły wprost z naszych projektantów i od deweloperów, co powinno zagwarantować poziom i świeżość treści.

Zresztą, zerknij na pierwsze materiały i sam oceń:

PS Daje radę? Tam niżej możesz zapisać się na nasz newsletter. Spokojnie, nie spamujemy.

PS 2 Gdybyś chciał poznać naszą opinię na jakiś temat, napisz na michal.samojlik@autentika.pl i postaramy się o tym napisać.