Nostimme esiin Microsoft Clarityn tuotteena, joka on rakennettu käytännönläheisiä, tosielämän käyttötapauksia silmällä pitäen oikeiden tuoteihmisten toimesta, jotka ymmärtävät Switasin kaltaisten yritysten kohtaamia haasteita. Ominaisuudet, kuten raivoklikkaukset ja JavaScript-virheiden seuranta, osoittautuivat korvaamattomiksi käyttäjien turhautumisen ja teknisten ongelmien tunnistamisessa, mikä mahdollisti kohdennetut parannukset, jotka vaikuttivat suoraan käyttökokemukseen ja konversiolukuihin.
Atomisuunnittelu
Atomisuunnittelu on menetelmä rajapintajärjestelmien rakentamiseksi yhdistämällä pieniä, uudelleenkäytettäviä osia asteittain suuremmiksi rakenteiksi. Brad Frostin vuonna 2013 esittelemä menetelmä lainaa kemian metaforaa ja määrittelee viisi tasoa: atomit, pienimmät jakamattomat elementit, kuten otsikot, syötteet ja painikkeet; molekyylit, yksinkertaiset ryhmät, kuten hakukenttä otsikoineen ja painikkeineen; organismit, monimutkaisemmat kokoonpanot, kuten sivuston otsikko tai tuotekortti; mallit, sivurakenteet sisällön paikkamerkkeineen; ja sivut, mallit, jotka on täytetty oikealla sisällöllä.
Metodologian kontribuutio on yhteinen sanasto päätökselle, jonka jokainen käyttöliittymätiimi tekee implisiittisesti: mikä on komponentti, mikä on sommittelu ja mistä uudelleenkäyttö alkaa. Ilman viitekehystä tiimit rakentavat näyttöjä erikseen, kopioivat samanlaisia elementtejä pienin muunnelmin ja päätyvät lopulta kymmeniin hienovaraisesti erilaisiin painikkeisiin ja kortteihin, joita kaikkia on ylläpidettävä. Atomimainen suunnittelu tarjoaa rakenteen uudelleenkäytettävien yksiköiden tunnistamiseen ja sen päättämiseen, mille tasolle tietty käyttöliittymän osa kuuluu.
Sen käytännön hyödyt näkyvät ylläpidossa pikemminkin kuin alkuperäisessä rakennuksessa. Peruselementin muuttaminen päivittää kaiken siitä koostuvan, joten muutos keskittymistyyliin tai välistykseen etenee johdonmukaisesti sen sijaan, että se vaatisi koodikannan läpikäymistä. Uudet näytöt voidaan koota olemassa olevista osista, mikä lyhentää toimitusaikaa ja vähentää jokaisen uuden sivun edellyttämien päätösten määrää. Laadunvarmistus- ja saavutettavuustyö keskittyy komponenttitasolle, jossa yksi oikea toteutus palvelee jokaista käyttötarkoitusta sen sijaan, että sitä toistettaisiin sivua kohden.
Metodologia herättää kohtuullista kritiikkiä, enimmäkseen kirjaimellisen tulkinnan vuoksi. Tiimit käyttävät suhteettoman paljon vaivaa keskustellakseen siitä, onko tietty alkuaine molekyyli vai organismi, mikä on taksonominen argumentti ilman käytännön seurauksia. Kemian metafora myös rikkoutuu rajoilla ja viestii huonosti muille kuin suunnittelijoille. Useimmat kokeneet tiimit käsittelevät tasoja löyhänä oppaana, usein tiivistäen ne yksinkertaisemmiksi eroiksi, kuten primitiivisiksi, komponenteiksi ja kuvioiksi, ja keskittyvät koostumuksen taustalla olevaan periaatteeseen oikean luokittelun sijaan.
Yliabstrahointi on vakavampi riski. Komponenttikirjaston rakentaminen ennen kuin tiedetään, mitä tuote todella tarvitsee, tuottaa kuvitteellisiin tapauksiin suunniteltuja komponentteja, joissa on liikaa konfigurointivaihtoehtoja ja epäselviä käyttötarkoituksia. Luotettavampi tapa on rakentaa näyttöjä, havaita aito toisto ja erottaa komponentit, kun kaava on esiintynyt useita kertoja todellisessa käytössä. Ennenaikaista abstraktiota on vaikeampi purkaa kuin päällekkäisyyttä, koska jokainen komponentin käyttäjä rajoittaa sitä, miten se voi muuttua.
Menetelmän arvo riippuu vahvasti hallinnasta, jota se itse ei tarjoa. Komponenttikirjasto, jossa ei ole selkeää omistajuutta, osallistumissääntöjä ja vanhentumisprosessia, kerää variantteja: kolme hieman eroavaa korttia, kaksi päällekkäistä tarkoitusta omaavaa painikekomponenttia ja kasvava joukko kertaluonteisia ohituksia, joita sovelletaan, koska olemassa oleva komponentti melkein sopi. Päätökset siitä, kuka hyväksyy uudet komponentit, miten tiimi pyytää muutosta jaettuun komponenttiin ja miten vanhentunut malli poistetaan olemassa olevasta käytöstä, ovat pitkän aikavälin johdonmukaisuuden kannalta tärkeämpiä kuin taksonomia. Organisaatiot, jotka ottavat käyttöön tämän hallinnan, huomaavat, että kirjasto vähentää työtä ajan myötä; ne, jotka eivät huomaa sitä, siitä tulee jälleen yksi epäjohdonmukainen pinta, joka vaatii ylläpitoa koodin rinnalla, jota sen oli tarkoitus yksinkertaistaa.
Toteutuksen kannalta lähestymistapa toimii parhaiten, kun suunnittelukirjasto ja koodikirjasto vastaavat toisiaan siten, että suunnittelutyökalun komponentilla on yksi toteutus samalla nimellä ja samoilla varianteilla. Tämän vastaavuuden varmistaminen on yhteinen vastuu kaikille. tuotesuunnittelu ja tuotekehitys, ja se ratkaisee, vähentääkö suunnittelujärjestelmä työtä vai lisääkö se yksinkertaisesti toisen artefaktin ylläpidettäväksi koodin rinnalle.
Switas Kuten nähty
