Design-velka

Suunnitteluvelka on sellaisten suunnitteluratkaisujen kertyneitä kustannuksia, jotka olivat aikoinaan tarkoituksenmukaisia ​​ja nyt vaikeuttavat tuotteen käyttöä ja muokkaamista. Se on suunnittelussa teknisen velan vastine, ja se rakentuu samalla tavalla: yksittäin järkeviä oikopolkuja otetaan määräaikapaineen alla, eikä mikään niistä vaikuta merkittävältä, ja ne kasautuvat epäjohdonmukaiseksi, hämmentäväksi ja kalliiksi muokata käyttöliittymäksi.

Se kertyy tunnistettavien mekanismien kautta. Komponenttia muokataan hieman yhtä näyttöä varten sen sijaan, että kaavaa päivitettäisiin, ja variantti säilyy. Ominaisuus lisätään miettimättä, miten se sopii olemassa olevaan rakenteeseen. Sivun suunnittelee joku, joka ei ole perehtynyt vakiintuneisiin kaavoihin. Hankittu tuote integroidaan ilman yhdenmukaistamista. Uudelleenbrändäys tehdään näkyvimmille alueille, mutta ei muille. Jokainen muutos jättää tuotteen hieman epäjohdonmukaisemmaksi kuin ennen.

Kustannukset ovat todellisia, mutta hajanaisia, minkä vuoksi ongelmaa siedetään vuosia. Käyttäjät kohtaavat epäjohdonmukaisia ​​toimintamalleja ja heidän on opittava uudelleen käyttäytymistä, jonka tulisi siirtyä, mikä lisää kognitiivista kuormitusta ja virhemääriä. Suunnittelijat käyttävät aikaa päättääkseen, mitä useista olemassa olevista hoitomuodoista noudattaa. Kehittäjät toteuttavat muunnelmia komponenttien uudelleenkäytön sijaan. Jokaisen uuden ominaisuuden on otettava huomioon kertynyt epäjohdonmukaisuus, joten muutoksen kustannukset nousevat jatkuvasti.

Tekniseen velkaan verrattuna sen erottava ominaisuus on näkyvyys. Tekninen velka on asiakkaille näkymätöntä, kunnes se tuottaa vian; suunnitteluvelka taas näkyy jokaisella näytöllä. Asiakkailla ei ehkä ole sanastoa sille, mutta he kokevat tuotteen, joka tuntuu viimeistelemättömältä ja epäjohdonmukaiselta, ja tämä käsitys vaikuttaa luottamukseen tavoilla, joita on vaikea yhdistää mihinkään tiettyyn elementtiin.

Osa suunnitteluvelasta on tarkoituksellista ja puolustettavissa. Karkean rajapinnan toimittaminen kysynnän validoimiseksi ennen investointeja hienosäätöön on järkevä kauppa, kunhan se kirjataan ja velvoite tunnustetaan. Vahingollista vaihtelua ei tunnisteta: epäjohdonmukaisuutta, joka syntyy kenenkään huomaamatta, kasaantuu vuosien ja tiimien aikana ilman kirjaa siitä, mistä poikettiin tai miksi.

Korjaava toimenpide vaatii ensin inventaarion, ennen kuin se vaatii työtä. Tuotteen auditointi sen luetteloimiseksi, missä kaavat poikkeavat toisistaan, kuinka monta varianttia kustakin komponentista on olemassa ja mitkä epäjohdonmukaisuudet vaikuttavat eniten käytettyihin prosesseihin, muuttaa yleisen epäjärjestyksen tunteen priorisoiduksi listaksi. Useimmat tuotteet sisältävät paljon enemmän variantteja kuin kukaan odottaa, ja auditointi itsessään tarjoaa usein perusteen investoinneille.

Priorisoinnin tulisi seurata käyttöä eikä loukkausta. Merkittäviä epäjohdonmukaisuuksia ovat ne, joita useimmat ihmiset käyttävät, ja häiritsevä muutos harvoin vieraillulla hallintapaneelilla maksaa paljon vähemmän kuin hienovarainen muutos kassalla. Korjaavien toimenpiteiden järjestäminen liikenteen ja kaupallisen arvon mukaan pitää työn yhteydessä tuloksiin ja estää yleisen kaavan, jossa yhdistämisprojekti käsittelee ne epäjohdonmukaisuudet, jotka tarkistava suunnittelija koki ärsyttävimmiksi.

Ennaltaehkäisy on huomattavasti halvempaa kuin takaisinmaksu ja on pitkälti järjestelmäkysymys. Hyvin hallittu suunnittelujärjestelmä, jossa on selkeät osallistumis- ja vanhentumisprosessit, tekee yhdenmukaisuudesta oletusarvon ja poikkeamista harkittua. Suunnittelukatselmointi vakiintuneena käytäntönä havaitsee poikkeamat ennen niiden lähettämistä. Ja mallipäivitysten käsitteleminen osana ominaisuustyötä sen sijaan, että ne olisivat erillisiä parannusprojekteja, joita ei koskaan aikatauluteta, pysäyttää kasautumisen jo lähteellä.

Koska korjaava investointi kilpailee ominaisuuksien toimittamisen kanssa samasta kapasiteetista, se tarvitsee saman perustelun kuin mikä tahansa muu investointi. Käytännössä auditointi ja korjaussuunnitelma laaditaan UX-tarkastus työssä systeeminen ehkäisy käsitellään suunnittelujärjestelmässä, joka on luotu tuotesuunnittelu, ja kuvioiden yhdistämisen toteutus on tyypillisesti ajoitettava teknisen velkatyön rinnalle tuotekehityskoska ne kaksi vaikuttavat usein samoihin komponentteihin.