03 / Vaka çalışması · Ürün keşfi ve teslimat
HERA V1
Manuel üniversite operasyonlarını ilk dijital ürünlerine dönüştürmek.
HERA, Tazelenme Üniversitesi'nin parçalı kâğıt ve belge tabanlı operasyonlarının yerini yapılandırılmış bir masaüstü yönetim sistemine bırakması için geliştirildi.
8 modül · tek operasyonGerçek HERA V1 arayüzü — bir arayüz yeniden tasarımı olarak değil, ürün kanıtı olarak gösteriliyor.
Proje akışı · kâğıttan çalışan bir ürüne
- Aşama 01KeşifPaydaş ziyareti, dinleme, süreç haritalama
- Aşama 02GereksinimlerTalepler süzülerek yapılandırılmış gereksinimlere dönüştü
- Aşama 03GeliştirmeSekiz operasyonel modül
- Aşama 04TestKurulumdan önce
- Aşama 05KurulumTazelenme Üniversitesi'nde kuruldu
- Aşama 06EğitimSunum, kullanıcı eğitimi ve destek
- Aşama 07Geri bildirimV1 revizyonları ya da V2 backlog'u
Başlangıç noktası
Her şey kâğıtla başladı.
Operasyonel kayıtlar ve süreçler fiziksel dosyalara ve belgelere dağılmıştı. Bilgi biriktikçe erişim, takip ve tutarlı bir operasyonel görünümü korumak giderek zorlaştı.
- Fiziksel dosyalar + belgeler
- Büyüyen kayıtlar
- Zor erişim
- Yapı ihtiyacı
Geliştirmeden önce keşif
Ekranları tasarlamadan önce operasyonu anlamamız gerekiyordu.
- Paydaş ziyareti
- Dinle
- Süreçleri haritala
- Talepleri süz
- Gereksinimleri tanımla
Paydaşlarla yüz yüze görüştük, günlük operasyonların nasıl işlediğini dinledik, taleplerini kendi analizimizle birleştirdik ve altta yatan ihtiyaçları yapılandırılmış gereksinimlere dönüştürdük.
Ne istiyorlar — ve gerçekte neye ihtiyaçları var?
Gereksinimleri yapıya dönüştürmek
Modüller analizin bir sonucuydu — önceden belirlenmiş bir özellik listesi değil.
- M01Öğrenci
- M02Sağlık
- M03Yoklama
- M04Günlük / Arşiv
- M05Gezi
- M06Kulüp
- M07Kütüphane
- M08Bağış
Orijinal sekiz modüllü ana ekran yukarıda gösteriliyor. Buradaki yapı, aynı ekranı tekrarlamadan operasyonel kapsamı haritalar.
Talepten ürün gereksinimine
“Bir kullanıcı talebi ile bir ürün gereksinimi her zaman aynı şey değildir.”
Sağlık kayıtları daha karmaşık bir gereksinim getirdi: yanıtlar tek bir veri tipiyle temsil edilemiyordu. Metriğe bağlı olarak sistemin metin, evet/hayır durumları, sayısal değerler ve açıklayıcı bilgileri desteklemesi gerekiyordu.
Duyusal metrikler
Görme durumu
Farklı metrik türleri farklı yanıt yapıları gerektirdi.
Gereksinimlerden çalışan bir ürüne
Sonuç, bir sunum slaytında kalan bir prototip değildi.
Uygulama öğrenci kayıtlarını, sağlık bilgilerini, yoklamayı, etkinlikleri ve diğer operasyonel süreçleri tek bir yönetim sisteminde topladı.
Orijinal masaüstü üründen, sınıf bazlı gezinme ve operasyonel işlemler.
İkili bir onay kutusu değil, dört durum. Yoklama yalnızca var / yok değildi. İş akışı var, yok, muaf ve raporlu durumlarını temsil ediyordu.
Teslimat da ürün çalışmasının parçasıydı
Ürün, geliştirme bittiğinde bitmedi.
- Test et
- Kur
- Sun
- Eğit
- Destekle
- Geri bildirim topla
Testlerin ardından uygulama Tazelenme Üniversitesi'nde kuruldu. Ürünü sundum, kullanıcıları eğittim, ilk kullanım sürecini destekledim ve geri bildirim topladım. Talepler otomatik olarak uygulanmak yerine değerlendirildi: uygun iyileştirmeler V1 revizyonlarına ya da gelecekteki backlog maddelerine dönüştü.
07 · Sonuç
- 8operasyonel modül
- Gerçek ortamda kurulum
- Kullanıcı eğitimi ve destek
- Geri bildirim → ürün evrimi
HERA bir ders projesi fikrinin ötesine geçip gerçek operasyonlarda kullanıldı ve daha sonra HERA V2'ye yön veren temeli oluşturdu.
Ne öğrendim
İyi ürün çalışması her talebi uygulamak değildir.
Talebin arkasındaki problemi anlamak, onu gereksinimlere dönüştürmek ve hem kullanıcılar hem de ürün için işe yarayan kararlar almaktır.