Energetics eBOK to przestrzeń kontaktu między spółdzielnią energetyczną a jej członkami. Widzą oni wczorajsze dane z własnych urządzeń, rozliczenia, komunikaty o awariach, zdarzenia spółdzielcze i skargi - krytyczne narzędzie zapewniające przejrzystość wewnątrz spółdzielni.
eBOK znajduje się wewnątrz Elektronicznej Platformy Zarządzania Spółdzielnią Energetyczną, która pobiera dane pomiarowe i profile energetyczne z CSIRE, rozlicza i bilansuje energię wewnątrz spółdzielni oraz daje zarządom realne narzędzia do dostarczania wymiernych oszczędności. Platforma służy zarządowi, eBOK służy członkom, a razem budują zaufanie w oparciu o wspólny zestaw liczb.
Dwa silne ograniczenia: istniejąca techniczna makieta internetowa gęsta od tabel i kierunkowa prośba założyciela o coś nowoczesnego i ambitnego. Brak bezpośrednich analogów na rynku - aplikacje energetyczne i ogólne rachunki elektroniczne w najlepszym razie obejmowały problem w 50%.
Oznaczało to dwie równoległe ścieżki nauki. Musieliśmy nauczyć się Model spółdzielni energetycznej od podstaw - Zarówno mechanika energii, jak i stojący za nią biznes - a strona użytkownika również nie została zmapowana, ponieważ większość przedsiębiorców, z którymi rozmawialiśmy, nigdy nie słyszała o tej koncepcji. Jednocześnie musieliśmy przełożenie makiety desktopowej z dużą ilością danych na makietę mobilną bez utraty głębi, bez istniejących wzorców, na których można by się oprzeć - każdy ekran wymagał kadrowania tego, co zachować, co skompresować, a co wymyślić.
Sześć miesięcy dla produktu o takim zasięgu to niewiele. Proces musiał zostać zoptymalizowany na każdej warstwie, a w kilku punktach był sprzeczny z procedurami podręcznikowymi. Nie dla mody, ale dlatego, że wymagał tego kształt projektu.
Pierwsze tygodnie to były badania, a nie projektowanie. Rozmawialiśmy z przedsiębiorcami prowadzącymi 50-60-osobowe firmy pod Poznaniem, pytając, co myślą o fotowoltaice, rachunkach za energię i co skłoniłoby ich do przystąpienia do spółdzielni. Równolegle analityk wykorzystał LLM jako eksperta tematycznego na żądanie w zakresie CSIRE, rozliczeń i otoczenia regulacyjnego. Model przyspieszył krzywą uczenia się w dziedzinie nowej dla zespołu. Nie zastąpił on rozmów z prawdziwymi użytkownikami.
Większość projektów zaczyna się od szkieletów. My tego nie zrobiliśmy. Przeskoczyliśmy od razu do kolorowych ekranów hi-fi, aby klient i zespół mogli zobaczyć prawdziwy produkt od pierwszego tygodnia zamiast abstrakcyjnych pudełek. Istniejąca makieta internetowa dała nam wystarczającą podstawę strukturalną, aby całkowicie pominąć rundę szkieletową, co skróciło czas i usunęło całą pętlę przeglądu ekranów, które i tak zostałyby wyrzucone.
Nie jest to domyślne rozwiązanie, które zalecamy. Działa tylko z wiarygodnym strukturalnym punktem wyjścia i zespołem wyższego szczebla, który może utrzymać rygor UX przy wysokiej wierności - oba warunki były tutaj spełnione.
Całodniowe warsztaty, zwykle będące wydarzeniem inauguracyjnym, odbyły się w samym środku projektu. Osiem perspektyw - architektura, rozwój, projektowanie, marketing, sprzedaż, księgowość, produkt, rozliczenia - siedziało w jednym pokoju z prawdziwymi ekranami już na stole. Informacje zwrotne były ostrzejsze, decyzje szybsze, a kształt MVP zestalił się w ciągu jednego dnia.
Po warsztatach pracowaliśmy bez ustalonych sprintów, łącząc synchroniczne rozmowy przeglądowe z asynchronicznymi instruktażami wideo. Ten rytm zadziałał, ponieważ zespół był starszy i samokierujący - w mniej doświadczonym zespole wprowadzilibyśmy z powrotem twardą kadencję sprintów.
"Tempo i jakość wymiany informacji były idealne. Asynchroniczne instrukcje wideo były naprawdę dobrym pomysłem - można spokojnie słuchać, wstrzymywać, przewijać. Nie sprawdziłoby się to w przypadku mniej doświadczonego zespołu. W tym przypadku idealnie pasowało do przepływu"."
Marcin Cichosz, główny analityk i architekt systemu
Trzy komponenty stanowiły większość złożoności projektu. Dla każdego z nich podajemy, czego próbowaliśmy najpierw, dlaczego się nie udało i gdzie wylądowaliśmy.
Najtrudniejszy ekran w aplikacji. Trzy iteracje, aby się tam dostać.
Komplikacją była skala. Pojedynczy punkt PPE może przechowywać dziesiątki lub setki zdarzeń, a ten sam komponent musiał obsługiwać dwa scenariusze jednocześnie: porównywanie kilku punktów i wiercenie w jednym. Iterowaliśmy przez kilka wersji roboczych, zanim model kart utrzymał oba przypadki w czystości.
Użytkownik z jednym punktem PPE jest łatwy. Użytkownik z setkami już nie. Ekran musiał wchłonąć ten zakres bez przytłaczania 30-letniego założyciela przeglądającego liczby na telefonie lub 65-letniego właściciela fabryki, który otwiera aplikację tylko po to, aby sprawdzić wynik finansowy.
Rozwiązaliśmy to za pomocą warstwowego modelu filtrowania i agregacji: domyślne ustawienia, które w pierwszej kolejności wyświetlają najbardziej przydatne porównania, elementy sterujące, które w razie potrzeby skalują się do analizy wielopunktowej, oraz wizualny rytm, który utrzymuje ekran cichy u góry i gęsty w dalszej części.
Wykresy wyglądały na proste, a okazały się najbardziej niestandardowym elementem systemu. Dwa skrajne przypadki przełamały typowy schemat.
Rezultatem jest niewielki zestaw niestandardowych wzorców wykresów stworzonych specjalnie dla tej aplikacji. Są one mniej fotogeniczne niż pączek z nadzieniem. Mówią prawdę.
Energetics eBOK to jedna z niewielu rzeczy, które widziałem w ciągu ostatniego roku, które można szczerze nazwać zmianą gry. Tradycyjne portale działają tylko wtedy, gdy stajesz się klientem. eBOK działa na odwrót - najpierw daje wartość, a współpraca rozwija się wokół niego.
Mieliśmy zdrową konfigurację. Proponowałem rozwiązanie, a zespół UX krytycznie je oceniał. Zwracali uwagę na rzeczy w modelu mentalnym użytkownika, które ja bym przeoczył. Dbałem o to, czy na ekranie znajdują się właściwe informacje. Oni dbali o to, czy zostały one przedstawione w sposób, na który użytkownik mógł faktycznie zareagować.
Iteracja była motorem napędowym projektu. Lepiej wysłać pierwszą wersję i iterować, niż dopracować idealną wersję, która i tak zostanie zmieniona. W przypadku tego zespołu takie podejście faktycznie przyspieszyło pracę.
Marcin Cichosz, główny analityk i architekt systemu
eBOK jest pozycjonowany zarówno jako portal członkowski, jak i kanał pozyskiwania nowych spółdzielni. Tradycyjny model portalu zakłada, że użytkownik jest już klientem. Ten produkt zapewnia wartość przed tym momentem i przyciąga ludzi.
Skompresowany proces dostarczania (hi-fi od pierwszego dnia, warsztaty w środku, MVP dostarczone w ciągu sześciu miesięcy), który przekłada się bezpośrednio na mniejszy budżet i krótszy czas wprowadzenia produktu na rynek. Przekazanie partnerowi programistycznemu (MicroSolutions) było na tyle proste, że wdrożenie odbyło się bez dodatkowego wsparcia projektowego.
Spółdzielnie energetyczne wspierają efektywność, lokalną niezależność i modernizację polskiej sieci poprzez utrzymywanie większej ilości energii lokalnie. eBOK jest widoczną częścią tej zmiany dla członków.
Poza ekranami, oto co współpraca z nami oznaczała dla Energetics IT i stojącej za nią spółdzielni.
Zespół Uxtivity przyjął rolę rzecznika użytkownika, uważnie oceniając każdy aspekt UX aplikacji i proponując przemyślane, dobrze przemyślane rozwiązania.
Tempo było idealne, a projekt na tyle przejrzysty, że programiści poradzili sobie z nim bez dodatkowego wsparcia. Bez wahania ponownie podjąłbym współpracę z tym zespołem.
Jeśli Twoja aplikacja, portal lub platforma wymaga takiego samego poziomu rygoru UX i rzemiosła UI, nasza usługa Product Design jest do tego stworzona.
