Et digitalt hjem.
Ét sammenhængende univers.
Seks faglige områder. Seksten modulidentiteter. Ét sted at forstå formålet, oplevelsen, reglerne og kvaliteten bag BroLykkeHus.
Projekt & retning
BroLykkeHus er en modulær familie af hverdagsværktøjer, bygget med en fælles identitet og sammenhængende brugeroplevelse.
Hverdagen skal være lettere at overskue
Samle praktiske informationer, planer og opgaver, så man ikke behøver holde det hele i hovedet. Dette er en redaktionel opsummering af projektets mål – ikke et godkendt kommercielt værdiløfte.
Værdi før kompleksitet
Mulig gevinst er mindre dobbeltregistrering, bedre overblik og færre tabte hverdagsopgaver. Kundemålgruppe, prisstrategi, dokumenterede effektmål og økonomisk business case kræver særskilt afklaring.
Hele produktfamilien · 16 godkendte signaturfarver
Målgrupper og brugskontekst
En husstand med forskellige medlemmer og gæster, forskellige præferencer og en hverdag på tværs af mobil og computer. Mere detaljerede personaer og interviews er endnu ikke besluttet.
Produktprincipper
- Fælles stamdata, når det giver mening
- Moduler kan have egen funktion og visuel accent
- Brugeren styrer data og godkender ændringer
- Trinvise udgivelser med sporbar status
Roadmap og afgrænsning
Aktive fokusområder: Basis og Mad, inklusive datadeling, hylder, opskrifter og indkøb. De øvrige fjorten moduler er ikke automatisk prioriterede udviklingsprojekter.
Fuld faglig disposition · 6 kapitler
01 · Produktidentitet
Vision og mission; elevator pitch; produktprincipper; værdiløfte.
02 · Behov og mulighed
Hverdagsproblemer; målgrupper; interessenter; værdiskabelse; differentiering.
03 · Produktfamilien
Alle 16 modulidentiteter og afhængigheder; aktiv app eller koncept.
04 · Strategi og roadmap
MVP; afgrænsning; prioritering; milepæle; strategiske valg.
05 · Business case
Gevinster, omkostninger, prismodel og bæredygtighed – endnu ikke besluttet.
06 · Måling og governance
Effektmål; KPI’er; risici; beslutningslog; ejerskab.
Dispositionen angiver den forventede dækning; punkter uden kildeverificeret indhold er endnu ikke godkendte krav.
Fælles designsystem
Én genkendelig komponentfamilie – tilpasset hver apps godkendte farveidentitet.
Ikoner hentes fra eksisterende appfiler
Ingen genererede erstatningsikoner. De resterende 14 ikonoriginaler indsættes først, når de officielle filer er tilgængelige i projektet.
Seks fælles nordiske grundfarver
Appfarver og semantik
Modulaccent: præcis HEX-værdi fra farvestandarden. Handlingsfarver: kontrastjusterede, hvor knaptekst kræver det. Status: succes, advarsel og fejl har samme betydning i alle moduler – og må ikke forveksles med modulfarven.
Interaktive komponenteksempler · test lokale tilstande
Menukort og bokstitler
Boks-kicker er lille, versal og uden farvet flade. Ens former og afstande på tværs af apps.
Handlinger og ikoner
Primær handling bruger appens farve; ikonknapper er hvide med tynd grå ramme.
Filtre og valg
Vælgte og fravalgte tilstande skal være entydige i både kort- og listevisning.
Liste, kort og status
Listevisning er kompakt og uden billeder. I kortvisning må eksisterende varebilleder åbnes i større format.
Interaktion og tilgængelighed
- Tydelig tastaturfokus og labels på ikonhandlinger
- Mobilvenlige trykflader og indre scrolling i modaler
- Fokus, valgt/fravalgt, fejl, loading og tom tilstand
- Ingen afklippede kontroller eller dekorative utydelige nåleikoner
Visuel accept
Godkendte designs skal afprøves på faktiske DEV-skærme i telefon- og desktopbredde. En skitse eller dette komponenteksempel er ikke bevis for implementering i appen.
Fuld faglig disposition · 7 kapitler
01 · Brand og aktiver
Logo; 16 officielle appidentiteter; godkendte ikonoriginaler; eksportformater.
02 · Farver og tokens
6 grundfarver; 16 signaturfarver; semantiske farver; kontrastkrav; spacing og radius.
03 · Typografi og grid
Typografisk hierarki; skala; læsbarhed; kolonner; responsive breakpoints.
04 · Komponenter
Knapper; ikonhandlinger; kort; bokstitler; navigation; felter; lister; badges; dialoger; filtras.
05 · Interaktionsmønstre
Fokus; valgt/fravalgt; fejl; loading; tom; disabled; bekræftelse; scroll i modal.
06 · Billeder og tilgængelighed
Egte appskærme; ikoner; billedbeskæring; tastatur; kontrast; touch; skærmlæsere.
07 · Governance og kvalitet
Do/Don't med faktiske skærme; ejerskab; designrevision; visuel DEV-accept.
Dispositionen angiver den forventede dækning; punkter uden kildeverificeret indhold er endnu ikke godkendte krav.
Basis · husstandens fælles fundament
Medlemmer, gæster, husstand og rum kan få én fælles betydning på tværs af moduler.
En fælles kerne – uden at skabe unødige rettigheder
Gæster er kontakter til præferencer og sammenhænge, ikke brugerkonti med selvstændig adgang. Det er en godkendt forretningsregel, ikke en påstand om at funktionen er live.
Husstand og medlemmer
Basis forsyner øvrige apps med fælles stamdata. Regler for ID, rettigheder og synk skal håndteres centralt frem for at blive opfundet forskelligt i hvert modul.
Gæster og rum
Godkendt behov Gæster registreres uden rettigheder; fremtidige apps kan knytte præferencer til dem. Husstandens rum skal kunne genbruges som lokationer.
Forretningsregler og eksempler
BA-01: Husstandens stamdata ejes ét sted. BA-02: Gæster må ikke få adgang, blot fordi de står på listen. BA-03: Rum skal kunne genbruges uden at oprette nye rumdefinitioner per app. Accept kræver både data- og brugertest.
Ikke-funktionelle krav og åbne beslutninger
Fuld faglig disposition · 6 kapitler
01 · Aktører og adgang
Administrator; medlemmer; gæster uden rettigheder; tilknytning.
02 · Stamdata
Husstand; medlemmer; identitet; dataejerskab og konsekvens af ændringer.
03 · Husstandens rum
Lokaliteter; opret/ret; genbrug af samme referencer i andre moduler.
04 · Brugerrejser
Opret husstand; rediger medlem; opret gæst; vedligehold rum.
05 · Regler og undtagelser
Entydige ID’er; validering; fjernelse; adgang; fejlsituationer.
06 · Accept og kvalitet
Brugerforståelse; stabil datadeling; korrekt mobiloplevelse; testspor.
Dispositionen angiver den forventede dækning; punkter uden kildeverificeret indhold er endnu ikke godkendte krav.
Mad & husholdning
Fra indkøb til registrering, overblik, opskrifter, madplan og forbrug.
Én sammenhængende hverdag
Varer kan identificeres, placeres og genbruges i opskrifter og indkøb, uden at alle brugerhandlinger bliver til nye fysiske lagerposter.
Varekatalog
Genbrug vareidentitet, navn og stregkode. Ved mulig dublet skal brugeren kunne sammenligne før gem.
På hylderne
Fysisk beholdning med lokation, antal, særskilte udløbsdatoer og flyt/forbrug. Antal nul vises kun i kataloget.
Opret vare
Manuel indtastning, indtaling, scanning og stregkodeindtastning. Formularen skal først åbne ved valgt handling.
Indkøb og kvitteringer
Indkøbslister og Indkøbt. Kvittering identificerer forslag, som gennemgås, før de sættes på plads.
Opskrifter
Opskriftskort med titel, fremgang, billede og mængder. Ingredienser vælges fra katalogvarer uden ny lagerpost.
Madplan og præferencer
Måltider og familievariationer skal fungere med medlemmer og gæster. Automatisk logik er ikke fuldt besluttet.
Vigtige regler for oprettelse, lister og billeder
- Nye registreringer vises i Registreringer med Ny!-markering.
- Listevisning har ingen billeder. Kortvisning har billeder, der kan åbnes stort.
- Lokationsvalg virker ens i begge visninger og understøtter flere valgte lokationer.
- Stemmeoptagelse stopper ved sideforladelse. Scanning har hjælpetekst, rød sigtelinje og mulighed for blitz hvor teknisk muligt.
Forretningsregler for mængder, udløb og forbrug
Fremtidige funktioner
Fuld faglig disposition · 9 kapitler
01 · Varekatalog
Katalogidentitet; GTIN/stregkode; producent; dubletmatch; billede.
02 · På hylderne
Mængde; udløbspartier; lokationer; flytning; flere filtre; nulbeholdning.
03 · Registrering
Tast selv; indtaling; scanning med sigtelinje/blitz; validering; Ny!-markering.
04 · Indkøb
Indkøbslister; Indkøbt; kvittering; billedoptagelse; brugerkontrol; Sæt på plads.
05 · Opskrifter
Vælg katalogvarer; måleenheder; billede; fremgangsmåde; opskriftskort.
06 · Madplan
Planlægning; måltider; antal personer; kobling til opskrifter; brugerhensyn.
07 · Forbrug
Bekræft mængder og specifikke udløbspartier; ingen skjult lagerændring.
08 · Præferencer
Husstandsmedlemmer og gæster; individuel variation; hensyn; åbent beslutningsrum.
09 · Fremtid
AI-import; automatisering; andre ikke godkendte muligheder.
Dispositionen angiver den forventede dækning; punkter uden kildeverificeret indhold er endnu ikke godkendte krav.
Data, login & synkronisering
Gennemsigtig håndtering af personlige data, pålidelige forbindelser og tydelige valg ved konflikter.
Dataejerskab
Husstanden skal have overblik over sine egne data. Basis er fælles kildemodul til husstandsdata; Mad har egne domænedata til varekatalog og beholdning.
Kontrollér faktiske kontrakterLogin og kontotilknytning
Microsoft/OneDrive anvendes til forbindelse og lagring. Brugerfladen skal gøre det forståeligt, hvilken konto der er tilknyttet, og om forbindelsen virker.
Synkronisering
Brugeren skal kunne skelne lokale data fra OneDrive-data og forstå retningen ved overførsel. Forskelle og konflikter skal vises, før irreversible overskrivninger gennemføres.
Backup og gendannelse
Backup, genopretning og migration skal kunne forklares i brugertermer. Dokumenteret backupfil er ikke det samme som testet gendannelse.
Grundlæggende datavej
Fejl og undtagelser, der skal beskrives
Fuld faglig disposition · 6 kapitler
01 · Informationsmodel
Stamdata vs moduldata; relationer; identiteter; datakvalitet.
02 · Kontotilknytning
Microsoft-login; adgang; hvem er aktiv; afmeldelse; fejltilstande.
03 · Synkronisering
Lokalt/OneDrive; retning; forandringer; sammenligning; konflikter; offline.
04 · Datasikkerhed
Adgangsrettigheder; privatliv; opbevaring; dataminimering.
05 · Backup og restore
Frekvens; historik; gendannelsesprocedurer; sikker verificering.
06 · Integration og migration
Kontrakter; versioner; kompatibilitet; dataflytning; afviste operationer.
Dispositionen angiver den forventede dækning; punkter uden kildeverificeret indhold er endnu ikke godkendte krav.
Kvalitet, test & udgivelse
Godkendt design, fungerende kode, beståede tests og frigivet produktion er fire forskellige ting.
Færdigt er dokumenteret og afprøvet
- Krav og acceptkriterier er entydige
- Relevante tests er tilføjet og bestået
- Faktisk DEV-skærm er visuelt gennemgået
- Dokumentation er opdateret og kildehenvist
- Release kræver særskilt gate
Basis og Mad har egne releaseforløb
Hver app kræver relevant CI, version, korrekt commit og tydelig godkendelse. En grøn deploy betyder ikke automatisk grøn regression eller manuel godkendelse.
Testspor og kvalitetsstatus
| Kontrol | Forventet dokumentation | Hvad der ikke må antages |
|---|---|---|
| GitHub-PR | Branch, SHA, review og merge | At ændringen er deployeret |
| Automatisk regression | Run-ID og resultat pr. app | At designet er manuelt godkendt |
| DEV | Faktisk URL, version og skærmbilleder | At PROD er opdateret |
| PROD | Releasekørsel, appversion, dato | At OneDrive-data er indholdskontrolleret |
Fejl, rollback og ændringshistorik
Fuld faglig disposition · 7 kapitler
01 · Kvalitetsstrategi
Kvalitetsmål; risiko; prioritet; kvalitetsansvar; testfilosofi.
02 · Testtyper
Enhedstest; integration; regression; browser; mobil; visuel accept.
03 · Krav- og testspor
Krav-ID; testcase; automatiseringsstatus; resultat; kendte huller.
04 · Miljøer og data
DEV; PROD; testdata; isolering; releasegrænser; ansvar.
05 · Fejl og rettelser
Severity; reproduktion; retest; regression; lukningskriterier.
06 · Releaseproces
Branch; PR; SHA; CI; appvis version; gate; godkendelse; rollback.
07 · Opfølgning
Driftsfejl; releasejournal; forbedringslog; audit.
Dispositionen angiver den forventede dækning; punkter uden kildeverificeret indhold er endnu ikke godkendte krav.