er is geen officiële methode voor het tekenen van een architectuurkaart. Op een mobiele applicatie, ik meestal proberen te onderscheiden stromen, schermen, en “delen van een scherm” (of “in-page content”), door het gebruik van een andere vorm voor elk van deze, zoals beschreven in de legende hierboven.

het kan ook nuttig zijn om op de kleurcode te spelen. In het bovenstaande voorbeeld gebruikte ik 3 kleuren en ook solide vs.stippellijn om uit te leggen hoe de huidige informatiearchitectuur zou worden bijgewerkt met de UX-vernieuwing van de applicatie waar we aan werkten. (groen: zal blijven zoals het is, Oranje: zal worden bijgewerkt, rood: zal worden verwijderd; solid: zal op dezelfde plaats blijven, gestippeld: zal ergens anders worden verplaatst). Op die manier hadden ingenieurs een duidelijk vogelperspectief op welk deel van de aanvraag aan verandering onderhevig zou zijn.

een andere tip om een begrijpelijke architectuur kaart te bouwen is om duidelijk onderscheid te maken tussen de verschillende delen van de navigatie, zoals hieronder gedaan met aparte gebieden voor elk van hen.

het Hebben van een architectuur kaart zal zeer nuttig zijn voor uw product spec; het zal u toelaten om te markeren welk deel van het product je het over hebt in elk van uw gebruikers verhalen.

welk gereedschap moet u gebruiken om een architectuurkaart te tekenen? Er zijn tonnen van hen beschikbaar die er zijn, mijn favoriete is grillig (want het is visueel aangenaam en zeer eenvoudig, niet volgepropt met zo veel functies), maar ik gebruikte ook Draw.io in het verleden — dat is interessant omdat het is geà ntegreerd met Google Drive, dus als je werkt met Google dia ‘ s en Google Docs het maakt het leuk om te gebruiken. Het is ook geïntegreerd met JIRA en Confluence.

als u meer wilt weten over architectuur kaarten (do ’s en don’ ts, welke tools te gebruiken, enkele voorbeelden, etc.), Toptal heeft een geweldige read bedacht: de uitgebreide gids voor informatiearchitectuur.

Epics en User stories

het afbreken en uitleggen van alle delen van uw product kan zeer snel behoorlijk chaotisch worden. Het schrijven van product specs in de afgelopen 5 jaar, de beste manier die ik heb gevonden om de specs georganiseerd en begrijpelijk te houden is om ze te breken volgens “user stories”.

Wat is een gebruikersverhaal? Volgens Agile modellering, een gebruiker verhaal is ” een zeer high-level definitie van een eis, met net genoeg informatie, zodat de ontwikkelaars een redelijke schatting van de inspanning om het te implementeren kan produceren.”

het idee van gebruikersverhalen is om gebruikers op de eerste plaats te zetten en te vermijden dat uitsluitend obscure & technische woordenschat wordt gebruikt bij het bespreken van functies. Zoals Atlassian het stelt: “na het lezen van een gebruikersverhaal weet het team waarom ze bouwen wat ze bouwen en welke waarde het creëert.”

ze zijn gericht op het bouwen van een beter product waarbij de gebruiker centraal staat in de debatten, in tegenstelling tot de goede oude waterval productontwikkeling.

Hier is hoe een user story geformuleerd moeten worden:

een < gebruiker >, Ik wil < enige doel > zodat < enkele reden >.

hier is bijvoorbeeld hoe we het kunnen formuleren van user stories voor de volgende subdeel van de architectuur van de kaart die ik trok voor een van mijn klanten:

• User Story #1: Als medewerker op de sectie profiel, ik wil mijn profiel bewerken, dus ik kan mijn foto, voornaam en achternaam.
• gebruikersverhaal # 2: Als werknemer in de profielsectie wil ik toegang tot de instellingen, zodat ik mijn wachtwoord en notificatievoorkeuren kan bijwerken.
• User Story # 3: als werknemer in de profielsectie wil ik toegang tot de chat zodat ik feedback kan geven aan de ontwikkelaars van de app

het is aan de productmanager om te beslissen welk niveau van details ze in het gebruikersverhaal willen behandelen. Als we dat zouden willen, zouden we ook een niveau dieper kunnen gaan in het User Story #2, bijvoorbeeld:

• User Story #2.a: Als werknemer in de Instellingen wil ik toegang krijgen tot de sectie “Wachtwoord bewerken”, zodat ik mijn wachtwoord
• User Story #2 kan bijwerken.b: als een werknemer in de Instellingen, wil ik toegang krijgen tot de meldingen voorkeuren, zodat ik kan bijwerken met welke frequentie ik elk type meldingen

ontvang, maar zoals je ziet, is dit enigszins voor de hand liggend en overbodig. Persoonlijk heb ik ervoor gekozen om deze scenarii te behandelen in de “acceptatiecriteria” (zie volgende sectie) van de verhalen in kwestie.

om gebruikersverhalen te organiseren, gebruiken we vaak “epics”. In agile termen, “epics” zijn grote hoeveelheden werk dat kan worden onderverdeeld in kleinere gebruiker verhalen. Persoonlijk gebruik ik epics om verhalen te groeperen die deel uitmaken van hetzelfde thema of gebied in het product. Bijvoorbeeld, Ik heb ervoor gekozen om de bovenstaande verhalen te groeperen als onderdeel van het” profiel ” epos. Sommige mensen kiezen ervoor om EPIC ‘ s op dezelfde manier te formuleren als gebruikersverhalen, met een eenvoudigere structuur (bijv. “As a user, I want to access my profile”)

Acceptance criteria

om er zeker van te zijn dat er voldoende details aan een gebruikersverhaal worden toegevoegd, gebruiken we “acceptance criteria” (soms ook wel “conditions of satisfaction”genoemd).

volgens LeadingAgile.com ” acceptatiecriteria “zijn” de voorwaarden waaraan een softwareproduct moet voldoen om te worden geaccepteerd door een gebruiker, klant, of in het geval van functionaliteit op systeemniveau, het consumerende systeem.”

in de acceptatiecriteria zou je alle functionele specificiteiten moeten vermelden die niet duidelijk zijn beschreven in het gebruikersverhaal. Bijvoorbeeld:

User Story

als werknemer in de profielsectie wil ik mijn profiel bewerken zodat ik mijn foto, Voornaam en achternaam Kan bijwerken.

acceptatiecriteria

• gegeven dat ik op het scherm Profiel Bewerken ben wanneer ik op het pictogram voornaam bewerken klik dan moet het overschakelen naar de modus Bewerken, zich concentreren op de invoer en het toetsenbord openen (hetzelfde voor achternaam)
• gegeven dat ik op het scherm Profiel Bewerken ben wanneer ik op het pictogram Foto Bewerken klik dan moet het me vragen om te kiezen tussen camera en bibliotheek
• gegeven dat ik mijn voornaam aan het bewerken ben wanneer ik op “Opslaan” klik dan moet het me omleiden naar het lezen Mode en ik zou een success Notification moeten zien

etc…

zie de acceptatiecriteria als een checklist die moet worden ingevuld voor het product te worden verzonden. Het gegeven/wanneer / dan formaat hierboven gebruikt is een goede manier om u te helpen bij het formuleren van uw acceptatiecriteria, maar in sommige gevallen kan het uitdagend zijn om te gebruiken.

ontwerp, inhoud en vertalingen

met up-to-date ontwerpen in uw productspecificaties

tot nu toe heb ik niet vermeld welke tool Ik gebruik om specificaties te schrijven. In het verleden ben ik overgestapt tussen Google Docs, Google Slides en Notion. Ik heb echt genoten van het gebruik van Notion voor alle coole integraties die het biedt (vooral die met Invision en Figma). Maar ik heb nu volledig overgestapt naar Google Docs: ik heb liever meer vrijheid op de manier waarop ik mijn product specificaties formatteren. Het is ook handiger om Google-producten te gebruiken wanneer u met externe partners of klanten werkt.

om ervoor te zorgen dat de visuele identiteit van uw product accuraat tot leven wordt gebracht door het ontwikkelteam, is het belangrijk om hen toegang te geven tot de meest up-to-date schermen die door uw ontwerper(s) worden geleverd. Maar omdat er geen echte integratie is tussen Google Docs en designtools zoals Figma, Invision of Zeplin, exporteerde ik schermen en kopieerde/plakte ze in mijn productspecificaties.

Dit zou al snel een probleem worden: ontwerpers itereren dagelijks op hun schermen, en zelfs als alles op een scherm is overeengekomen, kan het een paar weken later veranderen omdat een specifieke component wordt bijgewerkt in de design library. Dit zou ervoor zorgen dat mijn SPECIFICATIES meestal verouderd zijn.

daarom gebruik ik vandaag alleen de naam van de schermen. Bijvoorbeeld, als een gebruiker verhaal over profile edition is over 2 schermen die zijn ontworpen op Figma, Ik zal alleen schrijven “Figma screen name: edit-profile-1 and edit-profile-2”.

Dit is natuurlijk niet ideaal en beperkt ontwikkelaars of iemand anders die mijn SPECIFICATIES leest om te schakelen tussen verschillende tools.

maar dit laat zien dat er vandaag iets inefficiënt is in de manier waarop we productspecificaties schrijven. Het gebruik van verschillende producten roept vragen op van integratie en synchronisatie. Hoe zorg je ervoor dat alle informatie die nodig is om een product te bouwen op één plek zichtbaar is, zonder verouderd te zijn? (Eigenlijk geldt dit niet alleen voor ontwerpen, maar ook voor Architectuurkaarten en inhoud).

→ Als u ook dit probleem ondervindt en een oplossing hebt gevonden, ben ik geïnteresseerd om uw feedback te krijgen!

het geven van gemakkelijke toegang tot inhoud en vertalingen om typefouten te vermijden

wanneer u schermen ontwerpt met een grote hoeveelheid inhoud, is het leuk om ontwikkelaars de mogelijkheid te geven om het eenvoudig te kopiëren / plakken in plaats van het zelf opnieuw te typen. Anders, je zou kunnen eindigen met (1) veel typefouten en (2) boos ontwikkelaars. Er zijn verschillende manieren waarop u hen toegang tot de inhoud kunt geven:

• door hen toegang te geven tot de bronbestanden van het ontwerpwerk op Sketch, Figma of Zeplin bijvoorbeeld.
• door de inhoud direct in de spec te kopiëren/plakken (het kan het een beetje rommelig maken).

als uw product in meerdere talen bestaat, geef dan ook toegang tot elke vertaling. U kunt bijvoorbeeld een array gebruiken om de vertaling van uw oorspronkelijke inhoud in elke taal weer te geven. Het volgende niveau van vertaalbeheer is om een lokalisatiehulpmiddel (zoals zin) te gebruiken en slechts de “vertaalsleutels” in uw productspecie toe te voegen. Maar nogmaals, dit impliceert nog een heen-en-weer tussen uw product specs en een ander hulpmiddel.