diff --git a/astro-site/().md b/astro-site/().md new file mode 100644 index 00000000..e69de29b diff --git a/astro-site/.astro/content-assets.mjs b/astro-site/.astro/content-assets.mjs index e82130fb..2a1a0ea1 100644 --- a/astro-site/.astro/content-assets.mjs +++ b/astro-site/.astro/content-assets.mjs @@ -15,6 +15,8 @@ import __ASTRO_IMAGE_IMPORT_A1tQz from "./dross.png?astroContentImageFlag=&impor import __ASTRO_IMAGE_IMPORT_ZGbMWl from "./figjam.png?astroContentImageFlag=&importer=src%2Fcontent%2Fwork%2Fjiva-lite%2Findex.md"; import __ASTRO_IMAGE_IMPORT_pTGt3 from "./git25.png?astroContentImageFlag=&importer=src%2Fcontent%2Fwriting%2Fvibe-coding%2Findex.md"; import __ASTRO_IMAGE_IMPORT_Z2h82xm from "./gorontalo.jpeg?astroContentImageFlag=&importer=src%2Fcontent%2Fwork%2Fjiva-lite%2Findex.md"; +import __ASTRO_IMAGE_IMPORT_2dP0WI from "./grindsize.png?astroContentImageFlag=&importer=src%2Fcontent%2Fwriting%2Fhow-i-build-with-ai%2Findex.md"; +import __ASTRO_IMAGE_IMPORT_Z2wl5XB from "./how-i-build.png?astroContentImageFlag=&importer=src%2Fcontent%2Fwriting%2Fhow-i-build-with-ai%2Findex.md"; import __ASTRO_IMAGE_IMPORT_LumN8 from "./jivalite-ground.png?astroContentImageFlag=&importer=src%2Fcontent%2Fwork%2Fjiva-lite%2Findex.md"; import __ASTRO_IMAGE_IMPORT_Z1SL4zh from "./jivalite.jpg?astroContentImageFlag=&importer=src%2Fcontent%2Fwork%2Fjiva-lite%2Findex.md"; import __ASTRO_IMAGE_IMPORT_1CGnrC from "./jivalitev1.png?astroContentImageFlag=&importer=src%2Fcontent%2Fwork%2Fjiva-lite%2Findex.md"; @@ -40,6 +42,7 @@ import __ASTRO_IMAGE_IMPORT_ogiEj from "./squiggle-labels-outline.jpg?astroConte import __ASTRO_IMAGE_IMPORT_Z1CNLo3 from "./thai-header.jpeg?astroContentImageFlag=&importer=src%2Fcontent%2Fwork%2Finternational%2Findex.md"; import __ASTRO_IMAGE_IMPORT_jN1fQ from "./thai-research.jpeg?astroContentImageFlag=&importer=src%2Fcontent%2Fwork%2Finternational%2Findex.md"; import __ASTRO_IMAGE_IMPORT_lu7jP from "./user-behaviour.png?astroContentImageFlag=&importer=src%2Fcontent%2Fwork%2Finternational%2Findex.md"; +import __ASTRO_IMAGE_IMPORT_ZVag2n from "./variant.png?astroContentImageFlag=&importer=src%2Fcontent%2Fwriting%2Fhow-i-build-with-ai%2Findex.md"; import __ASTRO_IMAGE_IMPORT_20sBpP from "./viet.png?astroContentImageFlag=&importer=src%2Fcontent%2Fwork%2Finternational%2Findex.md"; import __ASTRO_IMAGE_IMPORT_22txty from "./whiteboard.JPG?astroContentImageFlag=&importer=src%2Fcontent%2Fwriting%2Fhiring-2%2Findex.md"; import __ASTRO_IMAGE_IMPORT_Z1gJ4cL from "./zoom.png?astroContentImageFlag=&importer=src%2Fcontent%2Fwriting%2Frituals%2Findex.md"; @@ -69,5 +72,5 @@ import __ASTRO_IMAGE_IMPORT_Z4LDMj from "spots.png?astroContentImageFlag=&import import __ASTRO_IMAGE_IMPORT_Z2wmyeK from "styleguide.webp?astroContentImageFlag=&importer=src%2Fcontent%2Fwork%2Fakar-design-system%2Findex.md"; import __ASTRO_IMAGE_IMPORT_CljXE from "type.webp?astroContentImageFlag=&importer=src%2Fcontent%2Fwork%2Fakar-design-system%2Findex.md"; import __ASTRO_IMAGE_IMPORT_ZSEHB from "v1-prototype.png?astroContentImageFlag=&importer=src%2Fcontent%2Fwriting%2Fvibe-coding%2Findex.md"; -export default new Map([["./4IiQQOEdmqPcCsjTqlta-1.png?astroContentImageFlag=&importer=src%2Fcontent%2Fwriting%2Fdesign-in-tech-2024%2Findex.md", __ASTRO_IMAGE_IMPORT_Z1AyhWV], ["./QRIS-gobiz.webp?astroContentImageFlag=&importer=src%2Fcontent%2Fwork%2Fgojek%2Findex.md", __ASTRO_IMAGE_IMPORT_JitFy], ["./akar.webp?astroContentImageFlag=&importer=src%2Fcontent%2Fwork%2Fakar-design-system%2Findex.md", __ASTRO_IMAGE_IMPORT_Z2g9ce], ["./asana.png?astroContentImageFlag=&importer=src%2Fcontent%2Fwork%2Finternational%2Findex.md", __ASTRO_IMAGE_IMPORT_Zn0Wwm], ["./chatgpt-final.png?astroContentImageFlag=&importer=src%2Fcontent%2Fwriting%2Fvibe-coding%2Findex.md", __ASTRO_IMAGE_IMPORT_Z1Rx8Co], ["./chatgpt-v1.png?astroContentImageFlag=&importer=src%2Fcontent%2Fwriting%2Fvibe-coding%2Findex.md", __ASTRO_IMAGE_IMPORT_Zc35bV], ["./claude-v1.png?astroContentImageFlag=&importer=src%2Fcontent%2Fwriting%2Fvibe-coding%2Findex.md", __ASTRO_IMAGE_IMPORT_Z1c50EV], ["./competitors.png?astroContentImageFlag=&importer=src%2Fcontent%2Fwork%2Finternational%2Findex.md", __ASTRO_IMAGE_IMPORT_RDvgL], ["./copy-doc.png?astroContentImageFlag=&importer=src%2Fcontent%2Fwork%2Finternational%2Findex.md", __ASTRO_IMAGE_IMPORT_Z2bA4yw], ["./copy-sheets.png?astroContentImageFlag=&importer=src%2Fcontent%2Fwork%2Finternational%2Findex.md", __ASTRO_IMAGE_IMPORT_ZTIp58], ["./design-keliling.jpg?astroContentImageFlag=&importer=src%2Fcontent%2Fwriting%2Fhiring%2Findex.md", __ASTRO_IMAGE_IMPORT_2gJYQo], ["./dogfooding.png?astroContentImageFlag=&importer=src%2Fcontent%2Fwork%2Finternational%2Findex.md", __ASTRO_IMAGE_IMPORT_FM05D], ["./dross.png?astroContentImageFlag=&importer=src%2Fcontent%2Fwork%2Fjiva-lite%2Findex.md", __ASTRO_IMAGE_IMPORT_A1tQz], ["./figjam.png?astroContentImageFlag=&importer=src%2Fcontent%2Fwork%2Fjiva-lite%2Findex.md", __ASTRO_IMAGE_IMPORT_ZGbMWl], ["./git25.png?astroContentImageFlag=&importer=src%2Fcontent%2Fwriting%2Fvibe-coding%2Findex.md", __ASTRO_IMAGE_IMPORT_pTGt3], ["./gorontalo.jpeg?astroContentImageFlag=&importer=src%2Fcontent%2Fwork%2Fjiva-lite%2Findex.md", __ASTRO_IMAGE_IMPORT_Z2h82xm], ["./jivalite-ground.png?astroContentImageFlag=&importer=src%2Fcontent%2Fwork%2Fjiva-lite%2Findex.md", __ASTRO_IMAGE_IMPORT_LumN8], ["./jivalite.jpg?astroContentImageFlag=&importer=src%2Fcontent%2Fwork%2Fjiva-lite%2Findex.md", __ASTRO_IMAGE_IMPORT_Z1SL4zh], ["./jivalitev1.png?astroContentImageFlag=&importer=src%2Fcontent%2Fwork%2Fjiva-lite%2Findex.md", __ASTRO_IMAGE_IMPORT_1CGnrC], ["./jl-impact-1.png?astroContentImageFlag=&importer=src%2Fcontent%2Fwork%2Fjiva-lite%2Findex.md", __ASTRO_IMAGE_IMPORT_1D7hUh], ["./jl-impact-2.png?astroContentImageFlag=&importer=src%2Fcontent%2Fwork%2Fjiva-lite%2Findex.md", __ASTRO_IMAGE_IMPORT_10U3Am], ["./landbot.png?astroContentImageFlag=&importer=src%2Fcontent%2Fwork%2Fjiva-lite%2Findex.md", __ASTRO_IMAGE_IMPORT_1xc7mp], ["./lite-wire.png?astroContentImageFlag=&importer=src%2Fcontent%2Fwork%2Fjiva-lite%2Findex.md", __ASTRO_IMAGE_IMPORT_jy2SX], ["./lookback-design-tools-1.jpg?astroContentImageFlag=&importer=src%2Fcontent%2Fwriting%2Fdesign-tools-decade%2Findex.md", __ASTRO_IMAGE_IMPORT_Z1p4q1D], ["./lookback-design-tools-2.jpg?astroContentImageFlag=&importer=src%2Fcontent%2Fwriting%2Fdesign-tools-decade%2Findex.md", __ASTRO_IMAGE_IMPORT_Z2mwJGO], ["./lookback-design-tools-3.png?astroContentImageFlag=&importer=src%2Fcontent%2Fwriting%2Fdesign-tools-decade%2Findex.md", __ASTRO_IMAGE_IMPORT_Z181dEH], ["./lookback-design-tools-4.png?astroContentImageFlag=&importer=src%2Fcontent%2Fwriting%2Fdesign-tools-decade%2Findex.md", __ASTRO_IMAGE_IMPORT_Z25txkS], ["./lookback-design-tools-5.png?astroContentImageFlag=&importer=src%2Fcontent%2Fwriting%2Fdesign-tools-decade%2Findex.md", __ASTRO_IMAGE_IMPORT_22fgMR], ["./practo-pro.png?astroContentImageFlag=&importer=src%2Fcontent%2Fwork%2Fpracto-pro%2Findex.md", __ASTRO_IMAGE_IMPORT_jzjgC], ["./practo-profile.png?astroContentImageFlag=&importer=src%2Fcontent%2Fwork%2Fclaim-profile%2Findex.md", __ASTRO_IMAGE_IMPORT_17I6uK], ["./process-1.png?astroContentImageFlag=&importer=src%2Fcontent%2Fwriting%2Fprocess%2Findex.md", __ASTRO_IMAGE_IMPORT_cIH9C], ["./product-designer-1.png?astroContentImageFlag=&importer=src%2Fcontent%2Fwriting%2Fproduct-designer%2Findex.md", __ASTRO_IMAGE_IMPORT_Z1Yqs2V], ["./product-designer-2.jpg?astroContentImageFlag=&importer=src%2Fcontent%2Fwriting%2Fproduct-designer%2Findex.md", __ASTRO_IMAGE_IMPORT_Z1zlJut], ["./rip-design-process.png?astroContentImageFlag=&importer=src%2Fcontent%2Fwriting%2Flong-live-design-process%2Findex.md", __ASTRO_IMAGE_IMPORT_ZOhPlD], ["./sjhome.webp?astroContentImageFlag=&importer=src%2Fcontent%2Fwork%2Fsahabat-jiva-redesign%2Findex.md", __ASTRO_IMAGE_IMPORT_Zxxblt], ["./solo-designer-jobs-1.png?astroContentImageFlag=&importer=src%2Fcontent%2Fwriting%2Fsolo-designer%2Findex.md", __ASTRO_IMAGE_IMPORT_2sVTyP], ["./spiderkaran.png?astroContentImageFlag=&importer=src%2Fcontent%2Fwork%2Fjiva-lite%2Findex.md", __ASTRO_IMAGE_IMPORT_1bULPG], ["./squiggle-labels-outline.jpg?astroContentImageFlag=&importer=src%2Fcontent%2Fwriting%2Fproduct-designer%2Findex.md", __ASTRO_IMAGE_IMPORT_ogiEj], ["./thai-header.jpeg?astroContentImageFlag=&importer=src%2Fcontent%2Fwork%2Finternational%2Findex.md", __ASTRO_IMAGE_IMPORT_Z1CNLo3], ["./thai-research.jpeg?astroContentImageFlag=&importer=src%2Fcontent%2Fwork%2Finternational%2Findex.md", __ASTRO_IMAGE_IMPORT_jN1fQ], ["./user-behaviour.png?astroContentImageFlag=&importer=src%2Fcontent%2Fwork%2Finternational%2Findex.md", __ASTRO_IMAGE_IMPORT_lu7jP], ["./viet.png?astroContentImageFlag=&importer=src%2Fcontent%2Fwork%2Finternational%2Findex.md", __ASTRO_IMAGE_IMPORT_20sBpP], ["./whiteboard.JPG?astroContentImageFlag=&importer=src%2Fcontent%2Fwriting%2Fhiring-2%2Findex.md", __ASTRO_IMAGE_IMPORT_22txty], ["./zoom.png?astroContentImageFlag=&importer=src%2Fcontent%2Fwriting%2Frituals%2Findex.md", __ASTRO_IMAGE_IMPORT_Z1gJ4cL], ["67.png?astroContentImageFlag=&importer=src%2Fcontent%2Fwriting%2Fvibe-coding%2Findex.md", __ASTRO_IMAGE_IMPORT_2obKnP], ["Design_Sprints.png?astroContentImageFlag=&importer=src%2Fcontent%2Fwriting%2Flong-live-design-process%2Findex.md", __ASTRO_IMAGE_IMPORT_Z2jJ5Ao], ["Early-explorations.png?astroContentImageFlag=&importer=src%2Fcontent%2Fwork%2Fgojek%2Findex.md", __ASTRO_IMAGE_IMPORT_4i5Y1], ["GoBiz-ratings.webp?astroContentImageFlag=&importer=src%2Fcontent%2Fwork%2Fgojek%2Findex.md", __ASTRO_IMAGE_IMPORT_Z1bqxmS], ["Gobiz-web.png?astroContentImageFlag=&importer=src%2Fcontent%2Fwork%2Fgojek%2Findex.md", __ASTRO_IMAGE_IMPORT_1bfU05], ["Gobiz-web3.png?astroContentImageFlag=&importer=src%2Fcontent%2Fwork%2Fgojek%2Findex.md", __ASTRO_IMAGE_IMPORT_FxCr], ["QRIS-gobiz.webp?astroContentImageFlag=&importer=src%2Fcontent%2Fwork%2Fgojek%2Findex.md", __ASTRO_IMAGE_IMPORT_15X722], ["akar-screens.webp?astroContentImageFlag=&importer=src%2Fcontent%2Fwork%2Fakar-design-system%2Findex.md", __ASTRO_IMAGE_IMPORT_ZYRBrj], ["budgie.png?astroContentImageFlag=&importer=src%2Fcontent%2Fwriting%2Fvibe-coding%2Findex.md", __ASTRO_IMAGE_IMPORT_9bdU7], ["color.webp?astroContentImageFlag=&importer=src%2Fcontent%2Fwork%2Fakar-design-system%2Findex.md", __ASTRO_IMAGE_IMPORT_dLojj], ["design-system-philosophy.webp?astroContentImageFlag=&importer=src%2Fcontent%2Fwork%2Fakar-design-system%2Findex.md", __ASTRO_IMAGE_IMPORT_9aYqu], ["gobiz-nav.jpg?astroContentImageFlag=&importer=src%2Fcontent%2Fwork%2Fgojek%2Findex.md", __ASTRO_IMAGE_IMPORT_Z1OS06e], ["gobiz-order.png?astroContentImageFlag=&importer=src%2Fcontent%2Fwork%2Fgojek%2Findex.md", __ASTRO_IMAGE_IMPORT_ilaDG], ["gobiz-v1.png?astroContentImageFlag=&importer=src%2Fcontent%2Fwork%2Fgojek%2Findex.md", __ASTRO_IMAGE_IMPORT_2tXh3t], ["how-to-tokens.webp?astroContentImageFlag=&importer=src%2Fcontent%2Fwork%2Fakar-design-system%2Findex.md", __ASTRO_IMAGE_IMPORT_Z1BXNHp], ["jivalite-ground.png?astroContentImageFlag=&importer=src%2Fcontent%2Fwriting%2Flong-live-design-process%2Findex.md", __ASTRO_IMAGE_IMPORT_1Q0tfQ], ["midtrans-old.png?astroContentImageFlag=&importer=src%2Fcontent%2Fwork%2Fgojek%2Findex.md", __ASTRO_IMAGE_IMPORT_23hBfS], ["midtrans-onboarding-1.png?astroContentImageFlag=&importer=src%2Fcontent%2Fwork%2Fgojek%2Findex.md", __ASTRO_IMAGE_IMPORT_1887Yy], ["midtrans-onboarding-2.png?astroContentImageFlag=&importer=src%2Fcontent%2Fwork%2Fgojek%2Findex.md", __ASTRO_IMAGE_IMPORT_196JQK], ["midtrans-onboarding-impact.png?astroContentImageFlag=&importer=src%2Fcontent%2Fwork%2Fgojek%2Findex.md", __ASTRO_IMAGE_IMPORT_Ft3Cm], ["naming.webp?astroContentImageFlag=&importer=src%2Fcontent%2Fwork%2Fakar-design-system%2Findex.md", __ASTRO_IMAGE_IMPORT_1Se92b], ["rough-sketches.png?astroContentImageFlag=&importer=src%2Fcontent%2Fwork%2Fgojek%2Findex.md", __ASTRO_IMAGE_IMPORT_Z1zMcvl], ["spots.png?astroContentImageFlag=&importer=src%2Fcontent%2Fwork%2Fgojek%2Findex.md", __ASTRO_IMAGE_IMPORT_Z4LDMj], ["styleguide.webp?astroContentImageFlag=&importer=src%2Fcontent%2Fwork%2Fakar-design-system%2Findex.md", __ASTRO_IMAGE_IMPORT_Z2wmyeK], ["type.webp?astroContentImageFlag=&importer=src%2Fcontent%2Fwork%2Fakar-design-system%2Findex.md", __ASTRO_IMAGE_IMPORT_CljXE], ["v1-prototype.png?astroContentImageFlag=&importer=src%2Fcontent%2Fwriting%2Fvibe-coding%2Findex.md", __ASTRO_IMAGE_IMPORT_ZSEHB]]); +export default new Map([["./4IiQQOEdmqPcCsjTqlta-1.png?astroContentImageFlag=&importer=src%2Fcontent%2Fwriting%2Fdesign-in-tech-2024%2Findex.md", __ASTRO_IMAGE_IMPORT_Z1AyhWV], ["./QRIS-gobiz.webp?astroContentImageFlag=&importer=src%2Fcontent%2Fwork%2Fgojek%2Findex.md", __ASTRO_IMAGE_IMPORT_JitFy], ["./akar.webp?astroContentImageFlag=&importer=src%2Fcontent%2Fwork%2Fakar-design-system%2Findex.md", __ASTRO_IMAGE_IMPORT_Z2g9ce], ["./asana.png?astroContentImageFlag=&importer=src%2Fcontent%2Fwork%2Finternational%2Findex.md", __ASTRO_IMAGE_IMPORT_Zn0Wwm], ["./chatgpt-final.png?astroContentImageFlag=&importer=src%2Fcontent%2Fwriting%2Fvibe-coding%2Findex.md", __ASTRO_IMAGE_IMPORT_Z1Rx8Co], ["./chatgpt-v1.png?astroContentImageFlag=&importer=src%2Fcontent%2Fwriting%2Fvibe-coding%2Findex.md", __ASTRO_IMAGE_IMPORT_Zc35bV], ["./claude-v1.png?astroContentImageFlag=&importer=src%2Fcontent%2Fwriting%2Fvibe-coding%2Findex.md", __ASTRO_IMAGE_IMPORT_Z1c50EV], ["./competitors.png?astroContentImageFlag=&importer=src%2Fcontent%2Fwork%2Finternational%2Findex.md", __ASTRO_IMAGE_IMPORT_RDvgL], ["./copy-doc.png?astroContentImageFlag=&importer=src%2Fcontent%2Fwork%2Finternational%2Findex.md", __ASTRO_IMAGE_IMPORT_Z2bA4yw], ["./copy-sheets.png?astroContentImageFlag=&importer=src%2Fcontent%2Fwork%2Finternational%2Findex.md", __ASTRO_IMAGE_IMPORT_ZTIp58], ["./design-keliling.jpg?astroContentImageFlag=&importer=src%2Fcontent%2Fwriting%2Fhiring%2Findex.md", __ASTRO_IMAGE_IMPORT_2gJYQo], ["./dogfooding.png?astroContentImageFlag=&importer=src%2Fcontent%2Fwork%2Finternational%2Findex.md", __ASTRO_IMAGE_IMPORT_FM05D], ["./dross.png?astroContentImageFlag=&importer=src%2Fcontent%2Fwork%2Fjiva-lite%2Findex.md", __ASTRO_IMAGE_IMPORT_A1tQz], ["./figjam.png?astroContentImageFlag=&importer=src%2Fcontent%2Fwork%2Fjiva-lite%2Findex.md", __ASTRO_IMAGE_IMPORT_ZGbMWl], ["./git25.png?astroContentImageFlag=&importer=src%2Fcontent%2Fwriting%2Fvibe-coding%2Findex.md", __ASTRO_IMAGE_IMPORT_pTGt3], ["./gorontalo.jpeg?astroContentImageFlag=&importer=src%2Fcontent%2Fwork%2Fjiva-lite%2Findex.md", __ASTRO_IMAGE_IMPORT_Z2h82xm], ["./grindsize.png?astroContentImageFlag=&importer=src%2Fcontent%2Fwriting%2Fhow-i-build-with-ai%2Findex.md", __ASTRO_IMAGE_IMPORT_2dP0WI], ["./how-i-build.png?astroContentImageFlag=&importer=src%2Fcontent%2Fwriting%2Fhow-i-build-with-ai%2Findex.md", __ASTRO_IMAGE_IMPORT_Z2wl5XB], ["./jivalite-ground.png?astroContentImageFlag=&importer=src%2Fcontent%2Fwork%2Fjiva-lite%2Findex.md", __ASTRO_IMAGE_IMPORT_LumN8], ["./jivalite.jpg?astroContentImageFlag=&importer=src%2Fcontent%2Fwork%2Fjiva-lite%2Findex.md", __ASTRO_IMAGE_IMPORT_Z1SL4zh], ["./jivalitev1.png?astroContentImageFlag=&importer=src%2Fcontent%2Fwork%2Fjiva-lite%2Findex.md", __ASTRO_IMAGE_IMPORT_1CGnrC], ["./jl-impact-1.png?astroContentImageFlag=&importer=src%2Fcontent%2Fwork%2Fjiva-lite%2Findex.md", __ASTRO_IMAGE_IMPORT_1D7hUh], ["./jl-impact-2.png?astroContentImageFlag=&importer=src%2Fcontent%2Fwork%2Fjiva-lite%2Findex.md", __ASTRO_IMAGE_IMPORT_10U3Am], ["./landbot.png?astroContentImageFlag=&importer=src%2Fcontent%2Fwork%2Fjiva-lite%2Findex.md", __ASTRO_IMAGE_IMPORT_1xc7mp], ["./lite-wire.png?astroContentImageFlag=&importer=src%2Fcontent%2Fwork%2Fjiva-lite%2Findex.md", __ASTRO_IMAGE_IMPORT_jy2SX], ["./lookback-design-tools-1.jpg?astroContentImageFlag=&importer=src%2Fcontent%2Fwriting%2Fdesign-tools-decade%2Findex.md", __ASTRO_IMAGE_IMPORT_Z1p4q1D], ["./lookback-design-tools-2.jpg?astroContentImageFlag=&importer=src%2Fcontent%2Fwriting%2Fdesign-tools-decade%2Findex.md", __ASTRO_IMAGE_IMPORT_Z2mwJGO], ["./lookback-design-tools-3.png?astroContentImageFlag=&importer=src%2Fcontent%2Fwriting%2Fdesign-tools-decade%2Findex.md", __ASTRO_IMAGE_IMPORT_Z181dEH], ["./lookback-design-tools-4.png?astroContentImageFlag=&importer=src%2Fcontent%2Fwriting%2Fdesign-tools-decade%2Findex.md", __ASTRO_IMAGE_IMPORT_Z25txkS], ["./lookback-design-tools-5.png?astroContentImageFlag=&importer=src%2Fcontent%2Fwriting%2Fdesign-tools-decade%2Findex.md", __ASTRO_IMAGE_IMPORT_22fgMR], ["./practo-pro.png?astroContentImageFlag=&importer=src%2Fcontent%2Fwork%2Fpracto-pro%2Findex.md", __ASTRO_IMAGE_IMPORT_jzjgC], ["./practo-profile.png?astroContentImageFlag=&importer=src%2Fcontent%2Fwork%2Fclaim-profile%2Findex.md", __ASTRO_IMAGE_IMPORT_17I6uK], ["./process-1.png?astroContentImageFlag=&importer=src%2Fcontent%2Fwriting%2Fprocess%2Findex.md", __ASTRO_IMAGE_IMPORT_cIH9C], ["./product-designer-1.png?astroContentImageFlag=&importer=src%2Fcontent%2Fwriting%2Fproduct-designer%2Findex.md", __ASTRO_IMAGE_IMPORT_Z1Yqs2V], ["./product-designer-2.jpg?astroContentImageFlag=&importer=src%2Fcontent%2Fwriting%2Fproduct-designer%2Findex.md", __ASTRO_IMAGE_IMPORT_Z1zlJut], ["./rip-design-process.png?astroContentImageFlag=&importer=src%2Fcontent%2Fwriting%2Flong-live-design-process%2Findex.md", __ASTRO_IMAGE_IMPORT_ZOhPlD], ["./sjhome.webp?astroContentImageFlag=&importer=src%2Fcontent%2Fwork%2Fsahabat-jiva-redesign%2Findex.md", __ASTRO_IMAGE_IMPORT_Zxxblt], ["./solo-designer-jobs-1.png?astroContentImageFlag=&importer=src%2Fcontent%2Fwriting%2Fsolo-designer%2Findex.md", __ASTRO_IMAGE_IMPORT_2sVTyP], ["./spiderkaran.png?astroContentImageFlag=&importer=src%2Fcontent%2Fwork%2Fjiva-lite%2Findex.md", __ASTRO_IMAGE_IMPORT_1bULPG], ["./squiggle-labels-outline.jpg?astroContentImageFlag=&importer=src%2Fcontent%2Fwriting%2Fproduct-designer%2Findex.md", __ASTRO_IMAGE_IMPORT_ogiEj], ["./thai-header.jpeg?astroContentImageFlag=&importer=src%2Fcontent%2Fwork%2Finternational%2Findex.md", __ASTRO_IMAGE_IMPORT_Z1CNLo3], ["./thai-research.jpeg?astroContentImageFlag=&importer=src%2Fcontent%2Fwork%2Finternational%2Findex.md", __ASTRO_IMAGE_IMPORT_jN1fQ], ["./user-behaviour.png?astroContentImageFlag=&importer=src%2Fcontent%2Fwork%2Finternational%2Findex.md", __ASTRO_IMAGE_IMPORT_lu7jP], ["./variant.png?astroContentImageFlag=&importer=src%2Fcontent%2Fwriting%2Fhow-i-build-with-ai%2Findex.md", __ASTRO_IMAGE_IMPORT_ZVag2n], ["./viet.png?astroContentImageFlag=&importer=src%2Fcontent%2Fwork%2Finternational%2Findex.md", __ASTRO_IMAGE_IMPORT_20sBpP], ["./whiteboard.JPG?astroContentImageFlag=&importer=src%2Fcontent%2Fwriting%2Fhiring-2%2Findex.md", __ASTRO_IMAGE_IMPORT_22txty], ["./zoom.png?astroContentImageFlag=&importer=src%2Fcontent%2Fwriting%2Frituals%2Findex.md", __ASTRO_IMAGE_IMPORT_Z1gJ4cL], ["67.png?astroContentImageFlag=&importer=src%2Fcontent%2Fwriting%2Fvibe-coding%2Findex.md", __ASTRO_IMAGE_IMPORT_2obKnP], ["Design_Sprints.png?astroContentImageFlag=&importer=src%2Fcontent%2Fwriting%2Flong-live-design-process%2Findex.md", __ASTRO_IMAGE_IMPORT_Z2jJ5Ao], ["Early-explorations.png?astroContentImageFlag=&importer=src%2Fcontent%2Fwork%2Fgojek%2Findex.md", __ASTRO_IMAGE_IMPORT_4i5Y1], ["GoBiz-ratings.webp?astroContentImageFlag=&importer=src%2Fcontent%2Fwork%2Fgojek%2Findex.md", __ASTRO_IMAGE_IMPORT_Z1bqxmS], ["Gobiz-web.png?astroContentImageFlag=&importer=src%2Fcontent%2Fwork%2Fgojek%2Findex.md", __ASTRO_IMAGE_IMPORT_1bfU05], ["Gobiz-web3.png?astroContentImageFlag=&importer=src%2Fcontent%2Fwork%2Fgojek%2Findex.md", __ASTRO_IMAGE_IMPORT_FxCr], ["QRIS-gobiz.webp?astroContentImageFlag=&importer=src%2Fcontent%2Fwork%2Fgojek%2Findex.md", __ASTRO_IMAGE_IMPORT_15X722], ["akar-screens.webp?astroContentImageFlag=&importer=src%2Fcontent%2Fwork%2Fakar-design-system%2Findex.md", __ASTRO_IMAGE_IMPORT_ZYRBrj], ["budgie.png?astroContentImageFlag=&importer=src%2Fcontent%2Fwriting%2Fvibe-coding%2Findex.md", __ASTRO_IMAGE_IMPORT_9bdU7], ["color.webp?astroContentImageFlag=&importer=src%2Fcontent%2Fwork%2Fakar-design-system%2Findex.md", __ASTRO_IMAGE_IMPORT_dLojj], ["design-system-philosophy.webp?astroContentImageFlag=&importer=src%2Fcontent%2Fwork%2Fakar-design-system%2Findex.md", __ASTRO_IMAGE_IMPORT_9aYqu], ["gobiz-nav.jpg?astroContentImageFlag=&importer=src%2Fcontent%2Fwork%2Fgojek%2Findex.md", __ASTRO_IMAGE_IMPORT_Z1OS06e], ["gobiz-order.png?astroContentImageFlag=&importer=src%2Fcontent%2Fwork%2Fgojek%2Findex.md", __ASTRO_IMAGE_IMPORT_ilaDG], ["gobiz-v1.png?astroContentImageFlag=&importer=src%2Fcontent%2Fwork%2Fgojek%2Findex.md", __ASTRO_IMAGE_IMPORT_2tXh3t], ["how-to-tokens.webp?astroContentImageFlag=&importer=src%2Fcontent%2Fwork%2Fakar-design-system%2Findex.md", __ASTRO_IMAGE_IMPORT_Z1BXNHp], ["jivalite-ground.png?astroContentImageFlag=&importer=src%2Fcontent%2Fwriting%2Flong-live-design-process%2Findex.md", __ASTRO_IMAGE_IMPORT_1Q0tfQ], ["midtrans-old.png?astroContentImageFlag=&importer=src%2Fcontent%2Fwork%2Fgojek%2Findex.md", __ASTRO_IMAGE_IMPORT_23hBfS], ["midtrans-onboarding-1.png?astroContentImageFlag=&importer=src%2Fcontent%2Fwork%2Fgojek%2Findex.md", __ASTRO_IMAGE_IMPORT_1887Yy], ["midtrans-onboarding-2.png?astroContentImageFlag=&importer=src%2Fcontent%2Fwork%2Fgojek%2Findex.md", __ASTRO_IMAGE_IMPORT_196JQK], ["midtrans-onboarding-impact.png?astroContentImageFlag=&importer=src%2Fcontent%2Fwork%2Fgojek%2Findex.md", __ASTRO_IMAGE_IMPORT_Ft3Cm], ["naming.webp?astroContentImageFlag=&importer=src%2Fcontent%2Fwork%2Fakar-design-system%2Findex.md", __ASTRO_IMAGE_IMPORT_1Se92b], ["rough-sketches.png?astroContentImageFlag=&importer=src%2Fcontent%2Fwork%2Fgojek%2Findex.md", __ASTRO_IMAGE_IMPORT_Z1zMcvl], ["spots.png?astroContentImageFlag=&importer=src%2Fcontent%2Fwork%2Fgojek%2Findex.md", __ASTRO_IMAGE_IMPORT_Z4LDMj], ["styleguide.webp?astroContentImageFlag=&importer=src%2Fcontent%2Fwork%2Fakar-design-system%2Findex.md", __ASTRO_IMAGE_IMPORT_Z2wmyeK], ["type.webp?astroContentImageFlag=&importer=src%2Fcontent%2Fwork%2Fakar-design-system%2Findex.md", __ASTRO_IMAGE_IMPORT_CljXE], ["v1-prototype.png?astroContentImageFlag=&importer=src%2Fcontent%2Fwriting%2Fvibe-coding%2Findex.md", __ASTRO_IMAGE_IMPORT_ZSEHB]]); \ No newline at end of file diff --git a/astro-site/.astro/data-store.json b/astro-site/.astro/data-store.json index 78f70798..05aad4b4 100644 --- a/astro-site/.astro/data-store.json +++ b/astro-site/.astro/data-store.json @@ -1 +1 @@ -[["Map",1,2,9,10,334,335,365,366],"meta::meta",["Map",3,4,5,6,7,8],"astro-version","5.16.0","content-config-digest","351ae21ed6cab114","astro-config-digest","{\"root\":{},\"srcDir\":{},\"publicDir\":{},\"outDir\":{},\"cacheDir\":{},\"site\":\"https://kenneth.dsouza.im\",\"compressHTML\":true,\"base\":\"/\",\"trailingSlash\":\"ignore\",\"output\":\"static\",\"scopedStyleStrategy\":\"attribute\",\"build\":{\"format\":\"directory\",\"client\":{},\"server\":{},\"assets\":\"_astro\",\"serverEntry\":\"entry.mjs\",\"redirects\":true,\"inlineStylesheets\":\"auto\",\"concurrency\":1},\"server\":{\"open\":false,\"host\":false,\"port\":4321,\"streaming\":true,\"allowedHosts\":[]},\"redirects\":{},\"image\":{\"endpoint\":{\"route\":\"/_image\"},\"service\":{\"entrypoint\":\"astro/assets/services/sharp\",\"config\":{}},\"domains\":[],\"remotePatterns\":[],\"responsiveStyles\":false},\"devToolbar\":{\"enabled\":true},\"markdown\":{\"syntaxHighlight\":{\"type\":\"shiki\",\"excludeLangs\":[\"math\"]},\"shikiConfig\":{\"langs\":[],\"langAlias\":{},\"theme\":\"github-dark\",\"themes\":{},\"wrap\":false,\"transformers\":[]},\"remarkPlugins\":[null],\"rehypePlugins\":[[null,{\"className\":\"image-figure\"}]],\"remarkRehype\":{},\"gfm\":true,\"smartypants\":true},\"security\":{\"checkOrigin\":true,\"allowedDomains\":[]},\"env\":{\"schema\":{},\"validateSecrets\":false},\"experimental\":{\"clientPrerender\":false,\"contentIntellisense\":false,\"headingIdCompat\":false,\"preserveScriptOrder\":false,\"liveContentCollections\":false,\"csp\":false,\"staticImportMetaEnv\":false,\"chromeDevtoolsWorkspace\":false,\"failOnPrerenderConflict\":false,\"svgo\":false},\"legacy\":{\"collections\":false}}","writing",["Map",11,12,34,35,60,61,82,83,126,127,157,158,188,189,218,219,254,255,277,278,302,303],"design-in-tech-2024",{"id":11,"data":13,"body":19,"filePath":20,"assetImports":21,"digest":23,"rendered":24,"legacyId":33},{"title":14,"description":15,"date":16,"image":17,"status":18},"An Insider's perspective on Design in Tech 2024","Reflections on the state of design leadership and the industry in India and Indonesia",["Date","2024-01-01T00:00:00.000Z"],"__ASTRO_IMAGE_./4IiQQOEdmqPcCsjTqlta-1.png","published","After the Great Layoffs, I've been seeing too many people declaring the [death](https://www.fastcompany.com/91027996/the-big-design-freak-out-a-generation-of-design-leaders-grapple-with-their-future) of [design](https://medium.com/@martynreding/how-to-survive-the-design-leadership-reckoning-ff2856bf4733) leadership and with the rise of AI, the death of the digital design industry as well. but I find that it's a poorly informed take and no offence, but in my opinion, written by outsiders or written about a specific industry/region/designer. In fact, there are a lot of highly [priced](https://maven.com/rachel-kobetz/dls-career-architecture) [leadership](https://www.designdept.co/series/design-leadership-fundamentals) [training](https://www.aiga.org/design/design-leadership) courses out there these days.\n\nOver my career of 10 odd years, I’ve had the honour of being an observer in the product design industry of 2 countries; India and Indonesia. My perspective comes from my vantage point of living in the Silicon Valley of India and professionally, from being part of the growth stage of the well funded startups.\n\nFor this article(rant?), I will use Startups vs Big Tech for sake of categorisation. Big tech would have the minimum expectation of being a listed company operating across more than 1 geographical region. Meta and the other MAANG companies would fall into big tech but do remember that they are the new entrants in a space already filled by CISCO, Intuit, Adobe.\n\nPost the dot-com bust, we saw the slow rise of today’s modern digital startups. First in the Silicon Valley and then in the rest of the world. This was mainly fuelled by the VC funding and still is. This lead us to look up to the Silicon Valley companies and the folks there as thought leaders for design. And rightly so since they were working on products we admired and used half a world away. That scale and magnitude is definitely something to be proud of. They encountered and solved problems at scale, establishing standards, registering patents and forming user behaviours that we take for granted today\n\nBut in our part of the world, even today, digital product design is still attempting to break out of its UI and UX tags. When I started out in 2014, UI/UX was the predominant way of describing designers in big tech, and even startups. Of course there were exceptions, but I will ignore them as outliers. The startup I worked at back then, was one of the first in India to adopt Facebook's popular convention to start using the term 'Product Designer'. Back then, the Indian digital design industry was so small. You were separated by 1-2 degrees from everyone and arguably, it's still that small. The VC funding, however, gave rise to a notion that tech startups are a lucrative career compared to the dominant IT/ITES industry. This led to a gold rush fuelled by opportunistic bootcamps and certification courses, most of which churned out low skill designers. However, unlike the West, few companies thrived and hardly any have scaled and now we have a supply-demand problem at hand.\n\nThis leads us to where we are today:\n\n1. Local companies are not getting 'Big' enough or if they are, once they get listed, they need to justify costs and respond to the market. It's quite easy for decision makers to take that call and cut a few roles to keep costs in check. Easier than getting out of your software license contracts to cut costs. Also much easier to do this when others in the industry are also doing layoffs. Smaller companies mean there are fewer senior roles to be filled especially when most teams out there are feature factories who know what to build next.\n\n2. In my experience, Design leaders in startups have always been expected to play a dual role of designer + manager. In fact the designer aspect is valued a lot more while the manager title is granted to keep designers happy. That said, Most companies do not know what to do with the design leaders that they hire. So often, what you encounter is the Design Leader who is a figurehead to appease the junior designers with almost 0 influence on business outcomes or worst case, to be head of design of a design team of 1. This explains the short tenures because those roles are just not fulfilling.\n\n3. This may anger a few, but in the current state of the industry, design progression ladders don’t need an IC track beyond the level of a senior designer of 5-6 years of experience. If you are not a Meta/Google, I don’t expect there to be scope or complexity that needs Staff Designers. So where have these senior designers been going? Well some of them move into “Manager” roles without the skills to operate in them while others tend to move out of the country to join companies which may have grown to a larger size or worst case at least they get to experience a new culture.\n\n4. The skills you need as a manager are different from the ones you polished as an IC designer. Being good at Figma can only take you so far, if you don’t have an affinity for bureaucracy, then being a manager is a bad fit. On the other extreme are the managers and heads of design, usually from a background in older big tech companies, who were at positions where their job was to pontificate about design and innovation. These folk tend to be disconnected from the day-to-day work and that’s bad for the team as well. Both of these are highly replaceable roles.\n\n5. And finally, we have not moved away from the worker productivity categorisation of industrialisation. Bell curves are common, business wants to keep control and budgets are paramount. I would like to argue that Design never got a seat at the table. The \"Design Thinking\" hype that got thrown around by IBM, McKinsey, IDEO was for their own PR and has run its due course. Everyone likes an optimistic story but rarely would you find actual organization leaders(CXOs) believing in the value that Design brings to the business and actually investing into Design. That is as true today, as it was a decade ago and hence good fulfilling design jobs are few and far between.\n\n This does not paint a very rosy picture of today's design industry but after all these years, this is my honest take on the state of affairs. Perhaps we've been swayed by all the positive marketing around design, perhaps we've believed that design in tech can save the world, but in reality, designers find themselves in a dystopia that they don't want to acknowledge. The old folks of the industry who have survived, will continue to do so but if you are a beginner, if you want to stick to design in tech, I recommend that you choose a discipline like engineering or product instead and leave your empathy at the door.","src/content/writing/design-in-tech-2024/index.md",[22],"./4IiQQOEdmqPcCsjTqlta-1.png","810211681d2c5d00",{"html":25,"metadata":26},"\u003Cp>After the Great Layoffs, I’ve been seeing too many people declaring the \u003Ca href=\"https://www.fastcompany.com/91027996/the-big-design-freak-out-a-generation-of-design-leaders-grapple-with-their-future\">death\u003C/a> of \u003Ca href=\"https://medium.com/@martynreding/how-to-survive-the-design-leadership-reckoning-ff2856bf4733\">design\u003C/a> leadership and with the rise of AI, the death of the digital design industry as well. but I find that it’s a poorly informed take and no offence, but in my opinion, written by outsiders or written about a specific industry/region/designer. In fact, there are a lot of highly \u003Ca href=\"https://maven.com/rachel-kobetz/dls-career-architecture\">priced\u003C/a> \u003Ca href=\"https://www.designdept.co/series/design-leadership-fundamentals\">leadership\u003C/a> \u003Ca href=\"https://www.aiga.org/design/design-leadership\">training\u003C/a> courses out there these days.\u003C/p>\n\u003Cp>Over my career of 10 odd years, I’ve had the honour of being an observer in the product design industry of 2 countries; India and Indonesia. My perspective comes from my vantage point of living in the Silicon Valley of India and professionally, from being part of the growth stage of the well funded startups.\u003C/p>\n\u003Cp>For this article(rant?), I will use Startups vs Big Tech for sake of categorisation. Big tech would have the minimum expectation of being a listed company operating across more than 1 geographical region. Meta and the other MAANG companies would fall into big tech but do remember that they are the new entrants in a space already filled by CISCO, Intuit, Adobe.\u003C/p>\n\u003Cp>Post the dot-com bust, we saw the slow rise of today’s modern digital startups. First in the Silicon Valley and then in the rest of the world. This was mainly fuelled by the VC funding and still is. This lead us to look up to the Silicon Valley companies and the folks there as thought leaders for design. And rightly so since they were working on products we admired and used half a world away. That scale and magnitude is definitely something to be proud of. They encountered and solved problems at scale, establishing standards, registering patents and forming user behaviours that we take for granted today\u003C/p>\n\u003Cp>But in our part of the world, even today, digital product design is still attempting to break out of its UI and UX tags. When I started out in 2014, UI/UX was the predominant way of describing designers in big tech, and even startups. Of course there were exceptions, but I will ignore them as outliers. The startup I worked at back then, was one of the first in India to adopt Facebook’s popular convention to start using the term ‘Product Designer’. Back then, the Indian digital design industry was so small. You were separated by 1-2 degrees from everyone and arguably, it’s still that small. The VC funding, however, gave rise to a notion that tech startups are a lucrative career compared to the dominant IT/ITES industry. This led to a gold rush fuelled by opportunistic bootcamps and certification courses, most of which churned out low skill designers. However, unlike the West, few companies thrived and hardly any have scaled and now we have a supply-demand problem at hand.\u003C/p>\n\u003Cp>This leads us to where we are today:\u003C/p>\n\u003Col>\n\u003Cli>\n\u003Cp>Local companies are not getting ‘Big’ enough or if they are, once they get listed, they need to justify costs and respond to the market. It’s quite easy for decision makers to take that call and cut a few roles to keep costs in check. Easier than getting out of your software license contracts to cut costs. Also much easier to do this when others in the industry are also doing layoffs. Smaller companies mean there are fewer senior roles to be filled especially when most teams out there are feature factories who know what to build next.\u003C/p>\n\u003C/li>\n\u003Cli>\n\u003Cp>In my experience, Design leaders in startups have always been expected to play a dual role of designer + manager. In fact the designer aspect is valued a lot more while the manager title is granted to keep designers happy. That said, Most companies do not know what to do with the design leaders that they hire. So often, what you encounter is the Design Leader who is a figurehead to appease the junior designers with almost 0 influence on business outcomes or worst case, to be head of design of a design team of 1. This explains the short tenures because those roles are just not fulfilling.\u003C/p>\n\u003C/li>\n\u003Cli>\n\u003Cp>This may anger a few, but in the current state of the industry, design progression ladders don’t need an IC track beyond the level of a senior designer of 5-6 years of experience. If you are not a Meta/Google, I don’t expect there to be scope or complexity that needs Staff Designers. So where have these senior designers been going? Well some of them move into “Manager” roles without the skills to operate in them while others tend to move out of the country to join companies which may have grown to a larger size or worst case at least they get to experience a new culture.\u003C/p>\n\u003C/li>\n\u003Cli>\n\u003Cp>The skills you need as a manager are different from the ones you polished as an IC designer. Being good at Figma can only take you so far, if you don’t have an affinity for bureaucracy, then being a manager is a bad fit. On the other extreme are the managers and heads of design, usually from a background in older big tech companies, who were at positions where their job was to pontificate about design and innovation. These folk tend to be disconnected from the day-to-day work and that’s bad for the team as well. Both of these are highly replaceable roles.\u003C/p>\n\u003C/li>\n\u003Cli>\n\u003Cp>And finally, we have not moved away from the worker productivity categorisation of industrialisation. Bell curves are common, business wants to keep control and budgets are paramount. I would like to argue that Design never got a seat at the table. The “Design Thinking” hype that got thrown around by IBM, McKinsey, IDEO was for their own PR and has run its due course. Everyone likes an optimistic story but rarely would you find actual organization leaders(CXOs) believing in the value that Design brings to the business and actually investing into Design. That is as true today, as it was a decade ago and hence good fulfilling design jobs are few and far between.\u003C/p>\n\u003Cp>This does not paint a very rosy picture of today’s design industry but after all these years, this is my honest take on the state of affairs. Perhaps we’ve been swayed by all the positive marketing around design, perhaps we’ve believed that design in tech can save the world, but in reality, designers find themselves in a dystopia that they don’t want to acknowledge. The old folks of the industry who have survived, will continue to do so but if you are a beginner, if you want to stick to design in tech, I recommend that you choose a discipline like engineering or product instead and leave your empathy at the door.\u003C/p>\n\u003C/li>\n\u003C/ol>",{"headings":27,"localImagePaths":28,"remoteImagePaths":29,"frontmatter":30,"imagePaths":32},[],[],[],{"title":14,"description":15,"date":31,"image":22},"2024-01-01",[],"design-in-tech-2024/index.md","design-tools-decade",{"id":34,"data":36,"body":41,"filePath":42,"assetImports":43,"digest":49,"rendered":50,"legacyId":59},{"title":37,"description":38,"date":39,"image":40,"status":18},"How far we've come: The last decade of design tools","A lookback at the evolution of design tools from Photoshop to Figma",["Date","2024-01-15T00:00:00.000Z"],"__ASTRO_IMAGE_./lookback-design-tools-1.jpg","Last night, I was thinking about how much the interface design and prototyping landscape has changed in the last decade. I started using Sketch and Marvelapp in 2014 when the predominant tools were Adobe Illustrator/Photoshop/Fireworks for UI, Balsamiq for low fidelity, Axure, Omnigraffle and Keynote for clickable prototypes. Some of these still exist today. While others like Antetype, Invision are no more.\n\nI was taught to design on [Photoshop](https://graphicdesign.stackexchange.com/questions/17928/what-is-the-exact-role-relationship-of-photoshop-in-web-design) at my first job. Even though, modern app stores had released three years earlier, websites was what we were designing back then. The Photoshop art boards we designed, would be ‘sliced’ and used in our HTML/CSS mockups. '[Redlining](https://x.com/teehanlax/status/560820287953195008)' was common practice for dev handovers. For personal projects and at hackathons, new age CSS/JS libraries like [Twitter Bootstrap](https://getbootstrap.com/1.0.0/) started being used. The designs I made back then are horrible and still exist in un-recoverable file formats (Okay, I actually found a photo of [one design](https://photos.app.goo.gl/yx1heXKvGiAFAkNn7)). Back then, I was a developer with an engineering degree working in a MNC IT company so I can’t blame myself for it.\n\n![A wireframe of mine from March 2012 for an event discovery startup idea.](./lookback-design-tools-1.jpg)\n\nWhen I was at Design school, using Adobe Illustrator for its vector capabilities became common place. We worked on information graphics and photoshop just didn't cut it for our workflow. It was largely a skill problem since we had no teachers for our tools, whatever we did was with knowledge from the internet and our peers. Outside in the world, the industry was using tools like Axure, Omnigraffle and Keynote and Teehan+Lax had legendary status in their community for their annual release of their iOS kits.\n\n![Teehan+Lax pictured in their iconic profile photo](./lookback-design-tools-2.jpg)\n\nBy the time we graduated, there had been changes in this ecosystem. Sketch started picking up market share, smart phone penetration was trending up and collaboration became an important buzzword. It was 2014.\n\nBy the time, I started my internship, Material Design had launched and I upgraded from my ancient Sony Viao to a MacBook Air (on EMI). We adopted Sketch and Marvelapp at my workplace.\n\n![My first Marvelapp prototype - June 2014. Created for my Master's submission, still seems to work.](./lookback-design-tools-3.png)\n\nBack then, Sketch files were saved in Google Drive Shared Drives for archival and access across the team. You still needed a license to access proprietary content so we still needed to redline screens and share exports in folders. This lead to tools like Zeplin, Invision and Marvelapp coming in to fill this gap. The next year, Facebook released [Origami](https://engineering.fb.com/2015/02/24/ios/introducing-origami-live/) built on top of Quartz Composer followed by [Framer 1.0](https://medium.com/insightdesign/this-is-how-i-tried-framer-in-8-active-hours-trial-c4a8a0392267) in the next year. That was the start of making prototypes multi-dimensional and letting users “interact” with UI elements and granting access to device hardware sensors like camera. There were [people](https://medium.com/framer-prototyping/making-framer-prototypes-talk-to-each-other-web-sockets-framer-85eedd2243aa) [that I](https://dribbble.com/shots/3699875-Life-Advices-app-Concept/attachments/9971472?mode=media) [knew](https://x.com/vikxlp/status/893453311210250240) making really cool stuff with this.\n\n![An Android date selector prototype I designed on Pixate and got implemented in 2015](./lookback-design-tools-4.png)\n\nNext, Figma and Abstract started up trying to solve the file organization and collaboration problem in their own way; Figma’s USP was that it was browser based and hence could be used by non-mac users so great for budding designers who couldn’t afford a Mac. I didn't use Figma until Jan 2022.\n\nAbstract targeted the existing Sketch user base and tried to introduce branching to the designer audience (albeit unsuccessfully?). [Framer X](https://blog.prototypr.io/framer-x-preview-9d067f35cf9a) built some hype but it didn’t catch on. I had beta access and building out a component system on Framer X(React) needed Dev support which most design teams didn’t have the luxury of. This (circa 2019) is when you started noticing design teams around the world having UX Engineers in their rosters. Design systems evolved out of style guides with the help of UX engineering and now we take design sytems to have both a design and code aspect to them along with voice, tone, illustrations, etc.\n\n![A responsive no-code app I built on Glide to help me expense bills for work travel](./lookback-design-tools-5.png)\n\nThen came the no-code/low-code revolution which simplified the ease of creation further and tools like Glideapps, Bubble and Landbot now make it easy for you to prototype and share ideas. And that brings us to 2024, where we are seeing the rise of AI assisted design and dev tools getting focus. These aren’t there yet but I wish with this we can sunset that beaten to death question of “Should designers code?”","src/content/writing/design-tools-decade/index.md",[44,45,46,47,48],"./lookback-design-tools-1.jpg","./lookback-design-tools-2.jpg","./lookback-design-tools-3.png","./lookback-design-tools-4.png","./lookback-design-tools-5.png","a11d46d7e892ab01",{"html":51,"metadata":52},"\u003Cp>Last night, I was thinking about how much the interface design and prototyping landscape has changed in the last decade. I started using Sketch and Marvelapp in 2014 when the predominant tools were Adobe Illustrator/Photoshop/Fireworks for UI, Balsamiq for low fidelity, Axure, Omnigraffle and Keynote for clickable prototypes. Some of these still exist today. While others like Antetype, Invision are no more.\u003C/p>\n\u003Cp>I was taught to design on \u003Ca href=\"https://graphicdesign.stackexchange.com/questions/17928/what-is-the-exact-role-relationship-of-photoshop-in-web-design\">Photoshop\u003C/a> at my first job. Even though, modern app stores had released three years earlier, websites was what we were designing back then. The Photoshop art boards we designed, would be ‘sliced’ and used in our HTML/CSS mockups. ‘\u003Ca href=\"https://x.com/teehanlax/status/560820287953195008\">Redlining\u003C/a>’ was common practice for dev handovers. For personal projects and at hackathons, new age CSS/JS libraries like \u003Ca href=\"https://getbootstrap.com/1.0.0/\">Twitter Bootstrap\u003C/a> started being used. The designs I made back then are horrible and still exist in un-recoverable file formats (Okay, I actually found a photo of \u003Ca href=\"https://photos.app.goo.gl/yx1heXKvGiAFAkNn7\">one design\u003C/a>). Back then, I was a developer with an engineering degree working in a MNC IT company so I can’t blame myself for it.\u003C/p>\n\u003Cfigure class=\"image-figure\">\u003Cimg __ASTRO_IMAGE_=\"{"src":"./lookback-design-tools-1.jpg","alt":"A wireframe of mine from March 2012 for an event discovery startup idea.","index":0}\">\u003Cfigcaption>A wireframe of mine from March 2012 for an event discovery startup idea.\u003C/figcaption>\u003C/figure>\n\u003Cp>When I was at Design school, using Adobe Illustrator for its vector capabilities became common place. We worked on information graphics and photoshop just didn’t cut it for our workflow. It was largely a skill problem since we had no teachers for our tools, whatever we did was with knowledge from the internet and our peers. Outside in the world, the industry was using tools like Axure, Omnigraffle and Keynote and Teehan+Lax had legendary status in their community for their annual release of their iOS kits.\u003C/p>\n\u003Cfigure class=\"image-figure\">\u003Cimg __ASTRO_IMAGE_=\"{"src":"./lookback-design-tools-2.jpg","alt":"Teehan+Lax pictured in their iconic profile photo","index":0}\">\u003Cfigcaption>Teehan+Lax pictured in their iconic profile photo\u003C/figcaption>\u003C/figure>\n\u003Cp>By the time we graduated, there had been changes in this ecosystem. Sketch started picking up market share, smart phone penetration was trending up and collaboration became an important buzzword. It was 2014.\u003C/p>\n\u003Cp>By the time, I started my internship, Material Design had launched and I upgraded from my ancient Sony Viao to a MacBook Air (on EMI). We adopted Sketch and Marvelapp at my workplace.\u003C/p>\n\u003Cfigure class=\"image-figure\">\u003Cimg __ASTRO_IMAGE_=\"{"src":"./lookback-design-tools-3.png","alt":"My first Marvelapp prototype - June 2014. Created for my Master's submission, still seems to work.","index":0}\">\u003Cfigcaption>My first Marvelapp prototype - June 2014. Created for my Master's submission, still seems to work.\u003C/figcaption>\u003C/figure>\n\u003Cp>Back then, Sketch files were saved in Google Drive Shared Drives for archival and access across the team. You still needed a license to access proprietary content so we still needed to redline screens and share exports in folders. This lead to tools like Zeplin, Invision and Marvelapp coming in to fill this gap. The next year, Facebook released \u003Ca href=\"https://engineering.fb.com/2015/02/24/ios/introducing-origami-live/\">Origami\u003C/a> built on top of Quartz Composer followed by \u003Ca href=\"https://medium.com/insightdesign/this-is-how-i-tried-framer-in-8-active-hours-trial-c4a8a0392267\">Framer 1.0\u003C/a> in the next year. That was the start of making prototypes multi-dimensional and letting users “interact” with UI elements and granting access to device hardware sensors like camera. There were \u003Ca href=\"https://medium.com/framer-prototyping/making-framer-prototypes-talk-to-each-other-web-sockets-framer-85eedd2243aa\">people\u003C/a> \u003Ca href=\"https://dribbble.com/shots/3699875-Life-Advices-app-Concept/attachments/9971472?mode=media\">that I\u003C/a> \u003Ca href=\"https://x.com/vikxlp/status/893453311210250240\">knew\u003C/a> making really cool stuff with this.\u003C/p>\n\u003Cfigure class=\"image-figure\">\u003Cimg __ASTRO_IMAGE_=\"{"src":"./lookback-design-tools-4.png","alt":"An Android date selector prototype I designed on Pixate and got implemented in 2015","index":0}\">\u003Cfigcaption>An Android date selector prototype I designed on Pixate and got implemented in 2015\u003C/figcaption>\u003C/figure>\n\u003Cp>Next, Figma and Abstract started up trying to solve the file organization and collaboration problem in their own way; Figma’s USP was that it was browser based and hence could be used by non-mac users so great for budding designers who couldn’t afford a Mac. I didn’t use Figma until Jan 2022.\u003C/p>\n\u003Cp>Abstract targeted the existing Sketch user base and tried to introduce branching to the designer audience (albeit unsuccessfully?). \u003Ca href=\"https://blog.prototypr.io/framer-x-preview-9d067f35cf9a\">Framer X\u003C/a> built some hype but it didn’t catch on. I had beta access and building out a component system on Framer X(React) needed Dev support which most design teams didn’t have the luxury of. This (circa 2019) is when you started noticing design teams around the world having UX Engineers in their rosters. Design systems evolved out of style guides with the help of UX engineering and now we take design sytems to have both a design and code aspect to them along with voice, tone, illustrations, etc.\u003C/p>\n\u003Cfigure class=\"image-figure\">\u003Cimg __ASTRO_IMAGE_=\"{"src":"./lookback-design-tools-5.png","alt":"A responsive no-code app I built on Glide to help me expense bills for work travel","index":0}\">\u003Cfigcaption>A responsive no-code app I built on Glide to help me expense bills for work travel\u003C/figcaption>\u003C/figure>\n\u003Cp>Then came the no-code/low-code revolution which simplified the ease of creation further and tools like Glideapps, Bubble and Landbot now make it easy for you to prototype and share ideas. And that brings us to 2024, where we are seeing the rise of AI assisted design and dev tools getting focus. These aren’t there yet but I wish with this we can sunset that beaten to death question of “Should designers code?”\u003C/p>",{"headings":53,"localImagePaths":54,"remoteImagePaths":55,"frontmatter":56,"imagePaths":58},[],[44,45,46,47,48],[],{"title":37,"description":38,"date":57,"image":44},"2024-01-15",[44,45,46,47,48],"design-tools-decade/index.md","hiring",{"id":60,"data":62,"body":67,"filePath":68,"assetImports":69,"digest":71,"rendered":72,"legacyId":81},{"title":63,"description":64,"date":65,"image":66,"status":18},"Thoughts on Hiring","Best practices for hiring designers based on my experiences hiring over the last 6 years",["Date","2021-08-19T00:00:00.000Z"],"__ASTRO_IMAGE_./design-keliling.jpg","> \"For every open job on your team, you need to spend one hour a day on recruiting-related activities. Cap that investment at 50% of your time.\"\n>\n> –– [Rands](https://randsinrepose.com/archives/how-to-recruit/)\n\nI strongly believe that hiring is a critical focus area for a design leader. I've been part of hiring panels since 2015. I've seen companies usually do not focus on hiring flows leading them to have a bad experience for interviewing candidates.\n\nI gave a short talk about hiring designers at a friend's startup in 2018 which could be drilled down into the following key points.\n\n1. **Write good job descriptions:**\n The industry is filled with nonsense JDs ~written~ copy-pasted by HRs. If you need to stand out, you need to write a good JD.\n Hire a design consultant to help you out with this if you are hiring the first designer for your startup.\n2. **Don't let a portfolio be a barrier for applying:**\n For entry level roles, I feel a portfolio acts like your resume but when you start hiring for senior designer roles you may want to broaden the application criteria.\n Most designers I know do not have an updated portfolio and this prevents them from applying to your startup if they are interested.\n3. **Customize application form to allow folks to upload a digital document:**\n The tool you use to run your hiring needs to be flexible to cater to your design hiring needs. \n At Gojek, we used Lever and for the longest time we did not have a way for designer applicants to upload a pdf portfolio.\n Binoy and I sat and figured out how to add it to the application form, however for internal referrals we were not able to enable it as Lever doesnt let you customize the form.\n4. **Keep the face-to-face rounds short:**\n In the interest of everyone's time, its best if you can earmark a particular day of the week for interviews and schedule all the rounds on that day for candidates.\n For this to work, your screening rounds need to be well designed so as to not overload your panelists.\n5. **Scaling the process:**\n If you have a lot of reqs to fill, you will need to get others to take part in the interview process.\n Playbooks and evaluation templates help scale the process while maintaining quality.\n \n\u003Cp class=\"attribution\"> Cover image: Taken at the end of the Bandung edition of \u003Ca href=\"https://www.linkedin.com/posts/trinugraha_gojekdesainkeliling-activity-6594891829370556416--yhf\">Gojek Desain Keliling\u003C/a>, Gojek's attempt to recruit designers in a sort of reality contest where winners would get golden tickets\n and a chance to be a part of the Gojek design team.\u003C/p>","src/content/writing/hiring/index.md",[70],"./design-keliling.jpg","16472590845e8714",{"html":73,"metadata":74},"\u003Cblockquote>\n\u003Cp>“For every open job on your team, you need to spend one hour a day on recruiting-related activities. Cap that investment at 50% of your time.”\u003C/p>\n\u003Cp>–– \u003Ca href=\"https://randsinrepose.com/archives/how-to-recruit/\">Rands\u003C/a>\u003C/p>\n\u003C/blockquote>\n\u003Cp>I strongly believe that hiring is a critical focus area for a design leader. I’ve been part of hiring panels since 2015. I’ve seen companies usually do not focus on hiring flows leading them to have a bad experience for interviewing candidates.\u003C/p>\n\u003Cp>I gave a short talk about hiring designers at a friend’s startup in 2018 which could be drilled down into the following key points.\u003C/p>\n\u003Col>\n\u003Cli>\u003Cstrong>Write good job descriptions:\u003C/strong>\nThe industry is filled with nonsense JDs \u003Cdel>written\u003C/del> copy-pasted by HRs. If you need to stand out, you need to write a good JD.\nHire a design consultant to help you out with this if you are hiring the first designer for your startup.\u003C/li>\n\u003Cli>\u003Cstrong>Don’t let a portfolio be a barrier for applying:\u003C/strong>\nFor entry level roles, I feel a portfolio acts like your resume but when you start hiring for senior designer roles you may want to broaden the application criteria.\nMost designers I know do not have an updated portfolio and this prevents them from applying to your startup if they are interested.\u003C/li>\n\u003Cli>\u003Cstrong>Customize application form to allow folks to upload a digital document:\u003C/strong>\nThe tool you use to run your hiring needs to be flexible to cater to your design hiring needs.\nAt Gojek, we used Lever and for the longest time we did not have a way for designer applicants to upload a pdf portfolio.\nBinoy and I sat and figured out how to add it to the application form, however for internal referrals we were not able to enable it as Lever doesnt let you customize the form.\u003C/li>\n\u003Cli>\u003Cstrong>Keep the face-to-face rounds short:\u003C/strong>\nIn the interest of everyone’s time, its best if you can earmark a particular day of the week for interviews and schedule all the rounds on that day for candidates.\nFor this to work, your screening rounds need to be well designed so as to not overload your panelists.\u003C/li>\n\u003Cli>\u003Cstrong>Scaling the process:\u003C/strong>\nIf you have a lot of reqs to fill, you will need to get others to take part in the interview process.\nPlaybooks and evaluation templates help scale the process while maintaining quality.\u003C/li>\n\u003C/ol>\n\u003Cp class=\"attribution\"> Cover image: Taken at the end of the Bandung edition of \u003Ca href=\"https://www.linkedin.com/posts/trinugraha_gojekdesainkeliling-activity-6594891829370556416--yhf\">Gojek Desain Keliling\u003C/a>, Gojek's attempt to recruit designers in a sort of reality contest where winners would get golden tickets\n and a chance to be a part of the Gojek design team.\u003C/p>",{"headings":75,"localImagePaths":76,"remoteImagePaths":77,"frontmatter":78,"imagePaths":80},[],[],[],{"title":63,"description":64,"date":79,"image":70},"2021-08-19",[],"hiring/index.md","product-designer",{"id":82,"data":84,"body":89,"filePath":90,"assetImports":91,"digest":95,"rendered":96,"legacyId":125},{"title":85,"description":86,"date":87,"image":88,"status":18},"What is a product designer?","After a decade of designing products, I decided to make an attempt describing the role and qualities of a product designer",["Date","2025-01-01T00:00:00.000Z"],"__ASTRO_IMAGE_./squiggle-labels-outline.jpg","A decade ago, the 'product designer' title was being used to refer to designers (and still is) working on physical products. The adoption of using it for software designers got a shot in the arm when [Facebook adopted it](https://qr.ae/pGQdVi) for their designers. Until then UI/UX was the term of choice for folks in the industry and used to indicate a specific job that the designer performed in the team. This was indicative of the shift from the delivery teams working with client requirements (enterprise first) to product teams (rapidly iterating consumer tech) which had to learn and uncover what was the best product they could build. Due to the scarcity of product designers in the space, companies started acquiring design agencies around the world[^1].\n\nThe 'product designer' now had to start looking at what they are designing as a product and not be restricted by your traditional mindset of UI and UX responsibilities. This would mean that they would need to learn about business, uncover user insights, use data analytic tools, have technical understanding, etc to design their product. These aren't skills that come naturally to designers and therein lay the problem. Not every designer wanted to be a “product designer” but it was an aspirational job for designers given the pay packages were miles ahead of what designers were paid in other industries. More and more companies started adopting the term of ‘product designer’ to follow industry trends and attract talent.\n\nBut even then there were few orgs which took design seriously.\n\n![Source: 2014 interview in Dezeen](./product-designer-1.png)[^2]\n\nEven today, most orgs don’t really provide a space for designers to thrive in the product space and even today, there are probably a handful of product designers and product orgs in the world, the rest is mostly good PR.\n\n**And what are the aspects of a product designer that sets them apart from other designers?**\n\n### Quality\n\nThe primary aspect the product designer optimises for is quality of delivery. Quality being subjective makes it hard for the different disciplines to align over what this means. For me, it means that the product designer needs to understand the constraints of business and development to be able to deliver the best outcome possible in the defined timeline. You may want to build that perfect animated transition, but let’s be real, that’s not really a user need most of the time. The product’s usage and success should be the thing driving you towards excelling as a designer.\n\n![](./product-designer-2.jpg)\n\n### Curiosity\n\nJust like Alice, a product designer has to be inquisitive about their users and their behaviour and the systems they inhabit. The ‘product designer’ need to be comfortable looking at dashboards, analyzing events as well as drafting a research plan and talking to users. The best way to level up as a product designer is to learn from what you are building and putting out into the world. And this learning tends to compound as the years go by and helps you take decisions when faced with new design challenges.\n\n### Craft\n\nThe product designer is actually [T-shaped](https://spotify.design/article/finding-your-t-shape-as-a-generalist-designer) despite a lot of folks thinking that they are generalists. So although the industry largely refers to the visual polish as 'craft', I don't feel its restricted to just that. You could be a 'product designer' excelling at copy writing, or a 'product designer' inclined towards the code side. A good team is made of many such designers who can learn from each other. If every designer you hire (or in your team) has a similar skill set to you then there would be limited direction for you to grow in. Some teams out there have chosen to double down on this kind of team building but to me that's building a design specialist team.[^3]\n\n### Agency\n\nThis is a quality which is rare to find. I feel this is because most designers tend to be introverts and love to be comfortable in their “space”. It’s easy to spend time in the world making pixel perfection your entire personality, it’s not easy to go out on a limb and argue for a decision to be made. Unfortunately, agency is what helps you level up the ranks. Agency is what gets you a seat at the table. Another hurdle towards product designers developing agency is that they need to be part of good teams run by design leaders who support and sponsor you and those are really scarce in supply.\n\n### So where do we go from here?\n\n* I see that we need to address this at a system level, today the ‘product design’ comes with a better salary and so for designers to get better pay it’s better to call themselves Product Designers. So things can’t change until the hiring parties don’t get better at their jobs.\n\n* No one designer is the same as the other. Organisations should be cognizant that there are no such thing as generalists and design their career rubrics in a way to suit the different kinds of designers on their team. This helps each designer to grow in their own way within the org.\n\n* Job descriptions could be honest up front of the kind of designer that they are looking for rather than getting ChatGPT to write it. There is no point lying about this, infact it just takes you lot longer to find someone.\n\n\n[^1]: **John Maeda's Design in Tech report 2015, Slide 4** https://www.slideshare.net/slideshow/design-in-tech-report-2015-45858974/45858974\n\n[^2]: **Silicon Valley \"didn't think a designer could build a company\" says Airbnb co-founder Brian Chesky** https://www.dezeen.com/2014/01/28/silicon-valley-didnt-think-a-designer-could-build-a-company-interview-airbnb-co-founder-brian-chesky/\n\n[^3]: **Pablo Stanley, Collection of Random Comics** https://thedesignteam.io/collection-of-random-comics-d66f32ee9c52\n\n\n\u003Cp class=\"attribution\"> This post was my response to Sidu's \u003Ca href=\"https://sidu.in/essays/hiring-product-managers.html\">Hiring Product Managers\u003C/a> and John Allspaw's \u003Ca href=\"https://www.kitchensoap.com/2012/10/25/on-being-a-senior-engineer/\">On being a Senior Engineer\u003C/a>.\u003C/p>\n\u003Cp class=\"attribution\"> Attribution: Cover image courtesy \u003Cstrong>'The Process of Design Squiggle' by Damien Newman, thedesignsquiggle.com\u003C/strong> \u003C/p>","src/content/writing/product-designer/index.md",[92,93,94],"./product-designer-1.png","./product-designer-2.jpg","./squiggle-labels-outline.jpg","595da99918ce871b",{"html":97,"metadata":98},"\u003Cp>A decade ago, the ‘product designer’ title was being used to refer to designers (and still is) working on physical products. The adoption of using it for software designers got a shot in the arm when \u003Ca href=\"https://qr.ae/pGQdVi\">Facebook adopted it\u003C/a> for their designers. Until then UI/UX was the term of choice for folks in the industry and used to indicate a specific job that the designer performed in the team. This was indicative of the shift from the delivery teams working with client requirements (enterprise first) to product teams (rapidly iterating consumer tech) which had to learn and uncover what was the best product they could build. Due to the scarcity of product designers in the space, companies started acquiring design agencies around the world\u003Csup>\u003Ca href=\"#user-content-fn-1\" id=\"user-content-fnref-1\" data-footnote-ref=\"\" aria-describedby=\"footnote-label\">1\u003C/a>\u003C/sup>.\u003C/p>\n\u003Cp>The ‘product designer’ now had to start looking at what they are designing as a product and not be restricted by your traditional mindset of UI and UX responsibilities. This would mean that they would need to learn about business, uncover user insights, use data analytic tools, have technical understanding, etc to design their product. These aren’t skills that come naturally to designers and therein lay the problem. Not every designer wanted to be a “product designer” but it was an aspirational job for designers given the pay packages were miles ahead of what designers were paid in other industries. More and more companies started adopting the term of ‘product designer’ to follow industry trends and attract talent.\u003C/p>\n\u003Cp>But even then there were few orgs which took design seriously.\u003C/p>\n\u003Cfigure class=\"image-figure\">\u003Cimg __ASTRO_IMAGE_=\"{"src":"./product-designer-1.png","alt":"Source: 2014 interview in Dezeen","index":0}\">\u003Cfigcaption>Source: 2014 interview in Dezeen\u003C/figcaption>\u003C/figure>\n\u003Cp>Even today, most orgs don’t really provide a space for designers to thrive in the product space and even today, there are probably a handful of product designers and product orgs in the world, the rest is mostly good PR.\u003C/p>\n\u003Cp>\u003Cstrong>And what are the aspects of a product designer that sets them apart from other designers?\u003C/strong>\u003C/p>\n\u003Ch3 id=\"quality\">Quality\u003C/h3>\n\u003Cp>The primary aspect the product designer optimises for is quality of delivery. Quality being subjective makes it hard for the different disciplines to align over what this means. For me, it means that the product designer needs to understand the constraints of business and development to be able to deliver the best outcome possible in the defined timeline. You may want to build that perfect animated transition, but let’s be real, that’s not really a user need most of the time. The product’s usage and success should be the thing driving you towards excelling as a designer.\u003C/p>\n\u003Cfigure class=\"image-figure\">\u003Cimg __ASTRO_IMAGE_=\"{"src":"./product-designer-2.jpg","alt":"","index":0}\">\u003C/figure>\n\u003Ch3 id=\"curiosity\">Curiosity\u003C/h3>\n\u003Cp>Just like Alice, a product designer has to be inquisitive about their users and their behaviour and the systems they inhabit. The ‘product designer’ need to be comfortable looking at dashboards, analyzing events as well as drafting a research plan and talking to users. The best way to level up as a product designer is to learn from what you are building and putting out into the world. And this learning tends to compound as the years go by and helps you take decisions when faced with new design challenges.\u003C/p>\n\u003Ch3 id=\"craft\">Craft\u003C/h3>\n\u003Cp>The product designer is actually \u003Ca href=\"https://spotify.design/article/finding-your-t-shape-as-a-generalist-designer\">T-shaped\u003C/a> despite a lot of folks thinking that they are generalists. So although the industry largely refers to the visual polish as ‘craft’, I don’t feel its restricted to just that. You could be a ‘product designer’ excelling at copy writing, or a ‘product designer’ inclined towards the code side. A good team is made of many such designers who can learn from each other. If every designer you hire (or in your team) has a similar skill set to you then there would be limited direction for you to grow in. Some teams out there have chosen to double down on this kind of team building but to me that’s building a design specialist team.\u003Csup>\u003Ca href=\"#user-content-fn-3\" id=\"user-content-fnref-3\" data-footnote-ref=\"\" aria-describedby=\"footnote-label\">3\u003C/a>\u003C/sup>\u003C/p>\n\u003Ch3 id=\"agency\">Agency\u003C/h3>\n\u003Cp>This is a quality which is rare to find. I feel this is because most designers tend to be introverts and love to be comfortable in their “space”. It’s easy to spend time in the world making pixel perfection your entire personality, it’s not easy to go out on a limb and argue for a decision to be made. Unfortunately, agency is what helps you level up the ranks. Agency is what gets you a seat at the table. Another hurdle towards product designers developing agency is that they need to be part of good teams run by design leaders who support and sponsor you and those are really scarce in supply.\u003C/p>\n\u003Ch3 id=\"so-where-do-we-go-from-here\">So where do we go from here?\u003C/h3>\n\u003Cul>\n\u003Cli>\n\u003Cp>I see that we need to address this at a system level, today the ‘product design’ comes with a better salary and so for designers to get better pay it’s better to call themselves Product Designers. So things can’t change until the hiring parties don’t get better at their jobs.\u003C/p>\n\u003C/li>\n\u003Cli>\n\u003Cp>No one designer is the same as the other. Organisations should be cognizant that there are no such thing as generalists and design their career rubrics in a way to suit the different kinds of designers on their team. This helps each designer to grow in their own way within the org.\u003C/p>\n\u003C/li>\n\u003Cli>\n\u003Cp>Job descriptions could be honest up front of the kind of designer that they are looking for rather than getting ChatGPT to write it. There is no point lying about this, infact it just takes you lot longer to find someone.\u003C/p>\n\u003C/li>\n\u003C/ul>\n\u003Cp class=\"attribution\"> This post was my response to Sidu's \u003Ca href=\"https://sidu.in/essays/hiring-product-managers.html\">Hiring Product Managers\u003C/a> and John Allspaw's \u003Ca href=\"https://www.kitchensoap.com/2012/10/25/on-being-a-senior-engineer/\">On being a Senior Engineer\u003C/a>.\u003C/p>\n\u003Cp class=\"attribution\"> Attribution: Cover image courtesy \u003Cstrong>'The Process of Design Squiggle' by Damien Newman, thedesignsquiggle.com\u003C/strong> \u003C/p>\n\u003Csection data-footnotes=\"\" class=\"footnotes\">\u003Ch2 class=\"sr-only\" id=\"footnote-label\">Footnotes\u003C/h2>\n\u003Col>\n\u003Cli id=\"user-content-fn-1\">\n\u003Cp>\u003Cstrong>John Maeda’s Design in Tech report 2015, Slide 4\u003C/strong> \u003Ca href=\"https://www.slideshare.net/slideshow/design-in-tech-report-2015-45858974/45858974\">https://www.slideshare.net/slideshow/design-in-tech-report-2015-45858974/45858974\u003C/a> \u003Ca href=\"#user-content-fnref-1\" data-footnote-backref=\"\" aria-label=\"Back to reference 1\" class=\"data-footnote-backref\">↩\u003C/a>\u003C/p>\n\u003C/li>\n\u003Cli id=\"user-content-fn-2\">\n\u003Cp>\u003Cstrong>Silicon Valley “didn’t think a designer could build a company” says Airbnb co-founder Brian Chesky\u003C/strong> \u003Ca href=\"https://www.dezeen.com/2014/01/28/silicon-valley-didnt-think-a-designer-could-build-a-company-interview-airbnb-co-founder-brian-chesky/\">https://www.dezeen.com/2014/01/28/silicon-valley-didnt-think-a-designer-could-build-a-company-interview-airbnb-co-founder-brian-chesky/\u003C/a> \u003Ca href=\"#user-content-fnref-2\" data-footnote-backref=\"\" aria-label=\"Back to reference 2\" class=\"data-footnote-backref\">↩\u003C/a>\u003C/p>\n\u003C/li>\n\u003Cli id=\"user-content-fn-3\">\n\u003Cp>\u003Cstrong>Pablo Stanley, Collection of Random Comics\u003C/strong> \u003Ca href=\"https://thedesignteam.io/collection-of-random-comics-d66f32ee9c52\">https://thedesignteam.io/collection-of-random-comics-d66f32ee9c52\u003C/a> \u003Ca href=\"#user-content-fnref-3\" data-footnote-backref=\"\" aria-label=\"Back to reference 3\" class=\"data-footnote-backref\">↩\u003C/a>\u003C/p>\n\u003C/li>\n\u003C/ol>\n\u003C/section>",{"headings":99,"localImagePaths":120,"remoteImagePaths":121,"frontmatter":122,"imagePaths":124},[100,104,107,110,113,116],{"depth":101,"slug":102,"text":103},3,"quality","Quality",{"depth":101,"slug":105,"text":106},"curiosity","Curiosity",{"depth":101,"slug":108,"text":109},"craft","Craft",{"depth":101,"slug":111,"text":112},"agency","Agency",{"depth":101,"slug":114,"text":115},"so-where-do-we-go-from-here","So where do we go from here?",{"depth":117,"slug":118,"text":119},2,"footnote-label","Footnotes",[92,93],[],{"title":85,"description":86,"date":123,"image":94},"2025-01-01",[92,93],"product-designer/index.md","process",{"id":126,"data":128,"body":133,"filePath":134,"assetImports":135,"digest":137,"rendered":138,"legacyId":156},{"title":129,"description":130,"date":131,"image":132,"status":18},"Beyond building processes at GoMerchant Design Team","Team process and documentation",["Date","2021-08-19T00:00:00.000Z"],"__ASTRO_IMAGE_./process-1.png","A considerable amount of time in 'Year 1' of being a manager has been about setting up artifacts and processes. I was lucky to be part of an organization that had a documentation culture in its DNA. This was partly because we had Program Managers embedded within each team. This meant that Jira, Confluence and Asana were setup and maintained religiously, with weekly feature spec reviews [FSR] and ProdTech meetings to keep these upto date.\n\n#### Setting up Documentation spaces\n\nI find design documentation to be a critical part of the design process. I recommend every designer takes the time to document the project because apart from being a design artifact, that serves as a single point of truth, it also helps them when they have to write their performance reviews, promotion proposals and build their portfolio.\n\nI do not like Google Docs for documentation. Documentation spaces need to be a searchable wiki and ironically Google Docs is poor at providing this. At Practo, we already had Atlassian's Confluence setup when I joined, and at Gojek, Maji setup our Confluence spaces in 2019 and then the two of us started structuring and documenting our knowledge about the product and its processes. I created a design documentation template based on the product feature spec template and advocated for it.\n\nAs for project management, the org moved to using Asana. Adding them here felt forced and an unnecessary addition to our workload. However as our product roadmap was moved into Asana, I devised a process to make design tasks a visible part of the product development process by adding them as subtasks and duplicating them to our design boards for effective tracking. Post every prioritization meeting, I added tasks into the todo list and tagged designers so that they were aware of what's coming up.\n\nHowever, we faced a problem with adoption of these processes. We lacked a program manager dedicated to design and not all designers in the team were able to keep their boards updated. We were able to setup a biweekly cadence with the program management VP, Gifika, to discuss our problems and understand how we can get better at solving them. And what we learned is two things.\n\n1. Add more meetings in the calendar\n2. Be a bad cop\n\n#### More meetings in the calendar\n\nWhen your calendar is already full of meetings, you feel like staying away from setting up any more that will take away whatever little 'time for focus work' that is left in it. But given our problem, this seemed to be the most effective way to get things working.\nOur team was a 3 level hierarchy so each lead now had to setup two additional cadences into their calendar. One was a common stream leads cadence where each stream lead would come prepared to the biweekly meeting with a progress update (which would be posted biweekly to the Asana board) Maji worked on a template for this.\n\nThe other meeting was with their stream where each of their reports could come with a similarly formatted update. This meeting helped stream leads prepare them for the stream leads meeting.\nYou can also make these meetings async if everyone is diligent. The updates were a small part of the biweekly leads meeting.\n\n#### Be a Bad Cop\n\nNot all designers like following process. They may see it as additional work with low ROI or they may just not have enough time. You should take the time to communicate the problems that the process is going to solve and ask them for feedback on the process. Make it feel like they co-own the process. But if this fails, then you should be okay with being \"bad cop\". This would mean that you would need to set Slack reminders, add calendar invites and send DMs if everything fails. This is the way.","src/content/writing/process/index.md",[136],"./process-1.png","91f652859cba28a2",{"html":139,"metadata":140},"\u003Cp>A considerable amount of time in ‘Year 1’ of being a manager has been about setting up artifacts and processes. I was lucky to be part of an organization that had a documentation culture in its DNA. This was partly because we had Program Managers embedded within each team. This meant that Jira, Confluence and Asana were setup and maintained religiously, with weekly feature spec reviews [FSR] and ProdTech meetings to keep these upto date.\u003C/p>\n\u003Ch4 id=\"setting-up-documentation-spaces\">Setting up Documentation spaces\u003C/h4>\n\u003Cp>I find design documentation to be a critical part of the design process. I recommend every designer takes the time to document the project because apart from being a design artifact, that serves as a single point of truth, it also helps them when they have to write their performance reviews, promotion proposals and build their portfolio.\u003C/p>\n\u003Cp>I do not like Google Docs for documentation. Documentation spaces need to be a searchable wiki and ironically Google Docs is poor at providing this. At Practo, we already had Atlassian’s Confluence setup when I joined, and at Gojek, Maji setup our Confluence spaces in 2019 and then the two of us started structuring and documenting our knowledge about the product and its processes. I created a design documentation template based on the product feature spec template and advocated for it.\u003C/p>\n\u003Cp>As for project management, the org moved to using Asana. Adding them here felt forced and an unnecessary addition to our workload. However as our product roadmap was moved into Asana, I devised a process to make design tasks a visible part of the product development process by adding them as subtasks and duplicating them to our design boards for effective tracking. Post every prioritization meeting, I added tasks into the todo list and tagged designers so that they were aware of what’s coming up.\u003C/p>\n\u003Cp>However, we faced a problem with adoption of these processes. We lacked a program manager dedicated to design and not all designers in the team were able to keep their boards updated. We were able to setup a biweekly cadence with the program management VP, Gifika, to discuss our problems and understand how we can get better at solving them. And what we learned is two things.\u003C/p>\n\u003Col>\n\u003Cli>Add more meetings in the calendar\u003C/li>\n\u003Cli>Be a bad cop\u003C/li>\n\u003C/ol>\n\u003Ch4 id=\"more-meetings-in-the-calendar\">More meetings in the calendar\u003C/h4>\n\u003Cp>When your calendar is already full of meetings, you feel like staying away from setting up any more that will take away whatever little ‘time for focus work’ that is left in it. But given our problem, this seemed to be the most effective way to get things working.\nOur team was a 3 level hierarchy so each lead now had to setup two additional cadences into their calendar. One was a common stream leads cadence where each stream lead would come prepared to the biweekly meeting with a progress update (which would be posted biweekly to the Asana board) Maji worked on a template for this.\u003C/p>\n\u003Cp>The other meeting was with their stream where each of their reports could come with a similarly formatted update. This meeting helped stream leads prepare them for the stream leads meeting.\nYou can also make these meetings async if everyone is diligent. The updates were a small part of the biweekly leads meeting.\u003C/p>\n\u003Ch4 id=\"be-a-bad-cop\">Be a Bad Cop\u003C/h4>\n\u003Cp>Not all designers like following process. They may see it as additional work with low ROI or they may just not have enough time. You should take the time to communicate the problems that the process is going to solve and ask them for feedback on the process. Make it feel like they co-own the process. But if this fails, then you should be okay with being “bad cop”. This would mean that you would need to set Slack reminders, add calendar invites and send DMs if everything fails. This is the way.\u003C/p>",{"headings":141,"localImagePaths":152,"remoteImagePaths":153,"frontmatter":154,"imagePaths":155},[142,146,149],{"depth":143,"slug":144,"text":145},4,"setting-up-documentation-spaces","Setting up Documentation spaces",{"depth":143,"slug":147,"text":148},"more-meetings-in-the-calendar","More meetings in the calendar",{"depth":143,"slug":150,"text":151},"be-a-bad-cop","Be a Bad Cop",[],[],{"title":129,"description":130,"date":79,"image":136},[],"process/index.md","solo-designer",{"id":157,"data":159,"body":164,"filePath":165,"assetImports":166,"digest":168,"rendered":169,"legacyId":187},{"title":160,"description":161,"date":162,"image":163,"status":18},"Evaluating that Solo Designer job","What to look for when joining a startup as the solo designer",["Date","2024-02-12T00:00:00.000Z"],"__ASTRO_IMAGE_./solo-designer-jobs-1.png","You often see people stating that they are joining as a solo designer in a Startup and want advice. Them being the solo designer shouldn’t directly impact their effectiveness.\n\nHere’s what I feel matters the most towards their success:\n\n### 1. What is your role?\n\nKnowing why they opened the designer role is important before you take that job. I recommend that you ask the hiring manager this question during your interview rounds and also ask to speak to the critical members in the team you will be joining. I take it that most Founders open a position because they got some feedback from customers or because their investor told them to. They may not be ready to invest in what can make a designer effective in their role.\n\n### 2. Fitting into the team:\n\nThe team would need to adapt to having an in-house designer working with them. The team members would need to understand what the role of the designer is and how they could work with them. They would need to take time to adapt their workflows or create new inclusive processes. All this is hard to do and the designer(especially a junior one) wouldn’t do very well without a sponsor.\n\n### 3. You need a sponsor.\n\nOne of my key learnings has been to choose to work with someone who will be your advocate in the organization. It's the single most important thing to look for during the interview process. The best teams I've observed had CEOs being the design sponsor and their products tend to win at least in terms of product quality (a product's success is more than it's quality, but that's another post) Don't believe me? Well in *Rams*, Dieter Rams states \"If you don't have someone who stands behind you, then you can forget it.\" And cites it as a reason for leaving Braun.\n\nOf course, not every Startup out there succeeds and there's no guarantee that the team you join will survive but its always good to make sure that you enjoy the team you spend there and learn how to become a better designer.\n\nIf you are looking for advice on what you can do as a solo designer to succeed, [this post I wrote after my first year as a designer](https://medium.com/user-experience-design-1/what-every-young-designer-should-know-abb2af79f43e) may be useful.","src/content/writing/solo-designer/index.md",[167],"./solo-designer-jobs-1.png","134f374691447467",{"html":170,"metadata":171},"\u003Cp>You often see people stating that they are joining as a solo designer in a Startup and want advice. Them being the solo designer shouldn’t directly impact their effectiveness.\u003C/p>\n\u003Cp>Here’s what I feel matters the most towards their success:\u003C/p>\n\u003Ch3 id=\"1-what-is-your-role\">1. What is your role?\u003C/h3>\n\u003Cp>Knowing why they opened the designer role is important before you take that job. I recommend that you ask the hiring manager this question during your interview rounds and also ask to speak to the critical members in the team you will be joining. I take it that most Founders open a position because they got some feedback from customers or because their investor told them to. They may not be ready to invest in what can make a designer effective in their role.\u003C/p>\n\u003Ch3 id=\"2-fitting-into-the-team\">2. Fitting into the team:\u003C/h3>\n\u003Cp>The team would need to adapt to having an in-house designer working with them. The team members would need to understand what the role of the designer is and how they could work with them. They would need to take time to adapt their workflows or create new inclusive processes. All this is hard to do and the designer(especially a junior one) wouldn’t do very well without a sponsor.\u003C/p>\n\u003Ch3 id=\"3-you-need-a-sponsor\">3. You need a sponsor.\u003C/h3>\n\u003Cp>One of my key learnings has been to choose to work with someone who will be your advocate in the organization. It’s the single most important thing to look for during the interview process. The best teams I’ve observed had CEOs being the design sponsor and their products tend to win at least in terms of product quality (a product’s success is more than it’s quality, but that’s another post) Don’t believe me? Well in \u003Cem>Rams\u003C/em>, Dieter Rams states “If you don’t have someone who stands behind you, then you can forget it.” And cites it as a reason for leaving Braun.\u003C/p>\n\u003Cp>Of course, not every Startup out there succeeds and there’s no guarantee that the team you join will survive but its always good to make sure that you enjoy the team you spend there and learn how to become a better designer.\u003C/p>\n\u003Cp>If you are looking for advice on what you can do as a solo designer to succeed, \u003Ca href=\"https://medium.com/user-experience-design-1/what-every-young-designer-should-know-abb2af79f43e\">this post I wrote after my first year as a designer\u003C/a> may be useful.\u003C/p>",{"headings":172,"localImagePaths":182,"remoteImagePaths":183,"frontmatter":184,"imagePaths":186},[173,176,179],{"depth":101,"slug":174,"text":175},"1-what-is-your-role","1. What is your role?",{"depth":101,"slug":177,"text":178},"2-fitting-into-the-team","2. Fitting into the team:",{"depth":101,"slug":180,"text":181},"3-you-need-a-sponsor","3. You need a sponsor.",[],[],{"title":160,"description":161,"date":185,"image":167},"2024-02-12",[],"solo-designer/index.md","rituals",{"id":188,"data":190,"body":195,"filePath":196,"assetImports":197,"digest":199,"rendered":200,"legacyId":217},{"title":191,"description":192,"date":193,"image":194,"status":18},"Team rituals and culture of the GoMerchant Design Team","Three meetings that helped us work remote and stay sane during the COVID pandemic",["Date","2021-08-19T00:00:00.000Z"],"__ASTRO_IMAGE_./zoom.png","As the GoMerchant team grew, processes and rituals became very important.\n\n### 1. Design Critiques\nDesign Critiques were the first one we instituted. This was a weekly design and research only session where designers could present their work to other designers.\nThese would be weekly and designers were encouraged to show work in progress. To setup this session as a safe space, leaders were expected to be vulnerable and lead by showing their own work in progress.\n\n### 2. Design Review\nWith a need to showcase our work and drive alignment with non-design stakeholders, we setup a Design Review.\nThe format of the design review was formal compared to our informal design critique. \nWe invited non-design stakeholders to the review so that the feedback we collect could flow back into the design process. This was done weekly if required but usually as per our product development cycle it was bi-weekly.\n\n### 3. Design Standup (for lack of a better term)\nI used to be the only designer on my team based in India, but until the lockdown I did not think about instituting any daily standups.\nI used to frequently travel to Indonesia and everyone else was based in the same office. I felt that was enough.\nBut when the pandemic hit and the designers started being isolated in their houses, Maji and I decided to setup a daily cooler talk. We called it _Design Standup_ but we didn't want it to be a 'standup'.\nWe encouraged folks to talk about their personal life, what they were going through and what they were doing.\nWe played games, drew murals together on digital whiteboards and went down internet rabbit holes. Attendance was never compulsory, you could join in if you felt like it. We always posted the link and created a thread of what we discussed on our channel so that if you missed out, you could still follow what was discussed.\nThis ritual couldn't have been achieved without the team members especially Maji, Lauditta and Aryo driving the conversations.\n\nI wonder if this is replicable or was I lucky to have this wonderful team…","src/content/writing/rituals/index.md",[198],"./zoom.png","1249e6497e2be7b7",{"html":201,"metadata":202},"\u003Cp>As the GoMerchant team grew, processes and rituals became very important.\u003C/p>\n\u003Ch3 id=\"1-design-critiques\">1. Design Critiques\u003C/h3>\n\u003Cp>Design Critiques were the first one we instituted. This was a weekly design and research only session where designers could present their work to other designers.\nThese would be weekly and designers were encouraged to show work in progress. To setup this session as a safe space, leaders were expected to be vulnerable and lead by showing their own work in progress.\u003C/p>\n\u003Ch3 id=\"2-design-review\">2. Design Review\u003C/h3>\n\u003Cp>With a need to showcase our work and drive alignment with non-design stakeholders, we setup a Design Review.\nThe format of the design review was formal compared to our informal design critique.\nWe invited non-design stakeholders to the review so that the feedback we collect could flow back into the design process. This was done weekly if required but usually as per our product development cycle it was bi-weekly.\u003C/p>\n\u003Ch3 id=\"3-design-standup-for-lack-of-a-better-term\">3. Design Standup (for lack of a better term)\u003C/h3>\n\u003Cp>I used to be the only designer on my team based in India, but until the lockdown I did not think about instituting any daily standups.\nI used to frequently travel to Indonesia and everyone else was based in the same office. I felt that was enough.\nBut when the pandemic hit and the designers started being isolated in their houses, Maji and I decided to setup a daily cooler talk. We called it \u003Cem>Design Standup\u003C/em> but we didn’t want it to be a ‘standup’.\nWe encouraged folks to talk about their personal life, what they were going through and what they were doing.\nWe played games, drew murals together on digital whiteboards and went down internet rabbit holes. Attendance was never compulsory, you could join in if you felt like it. We always posted the link and created a thread of what we discussed on our channel so that if you missed out, you could still follow what was discussed.\nThis ritual couldn’t have been achieved without the team members especially Maji, Lauditta and Aryo driving the conversations.\u003C/p>\n\u003Cp>I wonder if this is replicable or was I lucky to have this wonderful team…\u003C/p>",{"headings":203,"localImagePaths":213,"remoteImagePaths":214,"frontmatter":215,"imagePaths":216},[204,207,210],{"depth":101,"slug":205,"text":206},"1-design-critiques","1. Design Critiques",{"depth":101,"slug":208,"text":209},"2-design-review","2. Design Review",{"depth":101,"slug":211,"text":212},"3-design-standup-for-lack-of-a-better-term","3. Design Standup (for lack of a better term)",[],[],{"title":191,"description":192,"date":79,"image":198},[],"rituals/index.md","vibe-coding",{"id":218,"data":220,"body":225,"filePath":226,"assetImports":227,"digest":235,"rendered":236,"legacyId":253},{"title":221,"description":222,"date":223,"image":224,"status":18},"Through the vibe-coding looking glass","or How I stopped procrastinating and started to love vibe-coding",["Date","2025-12-22T00:00:00.000Z"],"__ASTRO_IMAGE_./git25.png","\u003Cdiv class=\"note\">Disclaimer: I had a shortlived career as a front end dev (IE7 era) at TCS when I began my career post-engineering in 2010, so I am familiar with the basics of web development. Hence vibe-coding on web may be slightly easier for me to grok then someone non-technical who is trying it out.\u003C/div>\n\nIn October, when I started off my break, I wanted to explore vibe coding but the choices are overwhelming. Up till then, my exposure to LLMs had been to use ChatGPT to edit blog posts and using Midjourney for creating assets for Meta Ads and VC pitch decks. Attending Razorpay’s Design x AI in November helped me understand the realities of vibe coding and prompting but I needed an extra push.\n\nThat push came in the form of a relative asking me to review their 'Vietnam Travel Itinerary'. They had shared their 'Itinerary as a huge wall of text pasted on Whatsapp. I could figure out a few obvious issues with it but I decided to see if AI can help me review and visualize the issues instead. I felt this would help me communicate the issues easier with my relative.\n\nPlanning holidays and building itineraries is a hobby of mine, so I had tried ChatGPT earlier to help with trip planning but I had found it lacking. It was great at generating rough to-dos for your trip like places to visit, etc which I believe it has adequate training data on and to be fair, it’s great for a normie. However, it fails miserably in many places like recommending good stays and other kinds of specialized interests and I've also observed that it tends to think about planning in terms of a western or american perspective. \n\nSo I started asking ChatGPT to visualize the itinerary on maps and when it created an html artifact, I asked it to iterated on the design and visuals. But there was a lot of back and forth to get something done and often subsequent generations rolled back changes I had made. Below are couple of variations of my iterations, ([left](/vibe-coding/iterations/vietnam_12_day_itinerary_web.html)) from when I started to ([right](/vibe-coding/iterations/Vietnam_12Day_Itinerary.html)) when I decided to get it to make it swiss-inspired.\n\n\u003Cdiv class=\"impact-images\" style=\"display: grid; grid-template-columns: 1fr 1fr; gap: 1rem;\">\n\n![](./chatgpt-v1.png)\n\n![](./chatgpt-final.png)\n\n\u003C/div>\n\nI hit chatGPT's session limit and decided to move it to Claude. That's when it got easier. Claude's execution of my requests were better. You could see an invisible multiplier in place such that a 1x simple prompt gave a [10x output](/vibe-coding/iterations/vietnam_itinerary.html). \n\n![My input was the chatGPT html](./claude-v1.png)\n\nThat piqued my curiousity, I decided to see how far I could go.\n\nI first asked Claude what it would take to \"productivize this\" and it gave me a very detailed product roadmap of everything possible including the kitchen sink. It was overwhelming, but I made me learn that asking Claude for a plan is a good way to source ideas but better to work through the designs in the traditional way of implementation (prototype > iterate, repeat)\n\n![Version 1 of Claude](v1-prototype.png)\n\nIt took me about 40 iterations[^1] to get to a state I was comfortable sharing with friends to get feedback. Claude walked me through the steps of setting up Claude API key and hosting the app on Netlify, something I've never done before. You can check out the project at [Traviti](https://traviti.netlify.app/).\n\n![My last iteration](67.png)\n\n#### Fun fact: \n1. When I moved the html to Claude, it removed the 'Made by ChatGPT' label in the markup. Jealousy?\n2. Claude struggled a lot to add it's own logo into the markup and I had to write the markup in the end.\n\nThis project gave me sort of confidence to build further. The itinerary generator was not what I would have wanted to build, but [Budgie](https://kenneth.dsouza.im/budgie/) was. The time to build Budgie was faster. I now had Claude Pro subscription and quickly hit the weekly limit and had to stop so the v1 of Budgie took a week longer than expected to ship. Update: I shipped an [updated version of Budgie](https://budgie.travel) over the Christmas holidays.\n\n\n![Final version of Budgie](budgie.png)\nThis was before Claude's release of Skills and I tried out using Projects for this. There was no Figma involved, just prompting and reading through CSS classes. There were some parts that I had to step into debug but largely this was coded by Claude.\n\nTowards the end of this project, I moved to Claude Code on web and the experience dramatically improved again. Having Claude as a partner to pair with and write to the same repo was amazing QoL improvement. \n\nAfter Budgie, I felt it was time to stop procrastinating and start working on my portfolio (this site). It had been previously built on Eleventy via Glitch (RIP) but I wanted to test how easy would it be to re-write this. So for this project, I asked Claude Code to review and then rebuild the site in Astro and I also provided designs I made in Figma. Claude was easily able to render it and since then, I've taken to making Figma mockups to move the designs along. \n\nMidway through this, I decided to try Claude code on desktop and found myself lost a couple of times, so I decided to move back to Claude code on web. (I do want to try Claude code on Desktop for a future project where I build from scratch.)\n\nSince then, I've tried my hands at [visualizing my book reading on P5js](https://kenneth.dsouza.im/books-2025/index.html) and tried to clean up [an old D3js assignment](https://kenneth.dsouza.im/visualizing-trains/) from a college module. \n\nHonestly, LLMs have been able to help me overcome the barriers I used to face with hobby side projects and I hope more people get empowered this way.\n\n### Helpful tips if you want to get started\n\n- Starting new chat is the new CTRL+S. I struggled a lot on regular chat conversation. Claude Code however generates a nice summary of the chat when you hit context limit.\n\n- Be ready to make a LOT of iteratons. Designing on Figma and providing images has been generally efficient to get the outcome you want. \n\n- Start with small projects; for me that means static web projects. Identify what it means for you. \n \n- I expect design hiring to have a vibe coding round in the near future. Being able to translate your designs to a real functioning prototype has never been easier and moreover it gives an insight into how the designer solves problems.\n\n- Setup a free Github account and connect Claude to it. This will help with your versioning and the ability to roll back any unexpected changes. I personally prefer Github desktop over terminal and if you are new, I suggest you try that.\n\n\n[^1]: At times, some of Claude's prompts generated multiple iterations so iteration 40 was more like 10 prompts into the conversation.","src/content/writing/vibe-coding/index.md",[228,229,230,231,232,233,234],"./chatgpt-v1.png","./chatgpt-final.png","./claude-v1.png","v1-prototype.png","67.png","budgie.png","./git25.png","f2bc29ccddd31a0f",{"html":237,"metadata":238},"\u003Cdiv class=\"note\">Disclaimer: I had a shortlived career as a front end dev (IE7 era) at TCS when I began my career post-engineering in 2010, so I am familiar with the basics of web development. Hence vibe-coding on web may be slightly easier for me to grok then someone non-technical who is trying it out.\u003C/div>\n\u003Cp>In October, when I started off my break, I wanted to explore vibe coding but the choices are overwhelming. Up till then, my exposure to LLMs had been to use ChatGPT to edit blog posts and using Midjourney for creating assets for Meta Ads and VC pitch decks. Attending Razorpay’s Design x AI in November helped me understand the realities of vibe coding and prompting but I needed an extra push.\u003C/p>\n\u003Cp>That push came in the form of a relative asking me to review their ‘Vietnam Travel Itinerary’. They had shared their ‘Itinerary as a huge wall of text pasted on Whatsapp. I could figure out a few obvious issues with it but I decided to see if AI can help me review and visualize the issues instead. I felt this would help me communicate the issues easier with my relative.\u003C/p>\n\u003Cp>Planning holidays and building itineraries is a hobby of mine, so I had tried ChatGPT earlier to help with trip planning but I had found it lacking. It was great at generating rough to-dos for your trip like places to visit, etc which I believe it has adequate training data on and to be fair, it’s great for a normie. However, it fails miserably in many places like recommending good stays and other kinds of specialized interests and I’ve also observed that it tends to think about planning in terms of a western or american perspective.\u003C/p>\n\u003Cp>So I started asking ChatGPT to visualize the itinerary on maps and when it created an html artifact, I asked it to iterated on the design and visuals. But there was a lot of back and forth to get something done and often subsequent generations rolled back changes I had made. Below are couple of variations of my iterations, (\u003Ca href=\"/vibe-coding/iterations/vietnam_12_day_itinerary_web.html\">left\u003C/a>) from when I started to (\u003Ca href=\"/vibe-coding/iterations/Vietnam_12Day_Itinerary.html\">right\u003C/a>) when I decided to get it to make it swiss-inspired.\u003C/p>\n\u003Cdiv class=\"impact-images\" style=\"display: grid; grid-template-columns: 1fr 1fr; gap: 1rem;\">\n\u003Cfigure class=\"image-figure\">\u003Cimg __ASTRO_IMAGE_=\"{"src":"./chatgpt-v1.png","alt":"","index":0}\">\u003C/figure>\n\u003Cfigure class=\"image-figure\">\u003Cimg __ASTRO_IMAGE_=\"{"src":"./chatgpt-final.png","alt":"","index":0}\">\u003C/figure>\n\u003C/div>\n\u003Cp>I hit chatGPT’s session limit and decided to move it to Claude. That’s when it got easier. Claude’s execution of my requests were better. You could see an invisible multiplier in place such that a 1x simple prompt gave a \u003Ca href=\"/vibe-coding/iterations/vietnam_itinerary.html\">10x output\u003C/a>.\u003C/p>\n\u003Cfigure class=\"image-figure\">\u003Cimg __ASTRO_IMAGE_=\"{"src":"./claude-v1.png","alt":"My input was the chatGPT html","index":0}\">\u003Cfigcaption>My input was the chatGPT html\u003C/figcaption>\u003C/figure>\n\u003Cp>That piqued my curiousity, I decided to see how far I could go.\u003C/p>\n\u003Cp>I first asked Claude what it would take to “productivize this” and it gave me a very detailed product roadmap of everything possible including the kitchen sink. It was overwhelming, but I made me learn that asking Claude for a plan is a good way to source ideas but better to work through the designs in the traditional way of implementation (prototype > iterate, repeat)\u003C/p>\n\u003Cfigure class=\"image-figure\">\u003Cimg __ASTRO_IMAGE_=\"{"src":"v1-prototype.png","alt":"Version 1 of Claude","index":0}\">\u003Cfigcaption>Version 1 of Claude\u003C/figcaption>\u003C/figure>\n\u003Cp>It took me about 40 iterations\u003Csup>\u003Ca href=\"#user-content-fn-1\" id=\"user-content-fnref-1\" data-footnote-ref=\"\" aria-describedby=\"footnote-label\">1\u003C/a>\u003C/sup> to get to a state I was comfortable sharing with friends to get feedback. Claude walked me through the steps of setting up Claude API key and hosting the app on Netlify, something I’ve never done before. You can check out the project at \u003Ca href=\"https://traviti.netlify.app/\">Traviti\u003C/a>.\u003C/p>\n\u003Cfigure class=\"image-figure\">\u003Cimg __ASTRO_IMAGE_=\"{"src":"67.png","alt":"My last iteration","index":0}\">\u003Cfigcaption>My last iteration\u003C/figcaption>\u003C/figure>\n\u003Ch4 id=\"fun-fact\">Fun fact:\u003C/h4>\n\u003Col>\n\u003Cli>When I moved the html to Claude, it removed the ‘Made by ChatGPT’ label in the markup. Jealousy?\u003C/li>\n\u003Cli>Claude struggled a lot to add it’s own logo into the markup and I had to write the markup in the end.\u003C/li>\n\u003C/ol>\n\u003Cp>This project gave me sort of confidence to build further. The itinerary generator was not what I would have wanted to build, but \u003Ca href=\"https://kenneth.dsouza.im/budgie/\">Budgie\u003C/a> was. The time to build Budgie was faster. I now had Claude Pro subscription and quickly hit the weekly limit and had to stop so the v1 of Budgie took a week longer than expected to ship. Update: I shipped an \u003Ca href=\"https://budgie.travel\">updated version of Budgie\u003C/a> over the Christmas holidays.\u003C/p>\n\u003Cfigure class=\"image-figure\">\u003Cimg __ASTRO_IMAGE_=\"{"src":"budgie.png","alt":"Final version of Budgie","index":0}\">\u003Cfigcaption>Final version of Budgie\u003C/figcaption>\u003C/figure>\n\u003Cp>Towards the end of this project, I moved to Claude Code on web and the experience dramatically improved again. Having Claude as a partner to pair with and write to the same repo was amazing QoL improvement.\u003C/p>\n\u003Cp>After Budgie, I felt it was time to stop procrastinating and start working on my portfolio (this site). It had been previously built on Eleventy via Glitch (RIP) but I wanted to test how easy would it be to re-write this. So for this project, I asked Claude Code to review and then rebuild the site in Astro and I also provided designs I made in Figma. Claude was easily able to render it and since then, I’ve taken to making Figma mockups to move the designs along.\u003C/p>\n\u003Cp>Midway through this, I decided to try Claude code on desktop and found myself lost a couple of times, so I decided to move back to Claude code on web. (I do want to try Claude code on Desktop for a future project where I build from scratch.)\u003C/p>\n\u003Cp>Since then, I’ve tried my hands at \u003Ca href=\"https://kenneth.dsouza.im/books-2025/index.html\">visualizing my book reading on P5js\u003C/a> and tried to clean up \u003Ca href=\"https://kenneth.dsouza.im/visualizing-trains/\">an old D3js assignment\u003C/a> from a college module.\u003C/p>\n\u003Cp>Honestly, LLMs have been able to help me overcome the barriers I used to face with hobby side projects and I hope more people get empowered this way.\u003C/p>\n\u003Ch3 id=\"helpful-tips-if-you-want-to-get-started\">Helpful tips if you want to get started\u003C/h3>\n\u003Cul>\n\u003Cli>\n\u003Cp>Starting new chat is the new CTRL+S. I struggled a lot on regular chat conversation. Claude Code however generates a nice summary of the chat when you hit context limit.\u003C/p>\n\u003C/li>\n\u003Cli>\n\u003Cp>Be ready to make a LOT of iteratons. Designing on Figma and providing images has been generally efficient to get the outcome you want.\u003C/p>\n\u003C/li>\n\u003Cli>\n\u003Cp>Start with small projects; for me that means static web projects. Identify what it means for you.\u003C/p>\n\u003C/li>\n\u003Cli>\n\u003Cp>I expect design hiring to have a vibe coding round in the near future. Being able to translate your designs to a real functioning prototype has never been easier and moreover it gives an insight into how the designer solves problems.\u003C/p>\n\u003C/li>\n\u003Cli>\n\u003Cp>Setup a free Github account and connect Claude to it. This will help with your versioning and the ability to roll back any unexpected changes. I personally prefer Github desktop over terminal and if you are new, I suggest you try that.\u003C/p>\n\u003C/li>\n\u003C/ul>\n\u003Csection data-footnotes=\"\" class=\"footnotes\">\u003Ch2 class=\"sr-only\" id=\"footnote-label\">Footnotes\u003C/h2>\n\u003Col>\n\u003Cli id=\"user-content-fn-1\">\n\u003Cp>At times, some of Claude’s prompts generated multiple iterations so iteration 40 was more like 10 prompts into the conversation. \u003Ca href=\"#user-content-fnref-1\" data-footnote-backref=\"\" aria-label=\"Back to reference 1\" class=\"data-footnote-backref\">↩\u003C/a>\u003C/p>\n\u003C/li>\n\u003C/ol>\n\u003C/section>",{"headings":239,"localImagePaths":247,"remoteImagePaths":248,"frontmatter":249,"imagePaths":252},[240,243,246],{"depth":143,"slug":241,"text":242},"fun-fact","Fun fact:",{"depth":101,"slug":244,"text":245},"helpful-tips-if-you-want-to-get-started","Helpful tips if you want to get started",{"depth":117,"slug":118,"text":119},[228,229,230,231,232,233],[],{"title":221,"description":222,"date":250,"status":18,"image":251},["Date","2025-12-22T00:00:00.000Z"],"git25.png",[228,229,230,231,232,233],"vibe-coding/index.md","toko-poster",{"id":254,"data":256,"body":262,"filePath":263,"assetImports":264,"digest":266,"rendered":267,"legacyId":276},{"title":257,"description":258,"date":259,"image":260,"status":261},"Midjourneying through Indonesia","this is a description",["Date","2026-03-02T00:00:00.000Z"],"__ASTRO_IMAGE_","draft","hello","src/content/writing/toko-poster/index.md",[265],"","917943514e073f56",{"html":268,"metadata":269},"\u003Cp>hello\u003C/p>",{"headings":270,"localImagePaths":271,"remoteImagePaths":272,"frontmatter":273,"imagePaths":275},[],[],[],{"title":257,"description":258,"date":274,"status":261,"image":265},["Date","2026-03-02T00:00:00.000Z"],[],"toko-poster/index.md","long-live-design-process",{"id":277,"data":279,"body":284,"filePath":285,"assetImports":286,"digest":290,"rendered":291,"legacyId":301},{"title":280,"description":281,"date":282,"image":283,"status":18},"The design process is dead, long live the design process","I’ve been building with AI for the past few months and I dont think the design process is dead.",["Date","2026-03-02T00:00:00.000Z"],"__ASTRO_IMAGE_./rip-design-process.png","Over the last couple of decades, people have tried to tame and commoditize the design process into a neat package especially in the software startup world.\n\nThis in-turn had led to designer portfolios filled with a [templatic story](https://essays.uxdesign.cc/case-study-factory/) of research, personas, wireframes and final output[^1]. A predictable sequence manufactured (often in retrospect) to appease the hiring manager gods.\n\nThe design process was never about following a linear sequence. It wasn't about the artifacts or the rituals. It was just easy to market it as such.\n\n![The Design Sprint tried to emphasise on the Learn and Repeat Loop, but failed. Image source: Wikipedia](Design_Sprints.png)\n\nThe real design process was about making, testing, failing and learning – all in the quest for a better human centric product. It's far easier to build products and features by targeting \"low hanging fruits\", looking at what the competitors are doing, or favouring your CEO's bias. Much easier than going out to talk to your users, dissect your product’s data and figure out what you really need to build. After all, the cost of bad product decisions is only visible in hindsight, while the cost of user research is visible upfront. \n\nBut when you are building products for users who aren’t like you, there is no replacement for the process. \n\n![Speaking to Farmers to understand their decision making when it comes to selling their harvests](jivalite-ground.png)\n\nAt Jiva.ag, we were building for rural Indonesia. Our users weren’t digital natives but often humans with limited technical literacy. We couldn’t really design products and systems for them sitting in our AC offices. We needed to spend time with them – mapping their world and understanding their ways. We tested with scrappy prototypes, iterating upon and validating ideas until we sat down to build. That’s how we understood how our customers used the internet, how they made decisions, and what mattered to them.\n\nYes, AI can help close the loop faster. But without a process, we would have designed for ourselves and not our users.\n\n\n[^1]: or beautiful dribbble UI or excessive animations that would frustrate the average user\n[^2]: \"Design fixation is a well-documented cognitive bias where a designer becomes stuck on a limited set of ideas, often influenced by prior knowledge, previous solutions, or dominant trends,\" explains design psychology expert Rachel A. Wood. [More here](https://www.livingetc.com/advice/what-is-design-fixation).\n[^3]: Cover image courtesy: [The Double Diamond from the Design Council UK](https://www.designcouncil.org.uk/our-resources/the-double-diamond/)\n[^4]: Design Sprint image: [Courtesy Wikipedia](https://en.wikipedia.org/wiki/Design_sprint).","src/content/writing/long-live-design-process/index.md",[287,288,289],"Design_Sprints.png","jivalite-ground.png","./rip-design-process.png","cbf44d98c7ff9968",{"html":292,"metadata":293},"\u003Cp>Over the last couple of decades, people have tried to tame and commoditize the design process into a neat package especially in the software startup world.\u003C/p>\n\u003Cp>This in-turn had led to designer portfolios filled with a \u003Ca href=\"https://essays.uxdesign.cc/case-study-factory/\">templatic story\u003C/a> of research, personas, wireframes and final output\u003Csup>\u003Ca href=\"#user-content-fn-1\" id=\"user-content-fnref-1\" data-footnote-ref=\"\" aria-describedby=\"footnote-label\">1\u003C/a>\u003C/sup>. A predictable sequence manufactured (often in retrospect) to appease the hiring manager gods.\u003C/p>\n\u003Cp>The design process was never about following a linear sequence. It wasn’t about the artifacts or the rituals. It was just easy to market it as such.\u003C/p>\n\u003Cfigure class=\"image-figure\">\u003Cimg __ASTRO_IMAGE_=\"{"src":"Design_Sprints.png","alt":"The Design Sprint tried to emphasise on the Learn and Repeat Loop, but failed. Image source: Wikipedia","index":0}\">\u003Cfigcaption>The Design Sprint tried to emphasise on the Learn and Repeat Loop, but failed. Image source: Wikipedia\u003C/figcaption>\u003C/figure>\n\u003Cp>The real design process was about making, testing, failing and learning – all in the quest for a better human centric product. It’s far easier to build products and features by targeting “low hanging fruits”, looking at what the competitors are doing, or favouring your CEO’s bias. Much easier than going out to talk to your users, dissect your product’s data and figure out what you really need to build. After all, the cost of bad product decisions is only visible in hindsight, while the cost of user research is visible upfront.\u003C/p>\n\u003Cp>But when you are building products for users who aren’t like you, there is no replacement for the process.\u003C/p>\n\u003Cfigure class=\"image-figure\">\u003Cimg __ASTRO_IMAGE_=\"{"src":"jivalite-ground.png","alt":"Speaking to Farmers to understand their decision making when it comes to selling their harvests","index":0}\">\u003Cfigcaption>Speaking to Farmers to understand their decision making when it comes to selling their harvests\u003C/figcaption>\u003C/figure>\n\u003Cp>At Jiva.ag, we were building for rural Indonesia. Our users weren’t digital natives but often humans with limited technical literacy. We couldn’t really design products and systems for them sitting in our AC offices. We needed to spend time with them – mapping their world and understanding their ways. We tested with scrappy prototypes, iterating upon and validating ideas until we sat down to build. That’s how we understood how our customers used the internet, how they made decisions, and what mattered to them.\u003C/p>\n\u003Cp>Yes, AI can help close the loop faster. But without a process, we would have designed for ourselves and not our users.\u003C/p>\n\u003Csection data-footnotes=\"\" class=\"footnotes\">\u003Ch2 class=\"sr-only\" id=\"footnote-label\">Footnotes\u003C/h2>\n\u003Col>\n\u003Cli id=\"user-content-fn-1\">\n\u003Cp>or beautiful dribbble UI or excessive animations that would frustrate the average user \u003Ca href=\"#user-content-fnref-1\" data-footnote-backref=\"\" aria-label=\"Back to reference 1\" class=\"data-footnote-backref\">↩\u003C/a>\u003C/p>\n\u003C/li>\n\u003C/ol>\n\u003C/section>",{"headings":294,"localImagePaths":296,"remoteImagePaths":297,"frontmatter":298,"imagePaths":300},[295],{"depth":117,"slug":118,"text":119},[287,288],[],{"title":280,"description":281,"date":299,"status":18,"image":289},["Date","2026-03-02T00:00:00.000Z"],[287,288],"long-live-design-process/index.md","hiring-2",{"id":302,"data":304,"body":309,"filePath":310,"assetImports":311,"digest":313,"rendered":314,"legacyId":333},{"title":305,"description":306,"date":307,"image":308,"status":18},"Thoughts on Hiring, part 2","Reflections on hiring based on my experience building the product design team at Jiva",["Date","2025-12-07T00:00:00.000Z"],"__ASTRO_IMAGE_./whiteboard.JPG","There are lot of opinions out there about hiring. [Part 1](https://kenneth.dsouza.im/writing/hiring/) was written in 2020-21, when I was on interview panels for product design and product management. Whereas Part 2 consists of my reflections\nafter being in the role of the hiring manager and co-designing Jiva's hiring process.\n\n### 1. Your hiring process is a reflection of your culture\n\nThe design hiring process isn't standardised. These days you'll see a variety of rounds; visual portfolios, take-home assignments, whiteboarding sessions, etc. The mix you choose isn't random; it's a *reflection* of your organization's culture. You're designing a candidate's very first experience of how your team thinks and works.\n\nDifferent rounds signal different things. Asking for visual designs in a portfolio implies that your product team drives the flows and you need someone with strong visual craft. Take-home assignments (and their subsequent presentation) reveal the candidate's communication skills, which can be especially useful if your team works in a traditional \"siloed\" setup. Collaborative whiteboarding sessions show you how it feels to partner with them day-to-day but usually your organization's designers work solo within their own teams.\n\nNone of these are inherently wrong. But if you are not mindful about your processes you end up unnecessarily making the candidate experience time consuming, anxiety-filled, and worse, you start evaluating candidates for the wrong set of attributes — a costly mistake that almost always leads to failure down the line. \n\u003C!-- (You can read about how we designed our product design hiring process at Jiva here.) -->\n\n\n### 2. Today’s design team needs to be multi-faceted\n\nWhen I first started taking interviews (in 2015), my evaluation criteria naturally leaned toward a certain kind of product designer — usually someone whose strengths mirrored what **I** personally valued. That worked when every designer owned a single product end-to-end. But as the organization grew, this approach started breaking down. Designers now had to work together, share problem spaces, and complement one another's strengths rather than operate in isolation and we hadn't hired for that.\n\nA better approach — and one I wish I had learnt earlier[^1] — is to step back and visualise your team's skillset as a whole. One simple way to do this is by mapping your organization's design competencies onto a rough [spider chart or competency map](https://medium.com/shapingdesign/the-ux-spectrum-cb29f048faf9)[^2] and plotting each designer against it. It doesn’t need to be perfect; the point is to create a shared view of where your team is strong, where it’s weak, and if you’re overly dependent on the skills of a single person. \n\n![UX Spectrum via Jason Mesut's Shaping Design series](https://miro.medium.com/v2/resize:fit:2000/format:webp/1*Vi4kDiI5uLhlXJdztg7lwg.png)\n\nThis kind of visualisation becomes even more valuable when you’re managing multiple teams or products. It gives you clarity on what gaps you’re trying to fill, instead of defaulting to hiring “more of the same.” For example, pairing a highly visual designer with a more analytical one can create a healthier balance, with each designer taking control of the tasks as per their skill sets. \n\nIn other words, what you need to realise is that you are not hiring an individual — you’re shaping the distribution of strengths and weaknesses across your entire design function. \n\n\n### 3. There is no place for ego in the team\n\nIt’s called a design team for a reason. The product the user experiences should feel seamless, not like a patchwork of different personalities, preferences, or stylistic signatures. One of the biggest gaps in a skills-only evaluation is that it completely misses the *collaboration layer* of design: how someone shows up, how they listen, and how they work with others under pressure. \n\nYour spider chart or competency map can show you strengths and weaknesses in craft, but it won't tell you whether a candidate can actually work well with the rest of your organization. That’s where cultural alignment matters. A designer who is stubborn, who refuses to take cross-functional feedback, or insists on “their way” will quickly become a bottleneck — no matter how talented they are. \n\nGetting people who play well together is one of the most underrated aspects of building a high-performing design org. A difficult personality erodes trust, slows down execution, and adds unnecessary emotional weight on everyone else — a mess that you, as the design manager, will spend a lot of time and energy sorting out. \n\nThis is why running a “vibe check” through your existing team — designers, PMs, engineers — can be invaluable. These aren’t popularity tests; they’re ways to sense how someone collaborates in real, messy, day-to-day situations and to check how excited stakeholders are about working with the candidate.\n\nThe goal isn’t to hire the best individual — it’s to hire the person who will make the team stronger.\n\n\n\u003Cp class=\"attribution\"> Cover image: Akshay, Hetang and Riya working on a whiteboard at Practo, 4 April 2017\u003C/p>\n\n[^1]: Derived learning from faculty from Ownpath Manager training in Q1 2020 where we interacted with Kristin Skinner, Alysha Naples, and Meredith Black.\n[^2]: Jason Mesut's Shaping Design series of posts is full of useful toolkits and design management frameworks.","src/content/writing/hiring-2/index.md",[312],"./whiteboard.JPG","b23c68bc14f2b699",{"html":315,"metadata":316},"\u003Cp>There are lot of opinions out there about hiring. \u003Ca href=\"https://kenneth.dsouza.im/writing/hiring/\">Part 1\u003C/a> was written in 2020-21, when I was on interview panels for product design and product management. Whereas Part 2 consists of my reflections\nafter being in the role of the hiring manager and co-designing Jiva’s hiring process.\u003C/p>\n\u003Ch3 id=\"1-your-hiring-process-is-a-reflection-of-your-culture\">1. Your hiring process is a reflection of your culture\u003C/h3>\n\u003Cp>The design hiring process isn’t standardised. These days you’ll see a variety of rounds; visual portfolios, take-home assignments, whiteboarding sessions, etc. The mix you choose isn’t random; it’s a \u003Cem>reflection\u003C/em> of your organization’s culture. You’re designing a candidate’s very first experience of how your team thinks and works.\u003C/p>\n\u003Cp>Different rounds signal different things. Asking for visual designs in a portfolio implies that your product team drives the flows and you need someone with strong visual craft. Take-home assignments (and their subsequent presentation) reveal the candidate’s communication skills, which can be especially useful if your team works in a traditional “siloed” setup. Collaborative whiteboarding sessions show you how it feels to partner with them day-to-day but usually your organization’s designers work solo within their own teams.\u003C/p>\n\u003Cp>None of these are inherently wrong. But if you are not mindful about your processes you end up unnecessarily making the candidate experience time consuming, anxiety-filled, and worse, you start evaluating candidates for the wrong set of attributes — a costly mistake that almost always leads to failure down the line.\u003C/p>\n\u003C!-- (You can read about how we designed our product design hiring process at Jiva here.) -->\n\u003Ch3 id=\"2-todays-design-team-needs-to-be-multi-faceted\">2. Today’s design team needs to be multi-faceted\u003C/h3>\n\u003Cp>When I first started taking interviews (in 2015), my evaluation criteria naturally leaned toward a certain kind of product designer — usually someone whose strengths mirrored what \u003Cstrong>I\u003C/strong> personally valued. That worked when every designer owned a single product end-to-end. But as the organization grew, this approach started breaking down. Designers now had to work together, share problem spaces, and complement one another’s strengths rather than operate in isolation and we hadn’t hired for that.\u003C/p>\n\u003Cp>A better approach — and one I wish I had learnt earlier\u003Csup>\u003Ca href=\"#user-content-fn-1\" id=\"user-content-fnref-1\" data-footnote-ref=\"\" aria-describedby=\"footnote-label\">1\u003C/a>\u003C/sup> — is to step back and visualise your team’s skillset as a whole. One simple way to do this is by mapping your organization’s design competencies onto a rough \u003Ca href=\"https://medium.com/shapingdesign/the-ux-spectrum-cb29f048faf9\">spider chart or competency map\u003C/a>\u003Csup>\u003Ca href=\"#user-content-fn-2\" id=\"user-content-fnref-2\" data-footnote-ref=\"\" aria-describedby=\"footnote-label\">2\u003C/a>\u003C/sup> and plotting each designer against it. It doesn’t need to be perfect; the point is to create a shared view of where your team is strong, where it’s weak, and if you’re overly dependent on the skills of a single person.\u003C/p>\n\u003Cfigure class=\"image-figure\">\u003Cimg src=\"https://miro.medium.com/v2/resize:fit:2000/format:webp/1*Vi4kDiI5uLhlXJdztg7lwg.png\" alt=\"UX Spectrum via Jason Mesut's Shaping Design series\">\u003Cfigcaption>UX Spectrum via Jason Mesut's Shaping Design series\u003C/figcaption>\u003C/figure>\n\u003Cp>This kind of visualisation becomes even more valuable when you’re managing multiple teams or products. It gives you clarity on what gaps you’re trying to fill, instead of defaulting to hiring “more of the same.” For example, pairing a highly visual designer with a more analytical one can create a healthier balance, with each designer taking control of the tasks as per their skill sets.\u003C/p>\n\u003Cp>In other words, what you need to realise is that you are not hiring an individual — you’re shaping the distribution of strengths and weaknesses across your entire design function.\u003C/p>\n\u003Ch3 id=\"3-there-is-no-place-for-ego-in-the-team\">3. There is no place for ego in the team\u003C/h3>\n\u003Cp>It’s called a design team for a reason. The product the user experiences should feel seamless, not like a patchwork of different personalities, preferences, or stylistic signatures. One of the biggest gaps in a skills-only evaluation is that it completely misses the \u003Cem>collaboration layer\u003C/em> of design: how someone shows up, how they listen, and how they work with others under pressure.\u003C/p>\n\u003Cp>Your spider chart or competency map can show you strengths and weaknesses in craft, but it won’t tell you whether a candidate can actually work well with the rest of your organization. That’s where cultural alignment matters. A designer who is stubborn, who refuses to take cross-functional feedback, or insists on “their way” will quickly become a bottleneck — no matter how talented they are.\u003C/p>\n\u003Cp>Getting people who play well together is one of the most underrated aspects of building a high-performing design org. A difficult personality erodes trust, slows down execution, and adds unnecessary emotional weight on everyone else — a mess that you, as the design manager, will spend a lot of time and energy sorting out.\u003C/p>\n\u003Cp>This is why running a “vibe check” through your existing team — designers, PMs, engineers — can be invaluable. These aren’t popularity tests; they’re ways to sense how someone collaborates in real, messy, day-to-day situations and to check how excited stakeholders are about working with the candidate.\u003C/p>\n\u003Cp>The goal isn’t to hire the best individual — it’s to hire the person who will make the team stronger.\u003C/p>\n\u003Cp class=\"attribution\"> Cover image: Akshay, Hetang and Riya working on a whiteboard at Practo, 4 April 2017\u003C/p>\n\u003Csection data-footnotes=\"\" class=\"footnotes\">\u003Ch2 class=\"sr-only\" id=\"footnote-label\">Footnotes\u003C/h2>\n\u003Col>\n\u003Cli id=\"user-content-fn-1\">\n\u003Cp>Derived learning from faculty from Ownpath Manager training in Q1 2020 where we interacted with Kristin Skinner, Alysha Naples, and Meredith Black. \u003Ca href=\"#user-content-fnref-1\" data-footnote-backref=\"\" aria-label=\"Back to reference 1\" class=\"data-footnote-backref\">↩\u003C/a>\u003C/p>\n\u003C/li>\n\u003Cli id=\"user-content-fn-2\">\n\u003Cp>Jason Mesut’s Shaping Design series of posts is full of useful toolkits and design management frameworks. \u003Ca href=\"#user-content-fnref-2\" data-footnote-backref=\"\" aria-label=\"Back to reference 2\" class=\"data-footnote-backref\">↩\u003C/a>\u003C/p>\n\u003C/li>\n\u003C/ol>\n\u003C/section>",{"headings":317,"localImagePaths":328,"remoteImagePaths":329,"frontmatter":330,"imagePaths":332},[318,321,324,327],{"depth":101,"slug":319,"text":320},"1-your-hiring-process-is-a-reflection-of-your-culture","1. Your hiring process is a reflection of your culture",{"depth":101,"slug":322,"text":323},"2-todays-design-team-needs-to-be-multi-faceted","2. Today’s design team needs to be multi-faceted",{"depth":101,"slug":325,"text":326},"3-there-is-no-place-for-ego-in-the-team","3. There is no place for ego in the team",{"depth":117,"slug":118,"text":119},[],[],{"title":305,"description":306,"date":331,"status":18,"image":312},"2025-12-07",[],"hiring-2/index.md","templates",["Map",336,337,352,353],"template-work",{"id":336,"data":338,"body":262,"filePath":343,"digest":344,"rendered":345,"legacyId":351},{"title":339,"description":258,"year":340,"company":341,"status":261,"image":342},"this is a title","this is where you will add year","this is the company",null,"src/content/templates/template-work/index.md","aec162d71437f1b5",{"html":268,"metadata":346},{"headings":347,"localImagePaths":348,"remoteImagePaths":349,"frontmatter":338,"imagePaths":350},[],[],[],[],"template-work/index.md","template-writing",{"id":352,"data":354,"body":262,"filePath":356,"digest":357,"rendered":358,"legacyId":364},{"title":339,"description":258,"date":355,"status":261,"image":342},"this is where you will add date","src/content/templates/template-writing/index.md","d1bb62b3c359fedd",{"html":268,"metadata":359},{"headings":360,"localImagePaths":361,"remoteImagePaths":362,"frontmatter":354,"imagePaths":363},[],[],[],[],"template-writing/index.md","work",["Map",367,368,442,443,475,476,515,516,549,550,595,596,684,685,714,715,738,739],"akar-design-system",{"id":367,"data":369,"body":375,"filePath":376,"assetImports":377,"digest":386,"rendered":387,"legacyId":441},{"title":370,"description":371,"image":372,"year":373,"company":374,"status":18},"Building the Akar Design System","The philosophy and design principles behind Jiva’s scalable design system","__ASTRO_IMAGE_./akar.webp","2023-2024","Jiva","Design systems often represent an aspirational milestone for product design teams. But they’re often seen as an all-or-nothing project — something that takes months of planning and effort, \nwhile day-to-day product delivery suffers. When everything is moving at breakneck speed, it feels risky to divert resources into building a design system. \n**But is it really?**\n\nIn early 2022, Jiva was deep in the throes of hyper-growth, onboarding new team members almost every week. The chaos hit every part of the company, and the design team wasn’t immune. \nWork was being duplicated across pods, our user experience was inconsistent, accessibility needs were being overlooked, and our app’s \nperformance was lagging behind.\nAt the time, we had a Figma-style guide, but it simply wasn’t enough. We needed more than a set of visual guidelines — we needed a \ncomprehensive design system that could help us keep up with the rapid growth without adding friction to the process. And yet, we faced a tough constraint: \nour design team was tiny (and growing), so we had to approach this in a _lean_ way.\n\n![A snapshot of our Figma Component Library Circa early 2022](styleguide.webp)\n\n\n## Role\nI led the effort on the design system and my responsibilities included managing with various stakeholders(product, engineering, qa), pitching ideas, \ndefining the design system tokens, identifying the right tools and libraries. Post implementation, my focus was towards evangelizing the design system, getting buyin for implementing it onto the various product roadmaps and \ntracking its usage within products.\n\n## Challenge\n\nWe set out with a clear set of goals for the design system:\n\n### Goals\n\n- **Scalability** \nLay a foundation that would allow Jiva to scale across platforms and countries.\n\n- **Speed** \nRemove friction in day-to-day work so designers could focus on designing, while product managers and developers knew exactly which components to use.\n\n- **Output quality** \nImprove the handoff process so what was designed could be built accurately.\n\n- **Accessibility** \nBring typography and color usage in line with minimum WCAG guidelines.\n\n- **Standardization** \nCreate a coherent, consistent feel across all our products, reinforcing a sense of trust and legitimacy.\n\n### Impact on our customers\n\n- **Familiarity** \nFamiliar patterns across products, reducing the learning curve.\n\n- **Readability** \nImproved readability for older MCs, with better support for built-in phone accessibility features.\n\n- **Performance** \nFaster, lighter apps through reduced duplication and a smaller overall app size.\n\n## Getting started\n\nIt's easy to write down what we wanted to achieve with our design system but we had 0 experience designing one. \n\nWe started by studying how well-known design systems such as Material Design, Shopify's Polaris, and Uber's Base were structured. \nWe analyzed their token structures, naming conventions, and the rationale behind their choices. We watched talks, talked to peers, read blog posts and then we got started.\n\n### Design Tokens\n\nDesign tokens represent the small, repeated design decisions that make up a design system's visual style. They replace static values, such as hex codes for color, with self-explanatory names. A token's value can be one of several things: a color, a typeface, a measurement, or even another token. \n\n![The way we envisioned our lean system to work inspired from Spotify’s Encore](design-system-philosophy.webp) [^1]\n\nWe chose **colour** and **typography** as tokens in our system. We chose only these tokens because they gave the team the autonomy to move fast while giving us the flexibility to maintain consistency where it mattered.\nAll without locking us into a rigid design expression. These tokens could be used to create design “atoms” and “molecules” across different platforms, allowing our \ncomponents to adapt naturally to each platform’s native constraints.\nThis flexibility was crucial. It allowed teams to move faster, design for different use cases, and scale without sacrificing brand coherence.\n\n>For example, in 2024, when we built react native apps by adopting [Paper](https://reactnativepaper.com/), our tokens could easily be ported to make Paper-based apps feel like a Jiva product. \n>In tools like Retool, we only ported over colour tokens because that’s all we needed to ensure visual consistency. \n>This token-driven flexibility became the key to scaling design without getting bogged down by unnecessary rigidity like uniformity of components.\n \n#### Typography\n\n![Old type vs New type](type.webp)\n\nFor Typography, we decided to lean on system defaults. On Android, by switching from [Mr. Eaves](https://fonts.adobe.com/fonts/mr-eaves-xl)(our brand font) to Roboto, we addressed the legibility issues we had previously\nfaced, particularly on budget Android devices. However, this wasn’t \na simple swap. We had to design a type scale that ensured our transition was seamless and consistent across various text elements, from headings to body text.\nfor this was taking several key UI screens and replacing text to see how we could map the new type styles to the old ones with minimal effect to the UI.\n\n#### Color\n\n![](color.webp)\n\nColour, on the other hand, posed a unique challenge. Our original primary colour (#0AB858), vibrant as it was, didn’t meet [WCAG](https://www.w3.org/WAI/standards-guidelines/wcag/) contrast requirements, especially for text on white or green backgrounds in smaller font sizes. We knew this was a dealbreaker for accessibility.\nAchieving the right contrast was tough — white on green rarely provides the necessary legibility, particularly on low-resolution displays. Finally with the help of \nEnvoy’s post on [building an accessible colour scheme](https://medium.com/envoy-design/how-to-design-an-accessible-color-scheme-4a13ca12c92b), [Stark’s handy plugin](https://www.figma.com/community/plugin/732603254453395948/stark-contrast-accessibility-checker) and [Tailwind Color Generator plugin](https://www.figma.com/community/plugin/1242548152689430610/tailwind-css-color-generator), we found a modified shade of green(#006E25) \nthat worked visually and was AA compliant. But colour wasn’t just about picking a new shade; \nwe also had to write detailed guidelines for how and where it should be used to maintain consistency and accessibility across our products.\n\n\n### Bringing it all together\nM3 [(Material Design 3)](https://m3.material.io) had just released and we loved the fresh new style it brought with it. Material Design is built around a ‘primary’ color making it easy for \npeople(read: devs) to adopt it. They provide you a [figma plugin](https://www.figma.com/community/plugin/1034969338659738588/material-theme-builder) to generate your color tokens but it lacks customization and is overly technical. \n\nMoreover, the way these tokens styled the components felt awkward to us. It did not fit our brand. So we decided to take control and create our own token system which we would map to these components.\n\nDuring further research, we learned that there's no standardization of naming conventions across companies—each has its own needs and preferences. This situation challenged us, as we're new to design tokens and struggled to decide which approach we can go ahead with. It was only when we watched [this talk from Schema 2021](https://www.youtube.com/watch?v=ylDed18OVdY) titled *\"Design tokens at Asana\"* by Jina Anne, \nAinsley Wagoner, and Ivy Wang that the solution finally dawned on us.\n\n>Color tokens need to be comprehensive enough to clearly describe their usage, yet concise enough to make it easy to determine which tokens to apply.\n\nWe took the ideas from the talk and aimed to create tokens that are direct and self-explanatory. Our goal was to make them easily understandable by all and avoid designers needing to refer back to documentation to use the system. \n\nAfter a lot of discussions, we implemented the following structure structure designed for clarity and ease of use. It wasn't perfect, but it worked with a little bit of documentation better than Material Design's approach.\n![Naming convention of Akar](naming.webp)\n1. \u003Cins>Property\u003C/ins> We start with what we call ‘property’, thus called because it defines what kind of element it is applied to; content, background or border. So for a primary button below, the color token for the text uses the content property while the colour of the button is represented by the background property.\n2. \u003Cins>Roles\u003C/ins> The ‘role’ aspect is where you start to identify the kind of component you are attempting to style. We use ‘Action’ for components that need the user to ‘act’ on them while ‘Highlight’ and ‘Interactive’ are used for communicating a system reaction to the user. We have ‘default’ for neutral colours and ‘decorative’ was introduced at a later point for components like badges and tags that needed to be visually appealing.\n3. \u003Cins>Priority\u003C/ins> Priority is used to optimize the visual hierarchy within the user interface, ensuring that the most important elements stand out and draw the user’s attention. By assigning different priority levels to components, we can guide users through the interface more intuitively, highlighting key actions, content, or information and making the overall experience more seamless and efficient.\n4. \u003Cins>Type\u003C/ins> Type is used to express the tone or meaning of an element, such as information, success, warning, error, or neutrality. These types are applied to components like buttons, banners, and toasts, as well as to elements like icons and text.\n5. \u003Cins>States\u003C/ins> States are visual indicators that communicate the current status or condition of a component or interactive element. They help users understand how an element is behaving at any given moment, such as whether it’s pressed, loading, selected, focused, or disabled.\n\n![How designers can use our tokens](how-to-tokens.webp)\n\n### The Final stretch\nIf your design system exists only in Figma, then its just a style guide. For a design system to be truly complete, it needs to exists outside of Figma and as a code library.\n\nWe were re-writing our Android Front end in Jetpack Compose and decided to merge the two efforts to implement our design system. \nWhile having self-explanatory token naming certainly makes designers' lives easier, by taking this direction of deviating from Material Design's conventions, we increased our developement effort. \nWe had to build a bridge to make our tokens compatible with material design. This wasn’t straightforward. Most big companies that we studied had UX engineering teams to help build such plugins for their use. \nWe came across [Amazon’s style dictionary](https://github.com/style-dictionary/style-dictionary) from [this talk by Doordash](https://www.youtube.com/watch?v=jgueTz72ZMQ&t=760s) and Atlassian’s inhouse plugin in [their schema talk](https://www.youtube.com/watch?v=m8ZSu9eCsQc&t=814s) \nand the popular figma plugin [Tokens Studio](https://tokens.studio). \n\n>So why did we still proceed with this approach? We prioritized ease of use, recognizing that the development work to implement this system is a one-time investment. \n>We believed that it was a worthwhile trade-off.\n\nIt wasn’t really all that straightforward. We were only able to make it work by closely working with our developers(Sivan and Vishnu).\n\n#### Our Approach\nWe used Tokens Studio to export our tokens from Figma as JSON and the devs had to figure out how to translate this to a setup that can be consumed by our apps. \nThe aim was to make sure that the designers had the freedom to take decisions while the devs wouldn’t have to break a sweat in integrating them into the apps.\n\nOur apps are on the Jetpack Compose framework and this meant that the design language and consumption were slightly different from Android’s traditional XML. \nWe found [Lukas Opperman’s Design Token Transformer](https://github.com/lukasoppermann/design-token-transformer) to be a great tool for porting tokens to Web, \niOS and Android’s XML system but we needed something that would support Jetpack Compose as well. So we forked this repo and decided to add support for Jetpack Compose. \nThe overall idea was straightforward. The engine should take in the \nJSON file as the input, and spit out Compose Theming files that can be imported onto your project directly and the devs wouldn’t have to worry too much about the setup.\n\n\u003Cimg src=\"/images/tokens-figma.gif\" alt=\"Tokens in Figma\" style=\"border-radius: 8px;\" />\n\nAnd that’s how we placed the final piece of our design system jigsaw puzzle.\n\n\n## Presenting the Akar Design Sytem: \nAll this while, we had been working hard on the system but we realised we didn’t have a name for our design system. We wanted something that resonated with the agritech space we were in, so we began brainstorming. Finally, with the help of Notion AI, we chose to go with Akar.\n\nAkar, derived from the Bahasa Indonesia word for ‘root,’ perfectly reflects the role of our design system in providing a solid foundation for building products. It’s also symbolic, as Indonesia is where our products first took shape, making the name a meaningful nod to our origins.\n\n![Akar on our screens](akar-screens.webp)\n\n### Post-launch\nA design system's success is measure by its penetration and implementation by the team. Building it in isolation is bound to fail. Throughout the process, we spent time\ninvolving the dev and design teams. We did this by \n- We created Slack channels to communicate updates and invite collaboration. \n- We presented the system at an org-wide ‘Lunch and Learn’ (an org level initiative to talk about work) to bring awareness to the initiative.\n- To track adoption, we created pod-specific slack channels for devs and designers to have discussions around implementation and we set up a Notion page to track migration and adoption.\n- We created a [documentation site](https://zeroheight.com/5c1eb1bd5/p/73e674-akar-design-system) which devs and designers could refer to. \n\n## Impact\n\nHaving Akar, helped us scale faster and build and redesign new apps and products in the Jiva ecosystem. As of September 2025, it was used across various platforms and products at Jiva, \nsupporting our 3 core Android mobile apps (Sahabat Jiva, Jiva Petani, Jiva Agro). We also extended our tokens to be used in our internal React Native apps (Jiva Sales, Field Agent App), as well as internal tools built using Retool.\n\nImplementation of the code components was a slow process as getting it prioritised over business needs was hard. \nWe were able to get like 80% of the product verticals to completely use our libarary within the first 12 months. \n\n## Team\nTyo (who had just joined the team) worked with me and built out the Figma token and components system. Nav, (head of design), helped us take decisions\naround the direction of the design components. Sivan and VIshnu were the devs who we collaborated closely to get the code components out in production. \n\n[^1]: **Spotify's Encore** https://spotify.design/article/can-i-get-an-encore-spotifys-design-system-three-years-on","src/content/work/akar-design-system/index.md",[378,379,380,381,382,383,384,385],"styleguide.webp","design-system-philosophy.webp","type.webp","color.webp","naming.webp","how-to-tokens.webp","akar-screens.webp","./akar.webp","bde199fee499ec2f",{"html":388,"metadata":389},"\u003Cp>Design systems often represent an aspirational milestone for product design teams. But they’re often seen as an all-or-nothing project — something that takes months of planning and effort,\nwhile day-to-day product delivery suffers. When everything is moving at breakneck speed, it feels risky to divert resources into building a design system.\n\u003Cstrong>But is it really?\u003C/strong>\u003C/p>\n\u003Cp>In early 2022, Jiva was deep in the throes of hyper-growth, onboarding new team members almost every week. The chaos hit every part of the company, and the design team wasn’t immune.\nWork was being duplicated across pods, our user experience was inconsistent, accessibility needs were being overlooked, and our app’s\nperformance was lagging behind.\nAt the time, we had a Figma-style guide, but it simply wasn’t enough. We needed more than a set of visual guidelines — we needed a\ncomprehensive design system that could help us keep up with the rapid growth without adding friction to the process. And yet, we faced a tough constraint:\nour design team was tiny (and growing), so we had to approach this in a \u003Cem>lean\u003C/em> way.\u003C/p>\n\u003Cfigure class=\"image-figure\">\u003Cimg __ASTRO_IMAGE_=\"{"src":"styleguide.webp","alt":"A snapshot of our Figma Component Library Circa early 2022","index":0}\">\u003Cfigcaption>A snapshot of our Figma Component Library Circa early 2022\u003C/figcaption>\u003C/figure>\n\u003Ch2 id=\"role\">Role\u003C/h2>\n\u003Cp>I led the effort on the design system and my responsibilities included managing with various stakeholders(product, engineering, qa), pitching ideas,\ndefining the design system tokens, identifying the right tools and libraries. Post implementation, my focus was towards evangelizing the design system, getting buyin for implementing it onto the various product roadmaps and\ntracking its usage within products.\u003C/p>\n\u003Ch2 id=\"challenge\">Challenge\u003C/h2>\n\u003Cp>We set out with a clear set of goals for the design system:\u003C/p>\n\u003Ch3 id=\"goals\">Goals\u003C/h3>\n\u003Cul>\n\u003Cli>\n\u003Cp>\u003Cstrong>Scalability\u003C/strong>\u003Cbr>\nLay a foundation that would allow Jiva to scale across platforms and countries.\u003C/p>\n\u003C/li>\n\u003Cli>\n\u003Cp>\u003Cstrong>Speed\u003C/strong>\u003Cbr>\nRemove friction in day-to-day work so designers could focus on designing, while product managers and developers knew exactly which components to use.\u003C/p>\n\u003C/li>\n\u003Cli>\n\u003Cp>\u003Cstrong>Output quality\u003C/strong>\u003Cbr>\nImprove the handoff process so what was designed could be built accurately.\u003C/p>\n\u003C/li>\n\u003Cli>\n\u003Cp>\u003Cstrong>Accessibility\u003C/strong>\u003Cbr>\nBring typography and color usage in line with minimum WCAG guidelines.\u003C/p>\n\u003C/li>\n\u003Cli>\n\u003Cp>\u003Cstrong>Standardization\u003C/strong>\u003Cbr>\nCreate a coherent, consistent feel across all our products, reinforcing a sense of trust and legitimacy.\u003C/p>\n\u003C/li>\n\u003C/ul>\n\u003Ch3 id=\"impact-on-our-customers\">Impact on our customers\u003C/h3>\n\u003Cul>\n\u003Cli>\n\u003Cp>\u003Cstrong>Familiarity\u003C/strong>\u003Cbr>\nFamiliar patterns across products, reducing the learning curve.\u003C/p>\n\u003C/li>\n\u003Cli>\n\u003Cp>\u003Cstrong>Readability\u003C/strong>\u003Cbr>\nImproved readability for older MCs, with better support for built-in phone accessibility features.\u003C/p>\n\u003C/li>\n\u003Cli>\n\u003Cp>\u003Cstrong>Performance\u003C/strong>\u003Cbr>\nFaster, lighter apps through reduced duplication and a smaller overall app size.\u003C/p>\n\u003C/li>\n\u003C/ul>\n\u003Ch2 id=\"getting-started\">Getting started\u003C/h2>\n\u003Cp>It’s easy to write down what we wanted to achieve with our design system but we had 0 experience designing one.\u003C/p>\n\u003Cp>We started by studying how well-known design systems such as Material Design, Shopify’s Polaris, and Uber’s Base were structured.\nWe analyzed their token structures, naming conventions, and the rationale behind their choices. We watched talks, talked to peers, read blog posts and then we got started.\u003C/p>\n\u003Ch3 id=\"design-tokens\">Design Tokens\u003C/h3>\n\u003Cp>Design tokens represent the small, repeated design decisions that make up a design system’s visual style. They replace static values, such as hex codes for color, with self-explanatory names. A token’s value can be one of several things: a color, a typeface, a measurement, or even another token.\u003C/p>\n\u003Cfigure class=\"image-figure\">\u003Cimg __ASTRO_IMAGE_=\"{"src":"design-system-philosophy.webp","alt":"The way we envisioned our lean system to work inspired from Spotify’s Encore","index":0}\">\u003Cfigcaption>The way we envisioned our lean system to work inspired from Spotify’s Encore\u003C/figcaption>\u003C/figure>\n\u003Cp>We chose \u003Cstrong>colour\u003C/strong> and \u003Cstrong>typography\u003C/strong> as tokens in our system. We chose only these tokens because they gave the team the autonomy to move fast while giving us the flexibility to maintain consistency where it mattered.\nAll without locking us into a rigid design expression. These tokens could be used to create design “atoms” and “molecules” across different platforms, allowing our\ncomponents to adapt naturally to each platform’s native constraints.\nThis flexibility was crucial. It allowed teams to move faster, design for different use cases, and scale without sacrificing brand coherence.\u003C/p>\n\u003Cblockquote>\n\u003Cp>For example, in 2024, when we built react native apps by adopting \u003Ca href=\"https://reactnativepaper.com/\">Paper\u003C/a>, our tokens could easily be ported to make Paper-based apps feel like a Jiva product.\nIn tools like Retool, we only ported over colour tokens because that’s all we needed to ensure visual consistency.\nThis token-driven flexibility became the key to scaling design without getting bogged down by unnecessary rigidity like uniformity of components.\u003C/p>\n\u003C/blockquote>\n\u003Ch4 id=\"typography\">Typography\u003C/h4>\n\u003Cfigure class=\"image-figure\">\u003Cimg __ASTRO_IMAGE_=\"{"src":"type.webp","alt":"Old type vs New type","index":0}\">\u003Cfigcaption>Old type vs New type\u003C/figcaption>\u003C/figure>\n\u003Cp>For Typography, we decided to lean on system defaults. On Android, by switching from \u003Ca href=\"https://fonts.adobe.com/fonts/mr-eaves-xl\">Mr. Eaves\u003C/a>(our brand font) to Roboto, we addressed the legibility issues we had previously\nfaced, particularly on budget Android devices. However, this wasn’t\na simple swap. We had to design a type scale that ensured our transition was seamless and consistent across various text elements, from headings to body text.\nfor this was taking several key UI screens and replacing text to see how we could map the new type styles to the old ones with minimal effect to the UI.\u003C/p>\n\u003Ch4 id=\"color\">Color\u003C/h4>\n\u003Cfigure class=\"image-figure\">\u003Cimg __ASTRO_IMAGE_=\"{"src":"color.webp","alt":"","index":0}\">\u003C/figure>\n\u003Cp>Colour, on the other hand, posed a unique challenge. Our original primary colour (#0AB858), vibrant as it was, didn’t meet \u003Ca href=\"https://www.w3.org/WAI/standards-guidelines/wcag/\">WCAG\u003C/a> contrast requirements, especially for text on white or green backgrounds in smaller font sizes. We knew this was a dealbreaker for accessibility.\nAchieving the right contrast was tough — white on green rarely provides the necessary legibility, particularly on low-resolution displays. Finally with the help of\nEnvoy’s post on \u003Ca href=\"https://medium.com/envoy-design/how-to-design-an-accessible-color-scheme-4a13ca12c92b\">building an accessible colour scheme\u003C/a>, \u003Ca href=\"https://www.figma.com/community/plugin/732603254453395948/stark-contrast-accessibility-checker\">Stark’s handy plugin\u003C/a> and \u003Ca href=\"https://www.figma.com/community/plugin/1242548152689430610/tailwind-css-color-generator\">Tailwind Color Generator plugin\u003C/a>, we found a modified shade of green(#006E25)\nthat worked visually and was AA compliant. But colour wasn’t just about picking a new shade;\nwe also had to write detailed guidelines for how and where it should be used to maintain consistency and accessibility across our products.\u003C/p>\n\u003Ch3 id=\"bringing-it-all-together\">Bringing it all together\u003C/h3>\n\u003Cp>M3 \u003Ca href=\"https://m3.material.io\">(Material Design 3)\u003C/a> had just released and we loved the fresh new style it brought with it. Material Design is built around a ‘primary’ color making it easy for\npeople(read: devs) to adopt it. They provide you a \u003Ca href=\"https://www.figma.com/community/plugin/1034969338659738588/material-theme-builder\">figma plugin\u003C/a> to generate your color tokens but it lacks customization and is overly technical.\u003C/p>\n\u003Cp>Moreover, the way these tokens styled the components felt awkward to us. It did not fit our brand. So we decided to take control and create our own token system which we would map to these components.\u003C/p>\n\u003Cp>During further research, we learned that there’s no standardization of naming conventions across companies—each has its own needs and preferences. This situation challenged us, as we’re new to design tokens and struggled to decide which approach we can go ahead with. It was only when we watched \u003Ca href=\"https://www.youtube.com/watch?v=ylDed18OVdY\">this talk from Schema 2021\u003C/a> titled \u003Cem>“Design tokens at Asana”\u003C/em> by Jina Anne,\nAinsley Wagoner, and Ivy Wang that the solution finally dawned on us.\u003C/p>\n\u003Cblockquote>\n\u003Cp>Color tokens need to be comprehensive enough to clearly describe their usage, yet concise enough to make it easy to determine which tokens to apply.\u003C/p>\n\u003C/blockquote>\n\u003Cp>We took the ideas from the talk and aimed to create tokens that are direct and self-explanatory. Our goal was to make them easily understandable by all and avoid designers needing to refer back to documentation to use the system.\u003C/p>\n\u003Cfigure class=\"image-figure\">\u003Cimg __ASTRO_IMAGE_=\"{"src":"naming.webp","alt":"Naming convention of Akar","index":0}\">\u003Cfigcaption>Naming convention of Akar\u003C/figcaption>\u003C/figure>\n\u003Col>\n\u003Cli>\u003Cins>Property\u003C/ins> We start with what we call ‘property’, thus called because it defines what kind of element it is applied to; content, background or border. So for a primary button below, the color token for the text uses the content property while the colour of the button is represented by the background property.\u003C/li>\n\u003Cli>\u003Cins>Roles\u003C/ins> The ‘role’ aspect is where you start to identify the kind of component you are attempting to style. We use ‘Action’ for components that need the user to ‘act’ on them while ‘Highlight’ and ‘Interactive’ are used for communicating a system reaction to the user. We have ‘default’ for neutral colours and ‘decorative’ was introduced at a later point for components like badges and tags that needed to be visually appealing.\u003C/li>\n\u003Cli>\u003Cins>Priority\u003C/ins> Priority is used to optimize the visual hierarchy within the user interface, ensuring that the most important elements stand out and draw the user’s attention. By assigning different priority levels to components, we can guide users through the interface more intuitively, highlighting key actions, content, or information and making the overall experience more seamless and efficient.\u003C/li>\n\u003Cli>\u003Cins>Type\u003C/ins> Type is used to express the tone or meaning of an element, such as information, success, warning, error, or neutrality. These types are applied to components like buttons, banners, and toasts, as well as to elements like icons and text.\u003C/li>\n\u003Cli>\u003Cins>States\u003C/ins> States are visual indicators that communicate the current status or condition of a component or interactive element. They help users understand how an element is behaving at any given moment, such as whether it’s pressed, loading, selected, focused, or disabled.\u003C/li>\n\u003C/ol>\n\u003Cfigure class=\"image-figure\">\u003Cimg __ASTRO_IMAGE_=\"{"src":"how-to-tokens.webp","alt":"How designers can use our tokens","index":0}\">\u003Cfigcaption>How designers can use our tokens\u003C/figcaption>\u003C/figure>\n\u003Ch3 id=\"the-final-stretch\">The Final stretch\u003C/h3>\n\u003Cp>If your design system exists only in Figma, then its just a style guide. For a design system to be truly complete, it needs to exists outside of Figma and as a code library.\u003C/p>\n\u003Cp>We were re-writing our Android Front end in Jetpack Compose and decided to merge the two efforts to implement our design system.\nWhile having self-explanatory token naming certainly makes designers’ lives easier, by taking this direction of deviating from Material Design’s conventions, we increased our developement effort.\nWe had to build a bridge to make our tokens compatible with material design. This wasn’t straightforward. Most big companies that we studied had UX engineering teams to help build such plugins for their use.\nWe came across \u003Ca href=\"https://github.com/style-dictionary/style-dictionary\">Amazon’s style dictionary\u003C/a> from \u003Ca href=\"https://www.youtube.com/watch?v=jgueTz72ZMQ&t=760s\">this talk by Doordash\u003C/a> and Atlassian’s inhouse plugin in \u003Ca href=\"https://www.youtube.com/watch?v=m8ZSu9eCsQc&t=814s\">their schema talk\u003C/a>\nand the popular figma plugin \u003Ca href=\"https://tokens.studio\">Tokens Studio\u003C/a>.\u003C/p>\n\u003Cblockquote>\n\u003Cp>So why did we still proceed with this approach? We prioritized ease of use, recognizing that the development work to implement this system is a one-time investment.\nWe believed that it was a worthwhile trade-off.\u003C/p>\n\u003C/blockquote>\n\u003Cp>It wasn’t really all that straightforward. We were only able to make it work by closely working with our developers(Sivan and Vishnu).\u003C/p>\n\u003Ch4 id=\"our-approach\">Our Approach\u003C/h4>\n\u003Cp>We used Tokens Studio to export our tokens from Figma as JSON and the devs had to figure out how to translate this to a setup that can be consumed by our apps.\nThe aim was to make sure that the designers had the freedom to take decisions while the devs wouldn’t have to break a sweat in integrating them into the apps.\u003C/p>\n\u003Cp>Our apps are on the Jetpack Compose framework and this meant that the design language and consumption were slightly different from Android’s traditional XML.\nWe found \u003Ca href=\"https://github.com/lukasoppermann/design-token-transformer\">Lukas Opperman’s Design Token Transformer\u003C/a> to be a great tool for porting tokens to Web,\niOS and Android’s XML system but we needed something that would support Jetpack Compose as well. So we forked this repo and decided to add support for Jetpack Compose.\nThe overall idea was straightforward. The engine should take in the\nJSON file as the input, and spit out Compose Theming files that can be imported onto your project directly and the devs wouldn’t have to worry too much about the setup.\u003C/p>\n\u003Cimg src=\"/images/tokens-figma.gif\" alt=\"Tokens in Figma\" style=\"border-radius: 8px;\">\n\u003Cp>And that’s how we placed the final piece of our design system jigsaw puzzle.\u003C/p>\n\u003Ch2 id=\"presenting-the-akar-design-sytem\">Presenting the Akar Design Sytem:\u003C/h2>\n\u003Cp>All this while, we had been working hard on the system but we realised we didn’t have a name for our design system. We wanted something that resonated with the agritech space we were in, so we began brainstorming. Finally, with the help of Notion AI, we chose to go with Akar.\u003C/p>\n\u003Cp>Akar, derived from the Bahasa Indonesia word for ‘root,’ perfectly reflects the role of our design system in providing a solid foundation for building products. It’s also symbolic, as Indonesia is where our products first took shape, making the name a meaningful nod to our origins.\u003C/p>\n\u003Cfigure class=\"image-figure\">\u003Cimg __ASTRO_IMAGE_=\"{"src":"akar-screens.webp","alt":"Akar on our screens","index":0}\">\u003Cfigcaption>Akar on our screens\u003C/figcaption>\u003C/figure>\n\u003Ch3 id=\"post-launch\">Post-launch\u003C/h3>\n\u003Cp>A design system’s success is measure by its penetration and implementation by the team. Building it in isolation is bound to fail. Throughout the process, we spent time\ninvolving the dev and design teams. We did this by\u003C/p>\n\u003Cul>\n\u003Cli>We created Slack channels to communicate updates and invite collaboration.\u003C/li>\n\u003Cli>We presented the system at an org-wide ‘Lunch and Learn’ (an org level initiative to talk about work) to bring awareness to the initiative.\u003C/li>\n\u003Cli>To track adoption, we created pod-specific slack channels for devs and designers to have discussions around implementation and we set up a Notion page to track migration and adoption.\u003C/li>\n\u003Cli>We created a \u003Ca href=\"https://zeroheight.com/5c1eb1bd5/p/73e674-akar-design-system\">documentation site\u003C/a> which devs and designers could refer to.\u003C/li>\n\u003C/ul>\n\u003Ch2 id=\"impact\">Impact\u003C/h2>\n\u003Cp>Having Akar, helped us scale faster and build and redesign new apps and products in the Jiva ecosystem. As of September 2025, it was used across various platforms and products at Jiva,\nsupporting our 3 core Android mobile apps (Sahabat Jiva, Jiva Petani, Jiva Agro). We also extended our tokens to be used in our internal React Native apps (Jiva Sales, Field Agent App), as well as internal tools built using Retool.\u003C/p>\n\u003Cp>Implementation of the code components was a slow process as getting it prioritised over business needs was hard.\nWe were able to get like 80% of the product verticals to completely use our libarary within the first 12 months.\u003C/p>\n\u003Ch2 id=\"team\">Team\u003C/h2>\n\u003Cp>Tyo (who had just joined the team) worked with me and built out the Figma token and components system. Nav, (head of design), helped us take decisions\naround the direction of the design components. Sivan and VIshnu were the devs who we collaborated closely to get the code components out in production.\u003C/p>\n\u003Csection data-footnotes=\"\" class=\"footnotes\">\u003Ch2 class=\"sr-only\" id=\"footnote-label\">Footnotes\u003C/h2>\n\u003Col>\n\u003Cli id=\"user-content-fn-1\">\n\u003Cp>\u003Cstrong>Spotify’s Encore\u003C/strong> \u003Ca href=\"https://spotify.design/article/can-i-get-an-encore-spotifys-design-system-three-years-on\">https://spotify.design/article/can-i-get-an-encore-spotifys-design-system-three-years-on\u003C/a> \u003Ca href=\"#user-content-fnref-1\" data-footnote-backref=\"\" aria-label=\"Back to reference 1\" class=\"data-footnote-backref\">↩\u003C/a>\u003C/p>\n\u003C/li>\n\u003C/ol>\n\u003C/section>",{"headings":390,"localImagePaths":437,"remoteImagePaths":438,"frontmatter":439,"imagePaths":440},[391,394,397,400,403,406,409,412,415,418,421,424,427,430,433,436],{"depth":117,"slug":392,"text":393},"role","Role",{"depth":117,"slug":395,"text":396},"challenge","Challenge",{"depth":101,"slug":398,"text":399},"goals","Goals",{"depth":101,"slug":401,"text":402},"impact-on-our-customers","Impact on our customers",{"depth":117,"slug":404,"text":405},"getting-started","Getting started",{"depth":101,"slug":407,"text":408},"design-tokens","Design Tokens",{"depth":143,"slug":410,"text":411},"typography","Typography",{"depth":143,"slug":413,"text":414},"color","Color",{"depth":101,"slug":416,"text":417},"bringing-it-all-together","Bringing it all together",{"depth":101,"slug":419,"text":420},"the-final-stretch","The Final stretch",{"depth":143,"slug":422,"text":423},"our-approach","Our Approach",{"depth":117,"slug":425,"text":426},"presenting-the-akar-design-sytem","Presenting the Akar Design Sytem:",{"depth":101,"slug":428,"text":429},"post-launch","Post-launch",{"depth":117,"slug":431,"text":432},"impact","Impact",{"depth":117,"slug":434,"text":435},"team","Team",{"depth":117,"slug":118,"text":119},[378,379,380,381,382,383,384],[],{"title":370,"description":371,"year":373,"company":374,"image":385},[378,379,380,381,382,383,384],"akar-design-system/index.md","hiring-jiva",{"id":442,"data":444,"body":448,"filePath":449,"digest":450,"rendered":451,"legacyId":474},{"title":445,"description":446,"year":447,"status":261},"Hiring Product Designers at Jiva","An overview of the product design hiring process at Jiva that we used to scale to 11+ designers","2022-2024","When I joined Jiva in January of 2022, as the Senior Design Manager of Product Design, we were a team of 2; me and Sai. We had to start building a team. I’ve never had the opportunity to build a team from scratch and it felt scary at first.\nWe had no defined process nor an evaluation criteria, just a product designer job description. It was well structured job description and spoke to the generalist designers we wanted to recruit but we were aware we needed to scale.\n\nSo with Nav's guidance, we designed a simple hiring flow keeping the good part of the older scrappy process while being mindful about the candidates and their time. \n\nOur process therefore was quite simple; \n\n### Round 0: Shortlisting Candidates\nWith our job description posted, we looked for candidates and their submissions to shortlist the ones we wanted to speak to. When Jiva was less known, we barely had any interested candidates and shortlisting was very easy.\nBut for the last set of job openings, we had a lot of demand making it impossible to screen efficiently. We encouraged people to send us Cover letters while applying rather than applying via the portal.\nThis acted as a fairly effective screening condition as not many ended up emailing us.\n\n### Round 1: Screening Call\nThis is the first experience a candidate has of Jiva’s design team and we want it to be the best.\nWe want to make the candidate comfortable and help them understand what Jiva is and what working here would be like.\nThis was the round where we discussed compensation in brief so that we could set expectations both upstream (with HR and leadership) and downstream (with the candidate).\nThe hiring manager (i.e., me) was the best person to have this conversation with the candidate.\n\nFor a candidate to make it through, they just needed to feel like they knew how to design, work in the team and someone I would want to have on my team.\nThe folks who blew my mind in this round inadvertently went to be key members of the team and probably the best skilled designers I've worked with.\n\n### Round 2: Presentation Round\nSince we were a small team with a short candidate pipeline, we didn't see value in having take home assignments or whiteboarding sessions, instead we opted for the presentation round. The jury for this round was composed\nof the other designers. We designed the jury based on the candidate. There would be a cultural mix of nationalities, genders and design disciplines in every jury panel. What we mainly measured in this round was\nthe capabilities of a product designer, (eventually we used our Job levels for this evaluation) and how they vibed with the jury panel. It wasn't enough that you had good work, you needed\nto fit in. Controversial maybe? but I felt strongly that getting people to play well together is key to building good design teams. In time, I've come to realize that just because you have technical chops\ndoesn't make you a good product designer. You also need to be kind, empathetic and collaborative. Technical skills can be learned, these values can not.\n\nIf you made it past this round, \"Congrats, welcome to the Jiva design team\" 🙌🏽\n\nFor everyone we rejected in Round 2, I tried to send a personal email to them explaining why they didn't make it. But this was hard to follow 100% of the time and I'm sure I forgot to send a few.\n\n### Round 3(?): Stakeholder Round\nFor L3 (our highest IC level) hiring, we added an extra round. \nThis was a chat with a Lead product manager to help gauge how the designer would fit within the Product and their product thinking abilities.\nThese designers would function like leads and own design for their product vertical. \n\n### Round 4: HR Round\nThere was a final round(or two) where either Nav or HR would have a conversation with the employee and dealt with the technicalities around compensation and hiring policies.\n\nIn time, we grew the team to 11 product designers working on 5+ mobile and web apps across multiple business systems (farmer, collector, retailer).","src/content/work/hiring-jiva/index.md","a71264957ff07f2d",{"html":452,"metadata":453},"\u003Cp>When I joined Jiva in January of 2022, as the Senior Design Manager of Product Design, we were a team of 2; me and Sai. We had to start building a team. I’ve never had the opportunity to build a team from scratch and it felt scary at first.\nWe had no defined process nor an evaluation criteria, just a product designer job description. It was well structured job description and spoke to the generalist designers we wanted to recruit but we were aware we needed to scale.\u003C/p>\n\u003Cp>So with Nav’s guidance, we designed a simple hiring flow keeping the good part of the older scrappy process while being mindful about the candidates and their time.\u003C/p>\n\u003Cp>Our process therefore was quite simple;\u003C/p>\n\u003Ch3 id=\"round-0-shortlisting-candidates\">Round 0: Shortlisting Candidates\u003C/h3>\n\u003Cp>With our job description posted, we looked for candidates and their submissions to shortlist the ones we wanted to speak to. When Jiva was less known, we barely had any interested candidates and shortlisting was very easy.\nBut for the last set of job openings, we had a lot of demand making it impossible to screen efficiently. We encouraged people to send us Cover letters while applying rather than applying via the portal.\nThis acted as a fairly effective screening condition as not many ended up emailing us.\u003C/p>\n\u003Ch3 id=\"round-1-screening-call\">Round 1: Screening Call\u003C/h3>\n\u003Cp>This is the first experience a candidate has of Jiva’s design team and we want it to be the best.\nWe want to make the candidate comfortable and help them understand what Jiva is and what working here would be like.\nThis was the round where we discussed compensation in brief so that we could set expectations both upstream (with HR and leadership) and downstream (with the candidate).\nThe hiring manager (i.e., me) was the best person to have this conversation with the candidate.\u003C/p>\n\u003Cp>For a candidate to make it through, they just needed to feel like they knew how to design, work in the team and someone I would want to have on my team.\nThe folks who blew my mind in this round inadvertently went to be key members of the team and probably the best skilled designers I’ve worked with.\u003C/p>\n\u003Ch3 id=\"round-2-presentation-round\">Round 2: Presentation Round\u003C/h3>\n\u003Cp>Since we were a small team with a short candidate pipeline, we didn’t see value in having take home assignments or whiteboarding sessions, instead we opted for the presentation round. The jury for this round was composed\nof the other designers. We designed the jury based on the candidate. There would be a cultural mix of nationalities, genders and design disciplines in every jury panel. What we mainly measured in this round was\nthe capabilities of a product designer, (eventually we used our Job levels for this evaluation) and how they vibed with the jury panel. It wasn’t enough that you had good work, you needed\nto fit in. Controversial maybe? but I felt strongly that getting people to play well together is key to building good design teams. In time, I’ve come to realize that just because you have technical chops\ndoesn’t make you a good product designer. You also need to be kind, empathetic and collaborative. Technical skills can be learned, these values can not.\u003C/p>\n\u003Cp>If you made it past this round, “Congrats, welcome to the Jiva design team” 🙌🏽\u003C/p>\n\u003Cp>For everyone we rejected in Round 2, I tried to send a personal email to them explaining why they didn’t make it. But this was hard to follow 100% of the time and I’m sure I forgot to send a few.\u003C/p>\n\u003Ch3 id=\"round-3-stakeholder-round\">Round 3(?): Stakeholder Round\u003C/h3>\n\u003Cp>For L3 (our highest IC level) hiring, we added an extra round.\nThis was a chat with a Lead product manager to help gauge how the designer would fit within the Product and their product thinking abilities.\nThese designers would function like leads and own design for their product vertical.\u003C/p>\n\u003Ch3 id=\"round-4-hr-round\">Round 4: HR Round\u003C/h3>\n\u003Cp>There was a final round(or two) where either Nav or HR would have a conversation with the employee and dealt with the technicalities around compensation and hiring policies.\u003C/p>\n\u003Cp>In time, we grew the team to 11 product designers working on 5+ mobile and web apps across multiple business systems (farmer, collector, retailer).\u003C/p>",{"headings":454,"localImagePaths":470,"remoteImagePaths":471,"frontmatter":472,"imagePaths":473},[455,458,461,464,467],{"depth":101,"slug":456,"text":457},"round-0-shortlisting-candidates","Round 0: Shortlisting Candidates",{"depth":101,"slug":459,"text":460},"round-1-screening-call","Round 1: Screening Call",{"depth":101,"slug":462,"text":463},"round-2-presentation-round","Round 2: Presentation Round",{"depth":101,"slug":465,"text":466},"round-3-stakeholder-round","Round 3(?): Stakeholder Round",{"depth":101,"slug":468,"text":469},"round-4-hr-round","Round 4: HR Round",[],[],{"title":445,"description":446,"year":447,"status":261},[],"hiring-jiva/index.md","gobiz-inbox",{"id":475,"data":477,"body":482,"filePath":483,"digest":484,"rendered":485,"legacyId":514},{"title":478,"description":479,"year":480,"company":481,"status":261},"Designing the Inbox experience for GoBiz","How we designed the in-app comms channel","2021","Gojek","The Gojek Chat SDK was built to support products wanting to integrate chat into their flows. However like many other platformized products, they end up being looked as solutions for use cases they were not designed for. The GoBiz inbox requirement wasn't my first experience with dog fooding, but it was one that I was able to influence positively for the benefit of the users.\n\nWe wanted to build an Inbox, an in-app channel for notifying our users. We just needed one-way communication. I do not understand the reason behind why product pushed to use the SDK, despite the arguments that the SDK wasn't able to support our web product and wasn't designed to communicate business updates.\n\n### Chat is chat, not inbox:\n\nI created a document to explain what that decision meant for the app.\nIf we use the chat sdk, then in the future as other teams build on the chat platform, we should plan to group all kinds of chat in a single space. This would align with the mental model of the user. This space would be the go-to place to follow up on your \"conversations\", whether its about onboarding a new outlet or following up about your GoFresh order.\n\n_Decision:_ We decided that all chats will show up in Inbox but we will need to visually separate them from the business chats. This is something that the Chat team had not yet designed for.\n\n### Where should Inbox/chat go?\n\nGiven that Inbox is something we are considering for communication, it should be easily accessible and indicate unread chats. Given the current structure of the GoBiz app, we could only think of 2 possible positions for the Inbox.\n\nHowever neither of these positions fulfill the conditions of\n\n1. Visibility of new messages: The red dot on Lainnya can't showcase a number since there are several other modules which have a no-number indication.\n\n2. Accessible from various parts of our app: A gofood merchant would jump right to the Orders inbox when they open the app and has no need to aware of this \"notification'\n\n_Decision:_ However without the redesign being prioritized, we decided to keep the entry point on the top right of the 'Lainnya' page.\n\n### Shuffle vs Inbox:\n\n1. Currently there can be overlaps. Overlaps may lead to reduction in importance of Inbox content.\n\n2. Can 'Promo' channel in Inbox be completely replaced by a shuffle card channel on lainnya? because promos need segmentation. Inbox may not work that way.\n\n_Decision:_ No decision yet\n\n### Design iterations\n\nThe Inbox requirement wasn't a new one. 11 months ago, Saneef had worked on how we could introduce communication channels(banner and inbox) in our /existing/ app. [(Aside: His redesign had 'Inbox' as a tab on the bottom navigation)](https://share.goabstract.com/8af61eee-de93-4f63-b0f8-64922742a29e?mode=design&sha=875263ee629f633ddd9229602605e3870884c3da)\n\nWhat was good about this iteration was that latest messages would be visible on the Lainnya page with a way for users to filter different kinds of messages. However this design wouldn't scale well if there were many channels. Think how filters work on Gojek Home's shuffles. Same problem.\n\nWhen we decided to adopt the Chat SDK, it came with a constraint that the view would be a chat window.\n\nSo this constraint causes us to have limited explorations for the channel view. Based on this, here are two iterations that could be possible.\n\n#### Iteration 1:\n\nIteration 1 is having a list of channels on the second page, but without the full message so users would need to make an additional click through to get the full message.\n\n#### Iteration 2:\n\nThis exploration attempts to use a notifier informing user about a new message. It could include the text of the message or a generic '1 new message'. In the chat window, we can see the latest message of a channel up front without clicking again to see the message. Even CTAs could be visible here.\n\nSo we went ahead with user-testing with both these iterations, and 'Iteration 2' came out successful.\n\n#### Key Learnings from the research\n\n1. People may ignore the position of the Inbox because of its proximity to the logout button\n\n2. The inbox icon was not understood, so we switched to the envelope icon and called it 'Kotak Pesan'","src/content/work/gobiz-inbox/index.md","e41b0d64e917328f",{"html":486,"metadata":487},"\u003Cp>The Gojek Chat SDK was built to support products wanting to integrate chat into their flows. However like many other platformized products, they end up being looked as solutions for use cases they were not designed for. The GoBiz inbox requirement wasn’t my first experience with dog fooding, but it was one that I was able to influence positively for the benefit of the users.\u003C/p>\n\u003Cp>We wanted to build an Inbox, an in-app channel for notifying our users. We just needed one-way communication. I do not understand the reason behind why product pushed to use the SDK, despite the arguments that the SDK wasn’t able to support our web product and wasn’t designed to communicate business updates.\u003C/p>\n\u003Ch3 id=\"chat-is-chat-not-inbox\">Chat is chat, not inbox:\u003C/h3>\n\u003Cp>I created a document to explain what that decision meant for the app.\nIf we use the chat sdk, then in the future as other teams build on the chat platform, we should plan to group all kinds of chat in a single space. This would align with the mental model of the user. This space would be the go-to place to follow up on your “conversations”, whether its about onboarding a new outlet or following up about your GoFresh order.\u003C/p>\n\u003Cp>\u003Cem>Decision:\u003C/em> We decided that all chats will show up in Inbox but we will need to visually separate them from the business chats. This is something that the Chat team had not yet designed for.\u003C/p>\n\u003Ch3 id=\"where-should-inboxchat-go\">Where should Inbox/chat go?\u003C/h3>\n\u003Cp>Given that Inbox is something we are considering for communication, it should be easily accessible and indicate unread chats. Given the current structure of the GoBiz app, we could only think of 2 possible positions for the Inbox.\u003C/p>\n\u003Cp>However neither of these positions fulfill the conditions of\u003C/p>\n\u003Col>\n\u003Cli>\n\u003Cp>Visibility of new messages: The red dot on Lainnya can’t showcase a number since there are several other modules which have a no-number indication.\u003C/p>\n\u003C/li>\n\u003Cli>\n\u003Cp>Accessible from various parts of our app: A gofood merchant would jump right to the Orders inbox when they open the app and has no need to aware of this “notification’\u003C/p>\n\u003C/li>\n\u003C/ol>\n\u003Cp>\u003Cem>Decision:\u003C/em> However without the redesign being prioritized, we decided to keep the entry point on the top right of the ‘Lainnya’ page.\u003C/p>\n\u003Ch3 id=\"shuffle-vs-inbox\">Shuffle vs Inbox:\u003C/h3>\n\u003Col>\n\u003Cli>\n\u003Cp>Currently there can be overlaps. Overlaps may lead to reduction in importance of Inbox content.\u003C/p>\n\u003C/li>\n\u003Cli>\n\u003Cp>Can ‘Promo’ channel in Inbox be completely replaced by a shuffle card channel on lainnya? because promos need segmentation. Inbox may not work that way.\u003C/p>\n\u003C/li>\n\u003C/ol>\n\u003Cp>\u003Cem>Decision:\u003C/em> No decision yet\u003C/p>\n\u003Ch3 id=\"design-iterations\">Design iterations\u003C/h3>\n\u003Cp>The Inbox requirement wasn’t a new one. 11 months ago, Saneef had worked on how we could introduce communication channels(banner and inbox) in our /existing/ app. \u003Ca href=\"https://share.goabstract.com/8af61eee-de93-4f63-b0f8-64922742a29e?mode=design&sha=875263ee629f633ddd9229602605e3870884c3da\">(Aside: His redesign had ‘Inbox’ as a tab on the bottom navigation)\u003C/a>\u003C/p>\n\u003Cp>What was good about this iteration was that latest messages would be visible on the Lainnya page with a way for users to filter different kinds of messages. However this design wouldn’t scale well if there were many channels. Think how filters work on Gojek Home’s shuffles. Same problem.\u003C/p>\n\u003Cp>When we decided to adopt the Chat SDK, it came with a constraint that the view would be a chat window.\u003C/p>\n\u003Cp>So this constraint causes us to have limited explorations for the channel view. Based on this, here are two iterations that could be possible.\u003C/p>\n\u003Ch4 id=\"iteration-1\">Iteration 1:\u003C/h4>\n\u003Cp>Iteration 1 is having a list of channels on the second page, but without the full message so users would need to make an additional click through to get the full message.\u003C/p>\n\u003Ch4 id=\"iteration-2\">Iteration 2:\u003C/h4>\n\u003Cp>This exploration attempts to use a notifier informing user about a new message. It could include the text of the message or a generic ‘1 new message’. In the chat window, we can see the latest message of a channel up front without clicking again to see the message. Even CTAs could be visible here.\u003C/p>\n\u003Cp>So we went ahead with user-testing with both these iterations, and ‘Iteration 2’ came out successful.\u003C/p>\n\u003Ch4 id=\"key-learnings-from-the-research\">Key Learnings from the research\u003C/h4>\n\u003Col>\n\u003Cli>\n\u003Cp>People may ignore the position of the Inbox because of its proximity to the logout button\u003C/p>\n\u003C/li>\n\u003Cli>\n\u003Cp>The inbox icon was not understood, so we switched to the envelope icon and called it ‘Kotak Pesan’\u003C/p>\n\u003C/li>\n\u003C/ol>",{"headings":488,"localImagePaths":510,"remoteImagePaths":511,"frontmatter":512,"imagePaths":513},[489,492,495,498,501,504,507],{"depth":101,"slug":490,"text":491},"chat-is-chat-not-inbox","Chat is chat, not inbox:",{"depth":101,"slug":493,"text":494},"where-should-inboxchat-go","Where should Inbox/chat go?",{"depth":101,"slug":496,"text":497},"shuffle-vs-inbox","Shuffle vs Inbox:",{"depth":101,"slug":499,"text":500},"design-iterations","Design iterations",{"depth":143,"slug":502,"text":503},"iteration-1","Iteration 1:",{"depth":143,"slug":505,"text":506},"iteration-2","Iteration 2:",{"depth":143,"slug":508,"text":509},"key-learnings-from-the-research","Key Learnings from the research",[],[],{"title":478,"description":479,"year":480,"company":481,"status":261},[],"gobiz-inbox/index.md","claim-profile",{"id":515,"data":517,"body":523,"filePath":524,"assetImports":525,"digest":527,"rendered":528,"legacyId":548},{"title":518,"description":519,"image":520,"year":521,"company":522,"status":261},"Practo.com doctor profiles","Designing the onboarding experience for new doctors on Practo.com","__ASTRO_IMAGE_./practo-profile.png","2016-2017","Practo","## Overview\n\nPracto has around 100k doctor profiles and another 70k clinic profiles currently live on its marketplace.\nThis accounts for barely 50% of coverage in our T6 cities. So during the Q3-Q4 of 2016-17, the primary\nobjective of the unified app; Practo Partner, was to get more profiles published and live.\n\nAround November 2016, to get a profile live on Practo.com, a doctor needed to fill in 20 fields which\nwere separated into 2 forms. We had taken the approach as an informational option but realized that\nlot of profiles were not being completed and we did not communicate what was necessary to go live to\na doctor within the app.\n\n\n[before we began]\n\n## Understanding the problem\n\nAs seen above, we did communicate that a profile was incomplete but the interface didn't\ncommunicate what was necessary for a doctor to go live. Our completion data showed us that major\ndropoffs occurred during profile completion, proof upload and clinic profile addition.\n\nWe studied onboarding flows of other applications like Airbnb and Gyroscope which deal with filling lot\nof mandatory data as well as Doximity which deals with the claiming of doctor profiles to get started.\nExploring a solution\n\nAfter some discussions with the stakeholders, we decided the best way to deliver impact was if we\nbreak this project into phases. For the first phase, we designed and shipped out with an intent page\nand a quick fix stitching the two forms together. At the same time, the app was going through the new\nbrand implementation which explains the choice of color palette and the change in typography.\n\n[designs from phase 1]\n\nPost this change, we saw an increase(approx 34%) in the profiles going towards completion in the\nmonth of March vs February and January numbers. This validated the brief and the direction that we\nwere going towards.\n\nAs part of the feet-on-street model adopted by Practo, we had several profiles that had been created\nby the salesguy, however those profiles were not being used by the doctor and instead the doctor\nwould create a new profile when they logged in leading to duplicates which would be an overhead for\noperations and decreased efficiency. We also needed doctors to keep their profile data fresh. So with\nthis in mind, Claim profile became a company objective so the next phase was integrating this into the\nonboarding\n\nThe various usecases and catering to both new and existing users kept us busy for almost a month\nwhere we iterated on various designs before narrowing down on one. We worked closely with the\nprofiles product team whenever we had to make a decision, since they knew best about the way profile\nclaim worked.\n\n\n[early explorations]\n\nBased on all these inputs, we were able to narrow down on the direction that we wanted to take for the\nproject.\nevolution of the ‘checkout’ screen\n\n\n### Things we are trying out with this\n– The design accommodated for problems with the flow with keeping a way to access our hotline on all\nthe decision making pages.\n– Users dropping off would be asked if they would want to be reminded to fill the form at a later time.\nThe form needs document proofs to be complete and these would not always be at hand.\n\n## Final screens\n\n\n**Footnote:**\nThanks to Sonal, Suhas, Preet, Rafiq, Pramod, Rachit and the rest of the Practo Pro team for their\ninputs and help in making this design come true","src/content/work/claim-profile/index.md",[526],"./practo-profile.png","a77ca723bf32625f",{"html":529,"metadata":530},"\u003Ch2 id=\"overview\">Overview\u003C/h2>\n\u003Cp>Practo has around 100k doctor profiles and another 70k clinic profiles currently live on its marketplace.\nThis accounts for barely 50% of coverage in our T6 cities. So during the Q3-Q4 of 2016-17, the primary\nobjective of the unified app; Practo Partner, was to get more profiles published and live.\u003C/p>\n\u003Cp>Around November 2016, to get a profile live on Practo.com, a doctor needed to fill in 20 fields which\nwere separated into 2 forms. We had taken the approach as an informational option but realized that\nlot of profiles were not being completed and we did not communicate what was necessary to go live to\na doctor within the app.\u003C/p>\n\u003Cp>[before we began]\u003C/p>\n\u003Ch2 id=\"understanding-the-problem\">Understanding the problem\u003C/h2>\n\u003Cp>As seen above, we did communicate that a profile was incomplete but the interface didn’t\ncommunicate what was necessary for a doctor to go live. Our completion data showed us that major\ndropoffs occurred during profile completion, proof upload and clinic profile addition.\u003C/p>\n\u003Cp>We studied onboarding flows of other applications like Airbnb and Gyroscope which deal with filling lot\nof mandatory data as well as Doximity which deals with the claiming of doctor profiles to get started.\nExploring a solution\u003C/p>\n\u003Cp>After some discussions with the stakeholders, we decided the best way to deliver impact was if we\nbreak this project into phases. For the first phase, we designed and shipped out with an intent page\nand a quick fix stitching the two forms together. At the same time, the app was going through the new\nbrand implementation which explains the choice of color palette and the change in typography.\u003C/p>\n\u003Cp>[designs from phase 1]\u003C/p>\n\u003Cp>Post this change, we saw an increase(approx 34%) in the profiles going towards completion in the\nmonth of March vs February and January numbers. This validated the brief and the direction that we\nwere going towards.\u003C/p>\n\u003Cp>As part of the feet-on-street model adopted by Practo, we had several profiles that had been created\nby the salesguy, however those profiles were not being used by the doctor and instead the doctor\nwould create a new profile when they logged in leading to duplicates which would be an overhead for\noperations and decreased efficiency. We also needed doctors to keep their profile data fresh. So with\nthis in mind, Claim profile became a company objective so the next phase was integrating this into the\nonboarding\u003C/p>\n\u003Cp>The various usecases and catering to both new and existing users kept us busy for almost a month\nwhere we iterated on various designs before narrowing down on one. We worked closely with the\nprofiles product team whenever we had to make a decision, since they knew best about the way profile\nclaim worked.\u003C/p>\n\u003Cp>[early explorations]\u003C/p>\n\u003Cp>Based on all these inputs, we were able to narrow down on the direction that we wanted to take for the\nproject.\nevolution of the ‘checkout’ screen\u003C/p>\n\u003Ch3 id=\"things-we-are-trying-out-with-this\">Things we are trying out with this\u003C/h3>\n\u003Cp>– The design accommodated for problems with the flow with keeping a way to access our hotline on all\nthe decision making pages.\n– Users dropping off would be asked if they would want to be reminded to fill the form at a later time.\nThe form needs document proofs to be complete and these would not always be at hand.\u003C/p>\n\u003Ch2 id=\"final-screens\">Final screens\u003C/h2>\n\u003Cp>\u003Cstrong>Footnote:\u003C/strong>\nThanks to Sonal, Suhas, Preet, Rafiq, Pramod, Rachit and the rest of the Practo Pro team for their\ninputs and help in making this design come true\u003C/p>",{"headings":531,"localImagePaths":544,"remoteImagePaths":545,"frontmatter":546,"imagePaths":547},[532,535,538,541],{"depth":117,"slug":533,"text":534},"overview","Overview",{"depth":117,"slug":536,"text":537},"understanding-the-problem","Understanding the problem",{"depth":101,"slug":539,"text":540},"things-we-are-trying-out-with-this","Things we are trying out with this",{"depth":117,"slug":542,"text":543},"final-screens","Final screens",[],[],{"title":518,"description":519,"year":521,"company":522,"image":526,"status":261},[],"claim-profile/index.md","international",{"id":549,"data":551,"body":555,"filePath":556,"assetImports":557,"digest":567,"rendered":568,"legacyId":594},{"title":552,"description":553,"image":554,"year":480,"company":481,"status":18},"Taking GoBiz international","What I learnt from launching Gojek's GoBiz app for different Southeast Asian Countries","__ASTRO_IMAGE_./thai-header.jpeg","At Practo, I had my first experience designing for markets outside India. Singapore was one of the strongest regions for the Practo Ray product, and it encouraged us to build features tailored to their dentists like [Dental Charting](https://help.practo.com/practo-ray/emr/dental-emr/all-about-dental-charting/).\n\nBy 2015, we began rolling out the Practo Ray app to Malaysia, Indonesia, the Philippines, and Brazil. Looking back, our localisation efforts were still fairly shallow. Most of the adjustments were limited to currency, date and number formatting, or small copy tweaks.\n\nScaling the GoBiz app to Thailand, Vietnam, and Singapore was completely different. Just translating the interface was not an option. We did research to understand local restaurant workflows (e.g., Hawker Centres in Singapore), worked with the local team to understand local terminologies and cultural nuances, and studied how food ordering worked.\n\n### Collaboration and Organization\nBut first, every project needs a start. GoBiz functioned as a platform with multiple teams contributing to it. So when we prepared for a new country launch, it became crucial to have a transparent and collaborative approach. That's where Asana came in. I created the 'GoBiz International Design' template and assigned tasks to the different designers. This functioned as our team's design tracker and was referenced during the weekly SOS meetings (Scrum of Scrums) run by the program managers.\n\n![The GoBiz International Design template in Asana](./asana.png)\n\nFor the design work itself, we set up a new Sketch file in Abstract for every country launch instead of adding changes to the existing files. This kept file sizes manageable and reduced merge conflicts in the Master branch. It also made it much easier for other teams to locate the relevant designs without needing to check with us.\n\n### Typography\nDesigning for languages that use only Latin characters is fairly straightforward because most fonts support them. But when you need to support non-latin scripts like Thai, Vietnamese, and Simplified Chinese, things get a little complicated typographically.\nOur brand typeface, Maison Neue, did not support these scripts, so the app fell back to system fonts. In Thailand, this caused visible inconsistencies in size and styling.\nThis led to many merchants using their device accessibility settings to increase their font size, which caused our layouts to break.\n![Vietnamese rendering in Maison Neue](./viet.png)\n\nVietnamese had its own challenges. Missing glyphs resulted in broken, mismatched text because unsupported characters were rendered in a different fallback format. \nMaison Neue does not support several important Vietnamese glyphs such as ờ, ư, ằ, ố, ế, ữ, ả, ẻ, ễ, ỉ, ỏ, ủ, ư, ứ, ừ, ử, ữ, ự, ỷ.\n\nBy the time we started work on the Singapore app, I realized we needed to address this and sat down with the brand and design system leads to select a reliable fallback font. \nWe chose Noto Sans, which is free, widely supported, and covered all the scripts we needed. We replaced Maison Neue with Noto Sans in our GoBiz International app.\n\n##### P.S. \"wkwkwkwk\" and \"5555555\" are common ways of typing laughter in Indonesian and Thai texting culture.\n\n\u003Cdiv class=\"impact-images\" style=\"display: grid; grid-template-columns: 1fr 1fr 1fr; gap: 1rem;\">\n\n![Placing an order to test our flow](./dogfooding.png)\n\n![Observing how they track orders](./user-behaviour.png)\n\n![Checking out the competitors](./competitors.png)\n\n\u003C/div>\n\n### Managing Copy\nManaging design files is relatively easy compared to managing multi-country copy. When we started supporting multiple languages, tools like Lokalise did not exist in our workflow. We relied entirely on Google Docs and Google Sheets.\n\n![How we managed copy in Google Docs](./copy-doc.png)\n\nWhen the product supported only Bahasa Indonesia, all GoBiz copy lived inside a single Google Doc. Over time, the document grew extremely long and slow. I had seen other teams use sheets for managing multi-language copy, so I worked with our UX writer, Lauditta, to create a template suited to our needs.\n\nDevelopers manage strings using “keys,” and we needed a way to map each key to the right line of copy. We realised too late how important this mapping was. Migrating retroactively meant spending a large amount of time copy-pasting, verifying strings, and searching through sheets.\n\n![How we managed copy in Google Sheets](./copy-sheets.png)\n\nWe also wanted screen references to help reviewers see copy in context. This was especially useful for UX writers in other countries, as well as QA and designers who did not speak the local languages. The release of Google Sheets’ “Insert picture in cell” feature was a huge help for this.\nGojek eventually moved to using [Lokalise](https://lokalise.com) for its copy management [^1] \n\n[^1]: You can read more about their International copy process on the blog by the Thai and Viet UX writer https://www.gojek.io/blog/language-no-bar-how-we-localise-ux-copies-at-gojek\n\n### Learnings\n- Scaling GoBiz across Thailand, Vietnam, and Singapore taught me that localisation is never something you add after the product is built. Even after launch, every new feature needs to be evaluated through the lens of each country. The same care you put into the initial rollout has to continue, otherwise the product quietly drifts back toward the needs of the base market.\n\n- There's also an organizational reality that often gets ignored. Supporting multiple markets properly sometimes requires reshaping how teams work, how decisions are made, and who is involved in the roadmap. But these shifts take time, and they rarely get prioritised unless there is a clear business outcome tied to them. \nAt Gojek, this misalignment became clear. Each international market operated under its own brand and leadership, which meant we couldn’t consistently involve those teams in product planning. As a result, our roadmaps naturally skewed toward Indonesia, and we only built out some must-have features for other countries. \n\n### Closing thoughts\n\nGojek eventually exited Thailand and Vietnam, and its presence in Singapore today is minimal. Looking back, designing GoBiz for other countries was a highly rewarding and learning experience. I got to experience new cultures and work with people from different nationalities. Those lessons stayed with us long after the product lines, org charts, and roadmaps changed.\n\n![The Gojek research team with a restaurant owner in Bangkok](./thai-research.jpeg)","src/content/work/international/index.md",[558,559,560,561,562,563,564,565,566],"./asana.png","./viet.png","./dogfooding.png","./user-behaviour.png","./competitors.png","./copy-doc.png","./copy-sheets.png","./thai-research.jpeg","./thai-header.jpeg","9be9459a81518519",{"html":569,"metadata":570},"\u003Cp>At Practo, I had my first experience designing for markets outside India. Singapore was one of the strongest regions for the Practo Ray product, and it encouraged us to build features tailored to their dentists like \u003Ca href=\"https://help.practo.com/practo-ray/emr/dental-emr/all-about-dental-charting/\">Dental Charting\u003C/a>.\u003C/p>\n\u003Cp>By 2015, we began rolling out the Practo Ray app to Malaysia, Indonesia, the Philippines, and Brazil. Looking back, our localisation efforts were still fairly shallow. Most of the adjustments were limited to currency, date and number formatting, or small copy tweaks.\u003C/p>\n\u003Cp>Scaling the GoBiz app to Thailand, Vietnam, and Singapore was completely different. Just translating the interface was not an option. We did research to understand local restaurant workflows (e.g., Hawker Centres in Singapore), worked with the local team to understand local terminologies and cultural nuances, and studied how food ordering worked.\u003C/p>\n\u003Ch3 id=\"collaboration-and-organization\">Collaboration and Organization\u003C/h3>\n\u003Cp>But first, every project needs a start. GoBiz functioned as a platform with multiple teams contributing to it. So when we prepared for a new country launch, it became crucial to have a transparent and collaborative approach. That’s where Asana came in. I created the ‘GoBiz International Design’ template and assigned tasks to the different designers. This functioned as our team’s design tracker and was referenced during the weekly SOS meetings (Scrum of Scrums) run by the program managers.\u003C/p>\n\u003Cfigure class=\"image-figure\">\u003Cimg __ASTRO_IMAGE_=\"{"src":"./asana.png","alt":"The GoBiz International Design template in Asana","index":0}\">\u003Cfigcaption>The GoBiz International Design template in Asana\u003C/figcaption>\u003C/figure>\n\u003Cp>For the design work itself, we set up a new Sketch file in Abstract for every country launch instead of adding changes to the existing files. This kept file sizes manageable and reduced merge conflicts in the Master branch. It also made it much easier for other teams to locate the relevant designs without needing to check with us.\u003C/p>\n\u003Ch3 id=\"typography\">Typography\u003C/h3>\n\u003Cfigure class=\"image-figure\">\u003Cimg __ASTRO_IMAGE_=\"{"src":"./viet.png","alt":"Vietnamese rendering in Maison Neue","index":0}\">\u003Cfigcaption>Vietnamese rendering in Maison Neue\u003C/figcaption>\u003C/figure>\n\u003Cp>Vietnamese had its own challenges. Missing glyphs resulted in broken, mismatched text because unsupported characters were rendered in a different fallback format.\u003Cbr>\nMaison Neue does not support several important Vietnamese glyphs such as ờ, ư, ằ, ố, ế, ữ, ả, ẻ, ễ, ỉ, ỏ, ủ, ư, ứ, ừ, ử, ữ, ự, ỷ.\u003C/p>\n\u003Cp>By the time we started work on the Singapore app, I realized we needed to address this and sat down with the brand and design system leads to select a reliable fallback font.\nWe chose Noto Sans, which is free, widely supported, and covered all the scripts we needed. We replaced Maison Neue with Noto Sans in our GoBiz International app.\u003C/p>\n\u003Ch5 id=\"ps-wkwkwkwk-and-5555555-are-common-ways-of-typing-laughter-in-indonesian-and-thai-texting-culture\">P.S. “wkwkwkwk” and “5555555” are common ways of typing laughter in Indonesian and Thai texting culture.\u003C/h5>\n\u003Cdiv class=\"impact-images\" style=\"display: grid; grid-template-columns: 1fr 1fr 1fr; gap: 1rem;\">\n\u003Cfigure class=\"image-figure\">\u003Cimg __ASTRO_IMAGE_=\"{"src":"./dogfooding.png","alt":"Placing an order to test our flow","index":0}\">\u003Cfigcaption>Placing an order to test our flow\u003C/figcaption>\u003C/figure>\n\u003Cfigure class=\"image-figure\">\u003Cimg __ASTRO_IMAGE_=\"{"src":"./user-behaviour.png","alt":"Observing how they track orders","index":0}\">\u003Cfigcaption>Observing how they track orders\u003C/figcaption>\u003C/figure>\n\u003Cfigure class=\"image-figure\">\u003Cimg __ASTRO_IMAGE_=\"{"src":"./competitors.png","alt":"Checking out the competitors","index":0}\">\u003Cfigcaption>Checking out the competitors\u003C/figcaption>\u003C/figure>\n\u003C/div>\n\u003Ch3 id=\"managing-copy\">Managing Copy\u003C/h3>\n\u003Cp>Managing design files is relatively easy compared to managing multi-country copy. When we started supporting multiple languages, tools like Lokalise did not exist in our workflow. We relied entirely on Google Docs and Google Sheets.\u003C/p>\n\u003Cfigure class=\"image-figure\">\u003Cimg __ASTRO_IMAGE_=\"{"src":"./copy-doc.png","alt":"How we managed copy in Google Docs","index":0}\">\u003Cfigcaption>How we managed copy in Google Docs\u003C/figcaption>\u003C/figure>\n\u003Cp>When the product supported only Bahasa Indonesia, all GoBiz copy lived inside a single Google Doc. Over time, the document grew extremely long and slow. I had seen other teams use sheets for managing multi-language copy, so I worked with our UX writer, Lauditta, to create a template suited to our needs.\u003C/p>\n\u003Cp>Developers manage strings using “keys,” and we needed a way to map each key to the right line of copy. We realised too late how important this mapping was. Migrating retroactively meant spending a large amount of time copy-pasting, verifying strings, and searching through sheets.\u003C/p>\n\u003Cfigure class=\"image-figure\">\u003Cimg __ASTRO_IMAGE_=\"{"src":"./copy-sheets.png","alt":"How we managed copy in Google Sheets","index":0}\">\u003Cfigcaption>How we managed copy in Google Sheets\u003C/figcaption>\u003C/figure>\n\u003Cp>We also wanted screen references to help reviewers see copy in context. This was especially useful for UX writers in other countries, as well as QA and designers who did not speak the local languages. The release of Google Sheets’ “Insert picture in cell” feature was a huge help for this.\nGojek eventually moved to using \u003Ca href=\"https://lokalise.com\">Lokalise\u003C/a> for its copy management \u003Csup>\u003Ca href=\"#user-content-fn-1\" id=\"user-content-fnref-1\" data-footnote-ref=\"\" aria-describedby=\"footnote-label\">1\u003C/a>\u003C/sup>\u003C/p>\n\u003Ch3 id=\"learnings\">Learnings\u003C/h3>\n\u003Cul>\n\u003Cli>\n\u003Cp>Scaling GoBiz across Thailand, Vietnam, and Singapore taught me that localisation is never something you add after the product is built. Even after launch, every new feature needs to be evaluated through the lens of each country. The same care you put into the initial rollout has to continue, otherwise the product quietly drifts back toward the needs of the base market.\u003C/p>\n\u003C/li>\n\u003Cli>\n\u003Cp>There’s also an organizational reality that often gets ignored. Supporting multiple markets properly sometimes requires reshaping how teams work, how decisions are made, and who is involved in the roadmap. But these shifts take time, and they rarely get prioritised unless there is a clear business outcome tied to them.\nAt Gojek, this misalignment became clear. Each international market operated under its own brand and leadership, which meant we couldn’t consistently involve those teams in product planning. As a result, our roadmaps naturally skewed toward Indonesia, and we only built out some must-have features for other countries.\u003C/p>\n\u003C/li>\n\u003C/ul>\n\u003Ch3 id=\"closing-thoughts\">Closing thoughts\u003C/h3>\n\u003Cp>Gojek eventually exited Thailand and Vietnam, and its presence in Singapore today is minimal. Looking back, designing GoBiz for other countries was a highly rewarding and learning experience. I got to experience new cultures and work with people from different nationalities. Those lessons stayed with us long after the product lines, org charts, and roadmaps changed.\u003C/p>\n\u003Cfigure class=\"image-figure\">\u003Cimg __ASTRO_IMAGE_=\"{"src":"./thai-research.jpeg","alt":"The Gojek research team with a restaurant owner in Bangkok","index":0}\">\u003Cfigcaption>The Gojek research team with a restaurant owner in Bangkok\u003C/figcaption>\u003C/figure>\n\u003Csection data-footnotes=\"\" class=\"footnotes\">\u003Ch2 class=\"sr-only\" id=\"footnote-label\">Footnotes\u003C/h2>\n\u003Col>\n\u003Cli id=\"user-content-fn-1\">\n\u003Cp>You can read more about their International copy process on the blog by the Thai and Viet UX writer \u003Ca href=\"https://www.gojek.io/blog/language-no-bar-how-we-localise-ux-copies-at-gojek\">https://www.gojek.io/blog/language-no-bar-how-we-localise-ux-copies-at-gojek\u003C/a> \u003Ca href=\"#user-content-fnref-1\" data-footnote-backref=\"\" aria-label=\"Back to reference 1\" class=\"data-footnote-backref\">↩\u003C/a>\u003C/p>\n\u003C/li>\n\u003C/ol>\n\u003C/section>",{"headings":571,"localImagePaths":590,"remoteImagePaths":591,"frontmatter":592,"imagePaths":593},[572,575,576,580,583,586,589],{"depth":101,"slug":573,"text":574},"collaboration-and-organization","Collaboration and Organization",{"depth":101,"slug":410,"text":411},{"depth":577,"slug":578,"text":579},5,"ps-wkwkwkwk-and-5555555-are-common-ways-of-typing-laughter-in-indonesian-and-thai-texting-culture","P.S. “wkwkwkwk” and “5555555” are common ways of typing laughter in Indonesian and Thai texting culture.",{"depth":101,"slug":581,"text":582},"managing-copy","Managing Copy",{"depth":101,"slug":584,"text":585},"learnings","Learnings",{"depth":101,"slug":587,"text":588},"closing-thoughts","Closing thoughts",{"depth":117,"slug":118,"text":119},[558,559,560,561,562,563,564,565],[],{"title":552,"description":553,"year":480,"company":481,"image":566,"status":18},[558,559,560,561,562,563,564,565],"international/index.md","jiva-lite",{"id":595,"data":597,"body":602,"filePath":603,"assetImports":604,"digest":616,"rendered":617,"legacyId":683},{"title":598,"description":599,"image":600,"year":601,"company":374,"status":18},"Jiva Lite","Building a farmer-centric experience for buying Corn in rural Indonesia leveraging Whatsapp","__ASTRO_IMAGE_./jivalite.jpg","2024-2025","When I joined Jiva in 2022, we had been leveraging collectors in rural areas to facilitate our business model.\n\nThe harvest of a smallholder corn farmer is typically around 2.5k-3k tons. The economics of sending it to the buyer isn't economically viable for such a small quantity when you factor in labour cost & transport cost. Additionally the ability to evaluate quality at the farmer level is approximate.\nCollectors helped fill this gap by aggregating corn for dispatch from multiple farmers and using moisture meters to estimate quality of the corn. \n\nJiva’s business model was working with buyers to acquire purchase orders for the corn and coordinate with the collectors to dispatch to feedmills to get the best price. \nThis wasn't a disruptionary model. The concept of middlemen have always existed in agricultural systems. What was different was the concept of a single entity who's presence across provinces helped get better prices. \nOur Collectors earned commission for selling through us and our Farmers got the best price. \n\nBut the question remained.. **could we do even better?** and that's where Jiva Lite came in.\n\n\n## Challenge\n\n- One of the reasons we resorted to the micro-collector model was the technical literacy and mobile device penetration in rural Indonesia. Most farmers still used feature phones and many families just had a shared single device usually operated by the children or the wife. For those who did have a smartphone device, local storage and internet were critical constraints. \nIt didn't make sense for them to keep our apps on their phones across seasons and our churn data suggested that as well.\n\n- Our research had shown us that the Sahabat Jiva android app was a complex system compared to the real world way to buying and selling corn\n\n- From the business side, this meant our customer acqusition funnel was fairly expensive and with the commissions and price fluctuations of the market, the Gross Contribution (GC) that we earned per kg was far below what we wanted to be at.\n\n## Role\nMy role was a fluid one in the project where at the start I was leading the product design effort and managing stakeholders but eventually transitioned to co-owning the project and focusing on the digital marketing efforts over the 1 year of operation. \n\n## Solution\n\n![Early Jiva Lite app wireframes](./lite-wire.png \"Early Jiva Lite app wireframes\")\n\nThe first idea for Jiva Lite came out of our efforts to simplify the Sahabat Jiva App information architecture and workflows. But it took a few more months before we got a chance to try to solve this.\nThe overwhelming idea at that time was to make another app albeit a \"lite\" one. But a few of us felt that Whatsapp was the way to go. So I used Landbot to quickly prototype how a Whatsapp based flow would look like.\n\n#### Why Whatsapp? \nMeta has deep penetration in Indonesia. Indonesia doesnt have net neutrality laws and hence Meta, Google, Netflix, etc have mobile plans that enabled unlimited usage of their services. \nThis is one of the reason that Facebook and Whatsapp are the communication tool of choice in our users. This meant that \nwe could be assured that unlike a mobile app, our target audience would definitely have Whatsapp on their phones.\n\nAfter pitching this to leadership, we got buyin to use the Whatsapp flow as a pilot project to test out the viability of the Jiva Lite business model.\n\n#### Why was Jiva Lite different?\n- If Jiva Lite had to succeed then it should be economically viable while at the same time, it should not cannibalize our existing businesses. So the pricing logic we set was to keep our offering price at 100idr/kg less than the price we showed in our Sahabat Jiva app. \n- A recent tax exemption made it easy for us to operate at the small scale without needing unnecessary documentation like KTPs\n- For the first time (probably), small holders could sell direct to our buyers irrespective of the volume of their harvest and get paid within a few hours.\n- Meta Ads and Whatsapp QRs let users quickly get into our flow and check prices.\n\n### Building the MVP\nA small team got together to work on this part time. Designing the first flow to be as simple took a few iterations. We used Figma and FigJam a lot to align everyone and used Slack's inbuilt project management system to keep us on track.\nWeekly syncs were run to share progress with the larger group of stakeholders and monthly meetings with the CEO.\n\n![Figjam](./figjam.png \"Blueprinting\")\n\nOur first version was built using Whatsapp Flows and simplified the crop buying flow to just 3 steps; View Prices, Register and Send Truck. \nWe offered farmers the option of selecting between 3 feedmills based on their corn quality. Prices would be updated everyday.\n\n![Designs for the first release version on Figma](./jivalitev1.png \"Designs for the first release version on Figma\")\n\n### Preparing for Go-To-Market\n\n#### Onboarding internal teams:\nWe ran sessions with our field agents, customer service agents and marketing teams to onboard them onto the pilot project. I prepared an \"objection handling\" (a FAQ document) for CX team to use for answering any queries they may receive on their channels.\nSpeaking to our on-ground field agents helped us address their concerns about Jiva Lite and its impact on their operations.\n\n#### Selecting a region for piloting:\nWe had to negotiate with stakeholders for selecting regions due to concerns around our existing micro-collector density as well as time of the year and , we decided to go with the regencies closest to Makassar (South Sulawesi) ; Maros and Takalar. \nThis meant that the distances to be travelled by the farmers to our buyers were just a few hours away.\n\n#### On field marketing:\nWe got 1 field marketer, Erwin, on loan from the growth team for the efforts on on-ground canvassing by meeting farmer groups (Gapoktans).\n\n#### Jiva Lite Website:\nWe built a website so that we could provide a social proof that Jiva Lite was infact an offering from Jiva and not a scam. The website had prices which we manually updated and directed users to the Whatsapp number.\n\n\u003Ciframe width=\"560\" height=\"315\" src=\"https://www.youtube.com/embed/kCQByHg5kBI?si=MZe2Z8pwF-LeETQI\" title=\"YouTube video player\" frameborder=\"0\" allow=\"accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" allowfullscreen>\u003C/iframe>\n#### Doing things that don't scale:\nWe didn't build an in-flow way to add a farmer's bank account details. We resorted instead to use a manual system of getting the information from the farmer and getting CX team to add them to the system. This enabled us to ship faster and prevented user error from entering the wrong information. Where possible we pre-filled dummy data (e.g., user address) in the backend because we didnt want to build without valdiating our idea at this stage.\n\n## Post Launch of the MVP\n\n![Karan, Nav, Idul and Erwin meeting Saripuddin and other farmers](./jivalite-ground.png)\n\nWe launched the first version to production on August 7th, but we didnt get our first transaction till Nav, Karan, Idul and Erwin visited Mr. Saripuddin and convinced him to send the corn to our collection centre.\nOn August 23rd, Saripuddin (seen in the cover image) became the first farmer to have sent us the corn directly. That first transaction was the litmus test that our systems failed, however with Karan co-ordinating with Erwin, we somehow managed to pull through.\n\n>“I made over IDR 3,000,000 with my truck! I invite all my friends to send trucks using Jiva Lite.”\n> — Saripuddin\n\nSaripuddin immediately saw the value Jiva Lite brought to him and instantly became our ambassador convincing multiple farmers in his village to send us corn over the year.\nWithin a month, we hit the milestone of 50 MT and started thinking of the next iteration for Jiva Lite.\n\nPersonally, the first transaction was a feeling unlike any other that my body had experienced. That day, I was unable to act rationally because I was completely blown away by the fact that 14 days after release we secured our first farmer and he saw the value we were providing. \nThere was a lot of time and effort that went into reaching this exact point and it felt glorious.\n\n## Learnings from the Pilot\n#### Selling breakdown:\nWe made a simple google sheets template to generate a breakdown that we sent to every farmer which helped them understand how much they were earning and what was the quality of their corn.\n\n#### Backend Issues: \nWe had not handled user creation of churned/deleted users and this is what caused our first transaction to fail. (Murphy's Law, amirite?)\n\n![spiderkaran](./spiderkaran.png)\n\n#### Changing behaviour isn't easy:\nWhen farmers are used to dealing with a broken system, 'a too-good to be true' deal like Jiva Lite feels unrealistic. Furthermore, farmers and local buyers tend to have a personal relationship that isnt easy to overcome. At the end of the day, Jiva is an external entity while the buyer may be a neighbour, a relative or their money lender.\n\n#### Flow still complex:\nWithout our on-field agents, getting users to navigate Whatsapp Flows wasnt easy. Whatsapp flows may seem simple to us, but for our target users, they were complex. We realized that just because they used Facebook and Whatsapp didn't mean that they were familiar navigating similar interfaces. We needed to re-do our flow.\n\n## Building V2\n\nFrom a product point of view, we realised the following shortcomings:\n- The current implementation didn't enable us to A/B test our flow fast enough. \n- There was no way for us to intervene in the flow to guide users through it if required\n- There was no way to re-target and engage our users\n\nWe decided to look if any pre-existing solutions would help us solve this. After an evaluation of several Whatsapp business providers, we decided to go ahead with Landbot. We were already familiar with Landbot and it met all the above criteria.\n\n![A small portion of the Landbot flow](./landbot.png)\n\n**Product:** We re-designed the whole flow to be more like a chat-bot conversation as Landbot didnt support Whatsapp flows. This unfortunately took longer than we planned for and we finally released in early January 2025.\n\n**Marketing:** While we built, we went ahead and started Meta Ads and sending Price Update notifications to users in our funnel. We felt the ads themselves may not be efficient at communicating the concept of Jiva Lite so Tyo and Nav created a few marketing videos to help us.\n\n## Post V2\n\n- Once Landbot released interacting with our users in the funnel became easy. Our Research Coordinators stepped in to own the role of helping guide our users through the funnel. They did a wonderful job (outside of their job description) and even converted a few sales purely via chat.\n\n- Our successful pilot had enabled us to get a small budget approved which allowed us to hire a few more Jive Lite Operators (or JLO's as we called them) to do outreach on ground. We also explored using Sentinel satellite data to help our JLOs narrow their canvassing regions to those being harvested.\n\n![Shakti, Abhishek and I travelled to Gorontalo to figure out if we could launch Jiva Lite there](./gorontalo.jpeg)\n\n- We wanted to scale our solution to other regions so we started expanding to Lampung, Sumatra and Central Java and explored building out Jiva Lite for other crops like Rubber. \n\n- We ran A/B tests and simplified our flow futher. Designed different types of ads; static, videos, localized (Bugis and Bahasa Indonesia) and even engaged social media influencers.\n\n## Final thoughts\n\n- Our digital conversion (Ads - Whatsapp)was near 0 throughout the time of operation. We tried a lot of different approaches but weren't able to get any organic sale from the digital channel. \n\n- Almost 98% of our sales came via our JLOs. This meant scaling volume would directly need more feet on ground and that was seen as expensive.\n\n![Some ads we made for recruiting drossers](./dross.png)\n\n- We uncovered certain systemic issues like Farmer debt, Cash payments (to avoid tax), Drossing systems. We attempted to solve Drossing (separating Corn kernels from Cob) by procuring and \nrenting out drossing machines and even built a simple advertising based funnel to acquire potential customers for this service. But we couldn't solve for the others with our budgetary constraints and the high level of risk associated with them.\n\n- Though I have attempted to write out the project in detail, there is still a lot that I feel I have left out because building a product and running it takes you in so many different directions. You encounter various problems and inefficiencies, some you solve and others you can't.\nThe experience takes a lot out of you but in the end, I am glad I got the opportunity to build a product with this level of ownership.\n\n## Impact\nIn the one year of operation, we scaled Jiva Lite from 0 to 600 registered users who sold 4102 MT of corn. With a margin of 100 IDR/kg, we generated around 24k USD of gross contribution (Additional earnings from sales from trading this corn added an additional 200 IDR/kg, which has not been counted here)\n\n\u003Cdiv class=\"impact-images\" style=\"display: grid; grid-template-columns: 1fr 3fr; gap: 1rem;\">\n\n![](./jl-impact-1.png)\n\n![](./jl-impact-2.png)\n\n\u003C/div>\n\nBehaviourally though, we were about to bring meaningful improvements into the lives of the Farmers in a few provinces of South Sulawesi. Most farmers who transacted with us made about 2.5-3 million IDR(~$180 USD) more than they would otherwise.\nEven after Jiva Lite shut down, a few of the farmers continued to deal directly with the collection centres and improve their collective earnings.\n\n## Team\nIt takes a village to run a project like this and almost everyone in the Jiva design team contributed towards this project. I couldnt have done this without Karan owning the offline side, Nilesh running the product sprint and Shakti managing the JLO's. \n\nNav, Sai and Tyo worked on the initial flow designs and Niraj took the reigns towards the end, Kesha on the UX copy, and Karan and Bharath on the Service Design. \nAsa, Idul, Aldi and El contributed heavily on the User research side often intervening in our workflow to helpg guide our Farmers. \nAkshay Koul led the Engineering team with Kalpesh and Mani, Rajlakshmi on QA. DJ for Data Dashboards. Gada and Salma on Marketing. Aiko & Idayanti helped us from the CX team.\n\nAnd we really couldnt have done as much as we did without our Jiva Lite Operators Erwin, Firman, Rahma, Nur Faisyah, Ainun, Irsyam, Rajab & Fery.","src/content/work/jiva-lite/index.md",[605,606,607,608,609,610,611,612,613,614,615],"./lite-wire.png","./figjam.png","./jivalitev1.png","./jivalite-ground.png","./spiderkaran.png","./landbot.png","./gorontalo.jpeg","./dross.png","./jl-impact-1.png","./jl-impact-2.png","./jivalite.jpg","6fa70d643570d6eb",{"html":618,"metadata":619},"\u003Cp>When I joined Jiva in 2022, we had been leveraging collectors in rural areas to facilitate our business model.\u003C/p>\n\u003Cp>The harvest of a smallholder corn farmer is typically around 2.5k-3k tons. The economics of sending it to the buyer isn’t economically viable for such a small quantity when you factor in labour cost & transport cost. Additionally the ability to evaluate quality at the farmer level is approximate.\nCollectors helped fill this gap by aggregating corn for dispatch from multiple farmers and using moisture meters to estimate quality of the corn.\u003C/p>\n\u003Cp>Jiva’s business model was working with buyers to acquire purchase orders for the corn and coordinate with the collectors to dispatch to feedmills to get the best price.\nThis wasn’t a disruptionary model. The concept of middlemen have always existed in agricultural systems. What was different was the concept of a single entity who’s presence across provinces helped get better prices.\nOur Collectors earned commission for selling through us and our Farmers got the best price.\u003C/p>\n\u003Cp>But the question remained.. \u003Cstrong>could we do even better?\u003C/strong> and that’s where Jiva Lite came in.\u003C/p>\n\u003Ch2 id=\"challenge\">Challenge\u003C/h2>\n\u003Cul>\n\u003Cli>\n\u003Cp>One of the reasons we resorted to the micro-collector model was the technical literacy and mobile device penetration in rural Indonesia. Most farmers still used feature phones and many families just had a shared single device usually operated by the children or the wife. For those who did have a smartphone device, local storage and internet were critical constraints.\nIt didn’t make sense for them to keep our apps on their phones across seasons and our churn data suggested that as well.\u003C/p>\n\u003C/li>\n\u003Cli>\n\u003Cp>Our research had shown us that the Sahabat Jiva android app was a complex system compared to the real world way to buying and selling corn\u003C/p>\n\u003C/li>\n\u003Cli>\n\u003Cp>From the business side, this meant our customer acqusition funnel was fairly expensive and with the commissions and price fluctuations of the market, the Gross Contribution (GC) that we earned per kg was far below what we wanted to be at.\u003C/p>\n\u003C/li>\n\u003C/ul>\n\u003Ch2 id=\"role\">Role\u003C/h2>\n\u003Cp>My role was a fluid one in the project where at the start I was leading the product design effort and managing stakeholders but eventually transitioned to co-owning the project and focusing on the digital marketing efforts over the 1 year of operation.\u003C/p>\n\u003Ch2 id=\"solution\">Solution\u003C/h2>\n\u003Cfigure class=\"image-figure\">\u003Cimg __ASTRO_IMAGE_=\"{"src":"./lite-wire.png","alt":"Early Jiva Lite app wireframes","title":"Early Jiva Lite app wireframes","index":0}\">\u003Cfigcaption>Early Jiva Lite app wireframes\u003C/figcaption>\u003C/figure>\n\u003Cp>The first idea for Jiva Lite came out of our efforts to simplify the Sahabat Jiva App information architecture and workflows. But it took a few more months before we got a chance to try to solve this.\nThe overwhelming idea at that time was to make another app albeit a “lite” one. But a few of us felt that Whatsapp was the way to go. So I used Landbot to quickly prototype how a Whatsapp based flow would look like.\u003C/p>\n\u003Ch4 id=\"why-whatsapp\">Why Whatsapp?\u003C/h4>\n\u003Cp>Meta has deep penetration in Indonesia. Indonesia doesnt have net neutrality laws and hence Meta, Google, Netflix, etc have mobile plans that enabled unlimited usage of their services.\nThis is one of the reason that Facebook and Whatsapp are the communication tool of choice in our users. This meant that\nwe could be assured that unlike a mobile app, our target audience would definitely have Whatsapp on their phones.\u003C/p>\n\u003Cp>After pitching this to leadership, we got buyin to use the Whatsapp flow as a pilot project to test out the viability of the Jiva Lite business model.\u003C/p>\n\u003Ch4 id=\"why-was-jiva-lite-different\">Why was Jiva Lite different?\u003C/h4>\n\u003Cul>\n\u003Cli>If Jiva Lite had to succeed then it should be economically viable while at the same time, it should not cannibalize our existing businesses. So the pricing logic we set was to keep our offering price at 100idr/kg less than the price we showed in our Sahabat Jiva app.\u003C/li>\n\u003Cli>A recent tax exemption made it easy for us to operate at the small scale without needing unnecessary documentation like KTPs\u003C/li>\n\u003Cli>For the first time (probably), small holders could sell direct to our buyers irrespective of the volume of their harvest and get paid within a few hours.\u003C/li>\n\u003Cli>Meta Ads and Whatsapp QRs let users quickly get into our flow and check prices.\u003C/li>\n\u003C/ul>\n\u003Ch3 id=\"building-the-mvp\">Building the MVP\u003C/h3>\n\u003Cp>A small team got together to work on this part time. Designing the first flow to be as simple took a few iterations. We used Figma and FigJam a lot to align everyone and used Slack’s inbuilt project management system to keep us on track.\nWeekly syncs were run to share progress with the larger group of stakeholders and monthly meetings with the CEO.\u003C/p>\n\u003Cfigure class=\"image-figure\">\u003Cimg __ASTRO_IMAGE_=\"{"src":"./figjam.png","alt":"Figjam","title":"Blueprinting","index":0}\">\u003Cfigcaption>Figjam\u003C/figcaption>\u003C/figure>\n\u003Cp>Our first version was built using Whatsapp Flows and simplified the crop buying flow to just 3 steps; View Prices, Register and Send Truck.\nWe offered farmers the option of selecting between 3 feedmills based on their corn quality. Prices would be updated everyday.\u003C/p>\n\u003Cfigure class=\"image-figure\">\u003Cimg __ASTRO_IMAGE_=\"{"src":"./jivalitev1.png","alt":"Designs for the first release version on Figma","title":"Designs for the first release version on Figma","index":0}\">\u003Cfigcaption>Designs for the first release version on Figma\u003C/figcaption>\u003C/figure>\n\u003Ch3 id=\"preparing-for-go-to-market\">Preparing for Go-To-Market\u003C/h3>\n\u003Ch4 id=\"onboarding-internal-teams\">Onboarding internal teams:\u003C/h4>\n\u003Cp>We ran sessions with our field agents, customer service agents and marketing teams to onboard them onto the pilot project. I prepared an “objection handling” (a FAQ document) for CX team to use for answering any queries they may receive on their channels.\nSpeaking to our on-ground field agents helped us address their concerns about Jiva Lite and its impact on their operations.\u003C/p>\n\u003Ch4 id=\"selecting-a-region-for-piloting\">Selecting a region for piloting:\u003C/h4>\n\u003Cp>We had to negotiate with stakeholders for selecting regions due to concerns around our existing micro-collector density as well as time of the year and , we decided to go with the regencies closest to Makassar (South Sulawesi) ; Maros and Takalar.\nThis meant that the distances to be travelled by the farmers to our buyers were just a few hours away.\u003C/p>\n\u003Ch4 id=\"on-field-marketing\">On field marketing:\u003C/h4>\n\u003Cp>We got 1 field marketer, Erwin, on loan from the growth team for the efforts on on-ground canvassing by meeting farmer groups (Gapoktans).\u003C/p>\n\u003Ch4 id=\"jiva-lite-website\">Jiva Lite Website:\u003C/h4>\n\u003Cp>We built a website so that we could provide a social proof that Jiva Lite was infact an offering from Jiva and not a scam. The website had prices which we manually updated and directed users to the Whatsapp number.\u003C/p>\n\u003Ciframe width=\"560\" height=\"315\" src=\"https://www.youtube.com/embed/kCQByHg5kBI?si=MZe2Z8pwF-LeETQI\" title=\"YouTube video player\" frameborder=\"0\" allow=\"accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" allowfullscreen>\u003C/iframe>\n#### Doing things that don't scale:\nWe didn't build an in-flow way to add a farmer's bank account details. We resorted instead to use a manual system of getting the information from the farmer and getting CX team to add them to the system. This enabled us to ship faster and prevented user error from entering the wrong information. Where possible we pre-filled dummy data (e.g., user address) in the backend because we didnt want to build without valdiating our idea at this stage.\n\u003Ch2 id=\"post-launch-of-the-mvp\">Post Launch of the MVP\u003C/h2>\n\u003Cfigure class=\"image-figure\">\u003Cimg __ASTRO_IMAGE_=\"{"src":"./jivalite-ground.png","alt":"Karan, Nav, Idul and Erwin meeting Saripuddin and other farmers","index":0}\">\u003Cfigcaption>Karan, Nav, Idul and Erwin meeting Saripuddin and other farmers\u003C/figcaption>\u003C/figure>\n\u003Cp>We launched the first version to production on August 7th, but we didnt get our first transaction till Nav, Karan, Idul and Erwin visited Mr. Saripuddin and convinced him to send the corn to our collection centre.\nOn August 23rd, Saripuddin (seen in the cover image) became the first farmer to have sent us the corn directly. That first transaction was the litmus test that our systems failed, however with Karan co-ordinating with Erwin, we somehow managed to pull through.\u003C/p>\n\u003Cblockquote>\n\u003Cp>“I made over IDR 3,000,000 with my truck! I invite all my friends to send trucks using Jiva Lite.”\n— Saripuddin\u003C/p>\n\u003C/blockquote>\n\u003Cp>Saripuddin immediately saw the value Jiva Lite brought to him and instantly became our ambassador convincing multiple farmers in his village to send us corn over the year.\nWithin a month, we hit the milestone of 50 MT and started thinking of the next iteration for Jiva Lite.\u003C/p>\n\u003Cp>Personally, the first transaction was a feeling unlike any other that my body had experienced. That day, I was unable to act rationally because I was completely blown away by the fact that 14 days after release we secured our first farmer and he saw the value we were providing.\nThere was a lot of time and effort that went into reaching this exact point and it felt glorious.\u003C/p>\n\u003Ch2 id=\"learnings-from-the-pilot\">Learnings from the Pilot\u003C/h2>\n\u003Ch4 id=\"selling-breakdown\">Selling breakdown:\u003C/h4>\n\u003Cp>We made a simple google sheets template to generate a breakdown that we sent to every farmer which helped them understand how much they were earning and what was the quality of their corn.\u003C/p>\n\u003Ch4 id=\"backend-issues\">Backend Issues:\u003C/h4>\n\u003Cp>We had not handled user creation of churned/deleted users and this is what caused our first transaction to fail. (Murphy’s Law, amirite?)\u003C/p>\n\u003Cfigure class=\"image-figure\">\u003Cimg __ASTRO_IMAGE_=\"{"src":"./spiderkaran.png","alt":"spiderkaran","index":0}\">\u003Cfigcaption>spiderkaran\u003C/figcaption>\u003C/figure>\n\u003Ch4 id=\"changing-behaviour-isnt-easy\">Changing behaviour isn’t easy:\u003C/h4>\n\u003Cp>When farmers are used to dealing with a broken system, ‘a too-good to be true’ deal like Jiva Lite feels unrealistic. Furthermore, farmers and local buyers tend to have a personal relationship that isnt easy to overcome. At the end of the day, Jiva is an external entity while the buyer may be a neighbour, a relative or their money lender.\u003C/p>\n\u003Ch4 id=\"flow-still-complex\">Flow still complex:\u003C/h4>\n\u003Cp>Without our on-field agents, getting users to navigate Whatsapp Flows wasnt easy. Whatsapp flows may seem simple to us, but for our target users, they were complex. We realized that just because they used Facebook and Whatsapp didn’t mean that they were familiar navigating similar interfaces. We needed to re-do our flow.\u003C/p>\n\u003Ch2 id=\"building-v2\">Building V2\u003C/h2>\n\u003Cp>From a product point of view, we realised the following shortcomings:\u003C/p>\n\u003Cul>\n\u003Cli>The current implementation didn’t enable us to A/B test our flow fast enough.\u003C/li>\n\u003Cli>There was no way for us to intervene in the flow to guide users through it if required\u003C/li>\n\u003Cli>There was no way to re-target and engage our users\u003C/li>\n\u003C/ul>\n\u003Cp>We decided to look if any pre-existing solutions would help us solve this. After an evaluation of several Whatsapp business providers, we decided to go ahead with Landbot. We were already familiar with Landbot and it met all the above criteria.\u003C/p>\n\u003Cfigure class=\"image-figure\">\u003Cimg __ASTRO_IMAGE_=\"{"src":"./landbot.png","alt":"A small portion of the Landbot flow","index":0}\">\u003Cfigcaption>A small portion of the Landbot flow\u003C/figcaption>\u003C/figure>\n\u003Cp>\u003Cstrong>Product:\u003C/strong> We re-designed the whole flow to be more like a chat-bot conversation as Landbot didnt support Whatsapp flows. This unfortunately took longer than we planned for and we finally released in early January 2025.\u003C/p>\n\u003Cp>\u003Cstrong>Marketing:\u003C/strong> While we built, we went ahead and started Meta Ads and sending Price Update notifications to users in our funnel. We felt the ads themselves may not be efficient at communicating the concept of Jiva Lite so Tyo and Nav created a few marketing videos to help us.\u003C/p>\n\u003Ch2 id=\"post-v2\">Post V2\u003C/h2>\n\u003Cul>\n\u003Cli>\n\u003Cp>Once Landbot released interacting with our users in the funnel became easy. Our Research Coordinators stepped in to own the role of helping guide our users through the funnel. They did a wonderful job (outside of their job description) and even converted a few sales purely via chat.\u003C/p>\n\u003C/li>\n\u003Cli>\n\u003Cp>Our successful pilot had enabled us to get a small budget approved which allowed us to hire a few more Jive Lite Operators (or JLO’s as we called them) to do outreach on ground. We also explored using Sentinel satellite data to help our JLOs narrow their canvassing regions to those being harvested.\u003C/p>\n\u003C/li>\n\u003C/ul>\n\u003Cfigure class=\"image-figure\">\u003Cimg __ASTRO_IMAGE_=\"{"src":"./gorontalo.jpeg","alt":"Shakti, Abhishek and I travelled to Gorontalo to figure out if we could launch Jiva Lite there","index":0}\">\u003Cfigcaption>Shakti, Abhishek and I travelled to Gorontalo to figure out if we could launch Jiva Lite there\u003C/figcaption>\u003C/figure>\n\u003Cul>\n\u003Cli>\n\u003Cp>We wanted to scale our solution to other regions so we started expanding to Lampung, Sumatra and Central Java and explored building out Jiva Lite for other crops like Rubber.\u003C/p>\n\u003C/li>\n\u003Cli>\n\u003Cp>We ran A/B tests and simplified our flow futher. Designed different types of ads; static, videos, localized (Bugis and Bahasa Indonesia) and even engaged social media influencers.\u003C/p>\n\u003C/li>\n\u003C/ul>\n\u003Ch2 id=\"final-thoughts\">Final thoughts\u003C/h2>\n\u003Cul>\n\u003Cli>\n\u003Cp>Our digital conversion (Ads - Whatsapp)was near 0 throughout the time of operation. We tried a lot of different approaches but weren’t able to get any organic sale from the digital channel.\u003C/p>\n\u003C/li>\n\u003Cli>\n\u003Cp>Almost 98% of our sales came via our JLOs. This meant scaling volume would directly need more feet on ground and that was seen as expensive.\u003C/p>\n\u003C/li>\n\u003C/ul>\n\u003Cfigure class=\"image-figure\">\u003Cimg __ASTRO_IMAGE_=\"{"src":"./dross.png","alt":"Some ads we made for recruiting drossers","index":0}\">\u003Cfigcaption>Some ads we made for recruiting drossers\u003C/figcaption>\u003C/figure>\n\u003Cul>\n\u003Cli>\n\u003Cp>We uncovered certain systemic issues like Farmer debt, Cash payments (to avoid tax), Drossing systems. We attempted to solve Drossing (separating Corn kernels from Cob) by procuring and\nrenting out drossing machines and even built a simple advertising based funnel to acquire potential customers for this service. But we couldn’t solve for the others with our budgetary constraints and the high level of risk associated with them.\u003C/p>\n\u003C/li>\n\u003Cli>\n\u003Cp>Though I have attempted to write out the project in detail, there is still a lot that I feel I have left out because building a product and running it takes you in so many different directions. You encounter various problems and inefficiencies, some you solve and others you can’t.\nThe experience takes a lot out of you but in the end, I am glad I got the opportunity to build a product with this level of ownership.\u003C/p>\n\u003C/li>\n\u003C/ul>\n\u003Ch2 id=\"impact\">Impact\u003C/h2>\n\u003Cp>In the one year of operation, we scaled Jiva Lite from 0 to 600 registered users who sold 4102 MT of corn. With a margin of 100 IDR/kg, we generated around 24k USD of gross contribution (Additional earnings from sales from trading this corn added an additional 200 IDR/kg, which has not been counted here)\u003C/p>\n\u003Cdiv class=\"impact-images\" style=\"display: grid; grid-template-columns: 1fr 3fr; gap: 1rem;\">\n\u003Cfigure class=\"image-figure\">\u003Cimg __ASTRO_IMAGE_=\"{"src":"./jl-impact-1.png","alt":"","index":0}\">\u003C/figure>\n\u003Cfigure class=\"image-figure\">\u003Cimg __ASTRO_IMAGE_=\"{"src":"./jl-impact-2.png","alt":"","index":0}\">\u003C/figure>\n\u003C/div>\n\u003Cp>Behaviourally though, we were about to bring meaningful improvements into the lives of the Farmers in a few provinces of South Sulawesi. Most farmers who transacted with us made about 2.5-3 million IDR(~$180 USD) more than they would otherwise.\nEven after Jiva Lite shut down, a few of the farmers continued to deal directly with the collection centres and improve their collective earnings.\u003C/p>\n\u003Ch2 id=\"team\">Team\u003C/h2>\n\u003Cp>It takes a village to run a project like this and almost everyone in the Jiva design team contributed towards this project. I couldnt have done this without Karan owning the offline side, Nilesh running the product sprint and Shakti managing the JLO’s.\u003C/p>\n\u003Cp>Nav, Sai and Tyo worked on the initial flow designs and Niraj took the reigns towards the end, Kesha on the UX copy, and Karan and Bharath on the Service Design.\nAsa, Idul, Aldi and El contributed heavily on the User research side often intervening in our workflow to helpg guide our Farmers.\nAkshay Koul led the Engineering team with Kalpesh and Mani, Rajlakshmi on QA. DJ for Data Dashboards. Gada and Salma on Marketing. Aiko & Idayanti helped us from the CX team.\u003C/p>\n\u003Cp>And we really couldnt have done as much as we did without our Jiva Lite Operators Erwin, Firman, Rahma, Nur Faisyah, Ainun, Irsyam, Rajab & Fery.\u003C/p>",{"headings":620,"localImagePaths":679,"remoteImagePaths":680,"frontmatter":681,"imagePaths":682},[621,622,623,626,629,632,635,638,641,644,647,650,653,656,659,662,665,668,671,674,677,678],{"depth":117,"slug":395,"text":396},{"depth":117,"slug":392,"text":393},{"depth":117,"slug":624,"text":625},"solution","Solution",{"depth":143,"slug":627,"text":628},"why-whatsapp","Why Whatsapp?",{"depth":143,"slug":630,"text":631},"why-was-jiva-lite-different","Why was Jiva Lite different?",{"depth":101,"slug":633,"text":634},"building-the-mvp","Building the MVP",{"depth":101,"slug":636,"text":637},"preparing-for-go-to-market","Preparing for Go-To-Market",{"depth":143,"slug":639,"text":640},"onboarding-internal-teams","Onboarding internal teams:",{"depth":143,"slug":642,"text":643},"selecting-a-region-for-piloting","Selecting a region for piloting:",{"depth":143,"slug":645,"text":646},"on-field-marketing","On field marketing:",{"depth":143,"slug":648,"text":649},"jiva-lite-website","Jiva Lite Website:",{"depth":117,"slug":651,"text":652},"post-launch-of-the-mvp","Post Launch of the MVP",{"depth":117,"slug":654,"text":655},"learnings-from-the-pilot","Learnings from the Pilot",{"depth":143,"slug":657,"text":658},"selling-breakdown","Selling breakdown:",{"depth":143,"slug":660,"text":661},"backend-issues","Backend Issues:",{"depth":143,"slug":663,"text":664},"changing-behaviour-isnt-easy","Changing behaviour isn’t easy:",{"depth":143,"slug":666,"text":667},"flow-still-complex","Flow still complex:",{"depth":117,"slug":669,"text":670},"building-v2","Building V2",{"depth":117,"slug":672,"text":673},"post-v2","Post V2",{"depth":117,"slug":675,"text":676},"final-thoughts","Final thoughts",{"depth":117,"slug":431,"text":432},{"depth":117,"slug":434,"text":435},[605,606,607,608,609,610,611,612,613,614],[],{"title":598,"description":599,"year":601,"company":374,"image":615},[605,606,607,608,609,610,611,612,613,614],"jiva-lite/index.md","practo-pro",{"id":684,"data":686,"body":691,"filePath":692,"assetImports":693,"digest":695,"rendered":696,"legacyId":713},{"title":687,"description":688,"image":689,"year":690,"company":522,"status":261},"Practo Pro v1","Designing a unified mobile experience for providers using Practo products","__ASTRO_IMAGE_./practo-pro.png","2015-2016","## Overview\nAround Dec 2015, Practo had 3 mobile apps (Profile, Ray and Qikwell Pulse), each of which served a\nparticular purpose and worked independent of each other. Ray had been the mainstay app for most of\nPracto’s existence, while Profile was created to onboard doctors easily to the marketplace. The Qikwell\napp entered into this mix when we acquired their company earlier in 2015. Maintaining 3 separate\nmobile applications was an overhead for our internal teams as well as for our users. Thus **Project\nSingularity** was born.\n\n## Understanding the problem\nI was not involved in the user research phase of this project. I started work on this project at the\nconceptualisation stage. I worked with Jonathan during this phase. The three apps had different visual\nstyles and interactions and were structured as per their workflows. We needed to integrate these\ntogether without alienating their existing user base while also providing a scalable structure for the\nfuture.\n\n>Our vision was to build one app which needs to become the defacto app for doctors and eventually\nother provider segments\n\nBased on the research conducted, it was understood that a healthcare professional had the following\nneeds; Reputation, Productivity, Marketing, Money and Networking.\n\n[Personas for the unified app]\n\nThe new application had to cater to these needs if it had to be a central point of their life. However,\nthese needs vary as per the standing of the doctor. For e.g., a just graduated doctor would seek to\nlearn more from experienced doctors and would rarely have their own clinic while a doctor with 10\nyears of experience would be focussing on setting up her own business and getting more patients.\nFirst we needed to figure out the information architecture. We started putting all the existing parts\nof the various apps into an excel sheet to get an idea of what the pieces were and we also listed out\nfeatures that we felt could be integrated into the app at a later stage.\n\n[arriving at the information architecture]\n\nWe then started organising this based on how the users would be interacting with them. This is when\nwe started realising that some features seemed redundant while others were incomplete. We then\nlooked at how these various features would be impacted with respect to our user roles.\nWe looked at what are the requirements for a user to access our products as well as how the app\nwould be for users of any of the apps. Thus we were able to finalise the information architecture of the app.\n\n[final information architecture]\n\n## Concepts\nBased on this information architecture, I created few app concepts which we evaluated before\nfinalising on the one we would present to the stakeholders. The final concept was presented as an\nInVision prototype.\n\n[final information architecture]\n\nNotifications, Summary and Settings were concepts that we proposed as part of the new app.\n\n**Notifications:**\nAt that point of time, we did not have a single in-product channel of communication. Most\ncommunication happened either by emails, message bars or blocking dialogs. We wanted to change\nthis so we proposed a Notification Drawer. Further, we categorised as notifications as promotional and\ntransactional and provided users with a way to customise what kind of notifications they would like to\nreceive.\n\n**Summary:**\nThe Summary section was conceived as the newsfeed that would be the landing page for returning\nusers to jump directly into their workflow. It was comprised of stationary widgets and a refreshing\ninfinite newsfeed. The widgets were devised only for transactional products like Ray and Consult. The\nrest of the feed was to be powered by content from our other products like Healthfeed, Synapse and\nConsult.\n\n**Settings:**\nJust like notifications, this did not exist but was an obvious thing to build. We didn't want the user to\nexperience the internal product separations that existed.\nThere were many many meetings and back and forth before we could get everyone to agree that this\nwas the way we should go ahead. During the final discussion with the stakeholders, It was decided\nthat the workflow based structure was too futuristic and we would need to have an interface that lets\nour users understand our offerings. So we shifted to an app grid and widget landing as shown below\ninstead of a feed based landing.\n[final app navigation]\n\n## Detailing\nI led this effort with a team of 3 other designers. Hetang, Akshay and me worked to create the various\nproduct screens while Saloni was responsible for the theme and illustrations. Jonathan was overseeing\nthe entire operation and he gradually transitioned the responsibility to me.\nWe chose a clean content first approach that was becoming popular at that time. It was decided to\nmake the android and iOS apps similar in experience and independent of platforms. I set down the core\nguidelines that we would need to follow to align the various parts of the products. We decided to use\nthe system fonts i.e., Roboto on Android and SF on iOS, when available, for the design. To finalise on\nthe elements, we mocked up key screens within the product to understand and added to our\nguidelines when we found a component that was being used in multiple places.\n[singularity stickersheet]\n\nI created a stickersheet which functioned as a Master file for all the designers. We used a primitive\npeer review process so that the various parts would be consistent and present a coherent experience.\nOur core files would reside within Google Drive and we would work on our versions separately before I\nwould go through everyone’s files before replacing the versions in our core Drive folder.\n\n## Final screens\n\nDuring the implementation, I was the only designer assigned to the project and worked closely with the\ndevelopers to get things right which was how I earned the moniker ‘ceo’ from them. The android app\nshipped on June 25th, 2016 to 100% while the iOS app took another month before it was ready for\nrelease.\n\n\nThanks to Jonathan, Hetang, Akshay, Saloni and the rest of the Practo Partner team for coming\ntogether to bring this once-in-a-lifetime project to life.","src/content/work/practo-pro/index.md",[694],"./practo-pro.png","9357b996caae3882",{"html":697,"metadata":698},"\u003Ch2 id=\"overview\">Overview\u003C/h2>\n\u003Cp>Around Dec 2015, Practo had 3 mobile apps (Profile, Ray and Qikwell Pulse), each of which served a\nparticular purpose and worked independent of each other. Ray had been the mainstay app for most of\nPracto’s existence, while Profile was created to onboard doctors easily to the marketplace. The Qikwell\napp entered into this mix when we acquired their company earlier in 2015. Maintaining 3 separate\nmobile applications was an overhead for our internal teams as well as for our users. Thus \u003Cstrong>Project\nSingularity\u003C/strong> was born.\u003C/p>\n\u003Ch2 id=\"understanding-the-problem\">Understanding the problem\u003C/h2>\n\u003Cp>I was not involved in the user research phase of this project. I started work on this project at the\nconceptualisation stage. I worked with Jonathan during this phase. The three apps had different visual\nstyles and interactions and were structured as per their workflows. We needed to integrate these\ntogether without alienating their existing user base while also providing a scalable structure for the\nfuture.\u003C/p>\n\u003Cblockquote>\n\u003Cp>Our vision was to build one app which needs to become the defacto app for doctors and eventually\nother provider segments\u003C/p>\n\u003C/blockquote>\n\u003Cp>Based on the research conducted, it was understood that a healthcare professional had the following\nneeds; Reputation, Productivity, Marketing, Money and Networking.\u003C/p>\n\u003Cp>[Personas for the unified app]\u003C/p>\n\u003Cp>The new application had to cater to these needs if it had to be a central point of their life. However,\nthese needs vary as per the standing of the doctor. For e.g., a just graduated doctor would seek to\nlearn more from experienced doctors and would rarely have their own clinic while a doctor with 10\nyears of experience would be focussing on setting up her own business and getting more patients.\nFirst we needed to figure out the information architecture. We started putting all the existing parts\nof the various apps into an excel sheet to get an idea of what the pieces were and we also listed out\nfeatures that we felt could be integrated into the app at a later stage.\u003C/p>\n\u003Cp>[arriving at the information architecture]\u003C/p>\n\u003Cp>We then started organising this based on how the users would be interacting with them. This is when\nwe started realising that some features seemed redundant while others were incomplete. We then\nlooked at how these various features would be impacted with respect to our user roles.\nWe looked at what are the requirements for a user to access our products as well as how the app\nwould be for users of any of the apps. Thus we were able to finalise the information architecture of the app.\u003C/p>\n\u003Cp>[final information architecture]\u003C/p>\n\u003Ch2 id=\"concepts\">Concepts\u003C/h2>\n\u003Cp>Based on this information architecture, I created few app concepts which we evaluated before\nfinalising on the one we would present to the stakeholders. The final concept was presented as an\nInVision prototype.\u003C/p>\n\u003Cp>[final information architecture]\u003C/p>\n\u003Cp>Notifications, Summary and Settings were concepts that we proposed as part of the new app.\u003C/p>\n\u003Cp>\u003Cstrong>Notifications:\u003C/strong>\nAt that point of time, we did not have a single in-product channel of communication. Most\ncommunication happened either by emails, message bars or blocking dialogs. We wanted to change\nthis so we proposed a Notification Drawer. Further, we categorised as notifications as promotional and\ntransactional and provided users with a way to customise what kind of notifications they would like to\nreceive.\u003C/p>\n\u003Cp>\u003Cstrong>Summary:\u003C/strong>\nThe Summary section was conceived as the newsfeed that would be the landing page for returning\nusers to jump directly into their workflow. It was comprised of stationary widgets and a refreshing\ninfinite newsfeed. The widgets were devised only for transactional products like Ray and Consult. The\nrest of the feed was to be powered by content from our other products like Healthfeed, Synapse and\nConsult.\u003C/p>\n\u003Cp>\u003Cstrong>Settings:\u003C/strong>\nJust like notifications, this did not exist but was an obvious thing to build. We didn’t want the user to\nexperience the internal product separations that existed.\nThere were many many meetings and back and forth before we could get everyone to agree that this\nwas the way we should go ahead. During the final discussion with the stakeholders, It was decided\nthat the workflow based structure was too futuristic and we would need to have an interface that lets\nour users understand our offerings. So we shifted to an app grid and widget landing as shown below\ninstead of a feed based landing.\n[final app navigation]\u003C/p>\n\u003Ch2 id=\"detailing\">Detailing\u003C/h2>\n\u003Cp>I led this effort with a team of 3 other designers. Hetang, Akshay and me worked to create the various\nproduct screens while Saloni was responsible for the theme and illustrations. Jonathan was overseeing\nthe entire operation and he gradually transitioned the responsibility to me.\nWe chose a clean content first approach that was becoming popular at that time. It was decided to\nmake the android and iOS apps similar in experience and independent of platforms. I set down the core\nguidelines that we would need to follow to align the various parts of the products. We decided to use\nthe system fonts i.e., Roboto on Android and SF on iOS, when available, for the design. To finalise on\nthe elements, we mocked up key screens within the product to understand and added to our\nguidelines when we found a component that was being used in multiple places.\n[singularity stickersheet]\u003C/p>\n\u003Cp>I created a stickersheet which functioned as a Master file for all the designers. We used a primitive\npeer review process so that the various parts would be consistent and present a coherent experience.\nOur core files would reside within Google Drive and we would work on our versions separately before I\nwould go through everyone’s files before replacing the versions in our core Drive folder.\u003C/p>\n\u003Ch2 id=\"final-screens\">Final screens\u003C/h2>\n\u003Cp>During the implementation, I was the only designer assigned to the project and worked closely with the\ndevelopers to get things right which was how I earned the moniker ‘ceo’ from them. The android app\nshipped on June 25th, 2016 to 100% while the iOS app took another month before it was ready for\nrelease.\u003C/p>\n\u003Cp>Thanks to Jonathan, Hetang, Akshay, Saloni and the rest of the Practo Partner team for coming\ntogether to bring this once-in-a-lifetime project to life.\u003C/p>",{"headings":699,"localImagePaths":709,"remoteImagePaths":710,"frontmatter":711,"imagePaths":712},[700,701,702,705,708],{"depth":117,"slug":533,"text":534},{"depth":117,"slug":536,"text":537},{"depth":117,"slug":703,"text":704},"concepts","Concepts",{"depth":117,"slug":706,"text":707},"detailing","Detailing",{"depth":117,"slug":542,"text":543},[],[],{"title":687,"description":688,"year":690,"company":522,"image":694,"status":261},[],"practo-pro/index.md","sahabat-jiva-redesign",{"id":714,"data":716,"body":721,"filePath":722,"assetImports":723,"digest":725,"rendered":726,"legacyId":737},{"title":717,"description":718,"image":719,"year":720,"company":374,"status":261},"Fixing the Information Architecture of the Sahabat Jiva app","Redesigning the Sahabat Jiva Android app to fit the user's mental model and making it an intuitive experience","__ASTRO_IMAGE_./sjhome.webp","2022-2023","\u003C!-- Add your project content here -->\n\nWhen I joined Jiva in 2022, we had been leveraging collectors in rural areas to facilitate our business model.\n\nThe harvest of a smallholder corn farmer is typically around 2.5k-3k tons. The economics of sending it to the buyer isn't economically viable for such a small quantity when you factor in labour cost & transport cost. Additionally the ability to evaluate quality at the farmer level is approximate. \n\nCollectors helped fill this gap by aggregating corn for dispatch from multiple farmers and using moisture meters to estimate quality of the corn. \n\nJiva's business model was working with buyers to acquire purchase orders for the corn and coordinate with the collectors to dispatch to feedmills to get the best price.\n\nThis wasn't a disruptionary model. The concept of middlemen have always existed in agricultural systems. Jiva and it's Collectors operated at a country level scale that hadn't been tried before. \nThe Sahabat Jiva android app was used by our Collectors to manage their Harvest Procurement, their Input sales (In the Agriculture business; Seeds, Chemicals, Fertilizers, Equipments are collectively termed as Inputs) and view their Earnings.\n\n## Challenge\nJiva had started off in the pandemic and we hadnt got a chance to observe our users on the ground. Moving to mobile apps had led to most of our transactions now flowing through a digital channel. However our qualitative research, quickly showed us that our users really struggled with our app. \n\nThese could be narrowed down to\n1. The app's localization was a mess since there had not been a dedicated UX Writer who was involved in the app in the past which led to wrong translations, english terms in various pages and alien terminology being used.\n2. Every new user had to sit through multiple training sessions to learn how to use the various features on the app and there was no guarantee that they remembered how to use it.\n3. There were many disconnected user flows which needed to be followed in a particular sequence.\n4. The Collector's privileges on the application were managed by the province's branch manager and finance team due to the financial risk. This led to a non-uniform user experience and rogue user behaviour. \n\nBusiness-wise, this was leading to: \n\n1. High investment into canvassing, recruiting, training and onboarding \n2. Churn increasing Season-on-Season \n\nWhat this really meant was that the Android app was not the primary channel used by the Collector but more of a digitization system while most of the actual activity happened on Whatsapp. \n\nThere were even cases where our field agents (Activation Co-ordinators, Finance Co-ordinators) may actually be the operators of the application as it had been mandated to digitize every transaction that flows through the system.\n\nSo our data had been lying all this while about product adoption and usage.\n\n## Solution\n\nCan you really solve a problem this systemic and prevalent at so many different levels? \n\nFor sure! but could we do it at one go? No way. \n\nI advocated to break these problems into multiple phases and prioritized the Information Architecture overhaul as the first step.\n\n\n## Impact","src/content/work/sahabat-jiva-redesign/index.md",[724],"./sjhome.webp","4bbe7b5304d9dfb5",{"html":727,"metadata":728},"\u003C!-- Add your project content here -->\n\u003Cp>When I joined Jiva in 2022, we had been leveraging collectors in rural areas to facilitate our business model.\u003C/p>\n\u003Cp>The harvest of a smallholder corn farmer is typically around 2.5k-3k tons. The economics of sending it to the buyer isn’t economically viable for such a small quantity when you factor in labour cost & transport cost. Additionally the ability to evaluate quality at the farmer level is approximate.\u003C/p>\n\u003Cp>Collectors helped fill this gap by aggregating corn for dispatch from multiple farmers and using moisture meters to estimate quality of the corn.\u003C/p>\n\u003Cp>Jiva’s business model was working with buyers to acquire purchase orders for the corn and coordinate with the collectors to dispatch to feedmills to get the best price.\u003C/p>\n\u003Cp>This wasn’t a disruptionary model. The concept of middlemen have always existed in agricultural systems. Jiva and it’s Collectors operated at a country level scale that hadn’t been tried before.\nThe Sahabat Jiva android app was used by our Collectors to manage their Harvest Procurement, their Input sales (In the Agriculture business; Seeds, Chemicals, Fertilizers, Equipments are collectively termed as Inputs) and view their Earnings.\u003C/p>\n\u003Ch2 id=\"challenge\">Challenge\u003C/h2>\n\u003Cp>Jiva had started off in the pandemic and we hadnt got a chance to observe our users on the ground. Moving to mobile apps had led to most of our transactions now flowing through a digital channel. However our qualitative research, quickly showed us that our users really struggled with our app.\u003C/p>\n\u003Cp>These could be narrowed down to\u003C/p>\n\u003Col>\n\u003Cli>The app’s localization was a mess since there had not been a dedicated UX Writer who was involved in the app in the past which led to wrong translations, english terms in various pages and alien terminology being used.\u003C/li>\n\u003Cli>Every new user had to sit through multiple training sessions to learn how to use the various features on the app and there was no guarantee that they remembered how to use it.\u003C/li>\n\u003Cli>There were many disconnected user flows which needed to be followed in a particular sequence.\u003C/li>\n\u003Cli>The Collector’s privileges on the application were managed by the province’s branch manager and finance team due to the financial risk. This led to a non-uniform user experience and rogue user behaviour.\u003C/li>\n\u003C/ol>\n\u003Cp>Business-wise, this was leading to:\u003C/p>\n\u003Col>\n\u003Cli>High investment into canvassing, recruiting, training and onboarding\u003C/li>\n\u003Cli>Churn increasing Season-on-Season\u003C/li>\n\u003C/ol>\n\u003Cp>What this really meant was that the Android app was not the primary channel used by the Collector but more of a digitization system while most of the actual activity happened on Whatsapp.\u003C/p>\n\u003Cp>There were even cases where our field agents (Activation Co-ordinators, Finance Co-ordinators) may actually be the operators of the application as it had been mandated to digitize every transaction that flows through the system.\u003C/p>\n\u003Cp>So our data had been lying all this while about product adoption and usage.\u003C/p>\n\u003Ch2 id=\"solution\">Solution\u003C/h2>\n\u003Cp>Can you really solve a problem this systemic and prevalent at so many different levels?\u003C/p>\n\u003Cp>For sure! but could we do it at one go? No way.\u003C/p>\n\u003Cp>I advocated to break these problems into multiple phases and prioritized the Information Architecture overhaul as the first step.\u003C/p>\n\u003Ch2 id=\"impact\">Impact\u003C/h2>",{"headings":729,"localImagePaths":733,"remoteImagePaths":734,"frontmatter":735,"imagePaths":736},[730,731,732],{"depth":117,"slug":395,"text":396},{"depth":117,"slug":624,"text":625},{"depth":117,"slug":431,"text":432},[],[],{"title":717,"description":718,"year":720,"company":374,"image":724,"status":261},[],"sahabat-jiva-redesign/index.md","gojek",{"id":738,"data":740,"body":745,"filePath":746,"assetImports":747,"digest":763,"rendered":764,"legacyId":818},{"title":741,"description":742,"image":743,"year":744,"company":481,"status":18},"Designing for Gojek's Merchants","A brief overview of the work I did at GoBiz, Gojek's Merchant Platform","__ASTRO_IMAGE_./QRIS-gobiz.webp","2019-2021","### Role\nFrom 2019-2022, I worked on the merchant side of Gojek. GoBiz, Gojek's merchant platform, catered to 1M+ merchants across Indonesia, Vietnam(closed down in Sep 2024) and Thailand (sold to AirAsia in July 2021). The GoBiz Platform served GoFood merchants, GoPay Micro-merchants, as well as Enterprise merchants.\n\nI started off as the designer tasked with redesigning the GoBiz Android app and eventually moved to lead the design on the GoBiz Platform contributing towards the design of the GoBiz app and website, the Spots app and the Midtrans website. Over this period of time, the design team at GoBiz grew to 12 designers with the mergers and acquisitions of Midtrans, Kartuku and Moka POS before eventually breaking up pre-IPO. \n\n## GoBiz app\n[GO-RESTO](https://www.gojek.io/blog/whats-cooking-diving-into-kitchens-for-gobiz) ,released on 2017, was the app that our GO-FOOD partner merchants would use to receive orders, manage their catalogue and other restaurant information. But with the creation of the Merchant vertical, now GO-RESTO was to have a much larger vision. I joined the team as their designer in 2018 and worked on the redesign to convert it into a Super app. \n\nWhen we started working on this, we were worried that our users would feel isolated by this change in the interface which were driven by our business needs. \n\nSo as always, we began with the users.\n\nWe did a merchant segmentation study and then selected a few merchants from each of these segments to better understand their needs and came up with the following objectives.\n\n#### The objectives of the redesign were\n1. \u003Cins>Scalability:\u003C/ins> The main navigation (shown below) was a hamburger menu. As Go-RESTO had kept adding new features, adding them to the navbar as an when they were ready was how the product had scaled. However now we needed an information architecture that would work for GoFood, GoPay, and other merchants.\n2. \u003Cins>UI refresh:\u003C/ins> With the move, we rebranded from 'Go-Resto' to 'GoBiz' and adopted the newly minted [Asphalt 1.0](https://www.gojek.io/blog/of-dreams-deadlines-and-a-design-system) design language system. Due to the timing of the redesign, we were the first app in the Gojek ecosystem to be completely built on the new Asphalt design system. \n3. \u003Cins>Platformization\u003C/ins>: As Gojek grew, in-order to reduce duplication of efforts across multiple verticals, having a platform like GoBiz to build on would be beneficial for teams building for merchant partners like GoPay, GoMart, etc.\n\n#### Design Process:\n\n![Rough Sketches](rough-sketches.png)\n![One of the early iterations](Early-explorations.png)\n![Redesigned screens in Sketch for GoBiz](gobiz-v1.png)\n\nLooking at existing analytics helped me make decision on the information architecture. Once we finalised the navigation with all the stakeholders, we moved into iterating solutions before finalizing on the design.\n\n#### User testing:\nWe decided to have a pilot group of merchants for the release and the research team conducted a user diary research with them. \nAs we had not changed any major flow, we did not find any issues. \n\n![GoBiz Navigation; before and after](gobiz-nav.jpg)\n#### Learnings post release:\nOnce we released we started seeing feedback on the playstore asking us why we had hidden the customer contact. In the design, in the interest of showing the list of ordered items, we had moved the customer contact behind an overflow menu. Our analytics had shown low usage of this feature and we felt we could move it and add an onboarding tooltip for the merchants\n\nHowever these complaints persisted and we followed up with a few merchants to understand the problem. We learned that though the merchants did not end up calling via the app (because the app may not have the phone balance), they would want to see the customer phone number either to collect it for marketing purpose, to call from another number or to identify if its a fraud order. \n\nBased on the feedback, we took a call to re-instate the customer number back on the order details screen. \n![There's a lot more back and forth than we expected](gobiz-order.png)\n\n#### Impact:\n\n![GoBiz Ratings](GoBiz-ratings.webp)\n\nThe ratings of the GoBiz Super app saw a positive growth from 3.7 when we started work to 4.5+ post release[^1].\n\n## GoBiz Dashboard\nSometimes you just inherit a product that has not been loved. The GoBiz dashboard was built for enterprise merchants by forking an internal portal. The portal was built on an internal front end framework “[Tanjidor](https://en.wikipedia.org/wiki/Tanjidor)” and the designers used to design in the browser and this meant that there were no design files. This meant that there was a dependency on the existing designers. So we decided to pick it up as a design initiative.\n\n#### Objectives of the redesign:\n1. Reduce dependancy on the existing designer by\n2. Make the dashboard accessible via mobile web\n\n#### What we did:\nIn 2019, we (product design and research) conducted a heuristic evaluation to identify key issues. But post that due to issues with design bandwidth, the project was deprioritised. \n\nFast forward to 2020, Hendri joined us on the GoBiz team and I assigned him to start work on the GoBiz Dashboard redesign as a way to familiarise himself with the product. \n\nWe decided to design anything new with our web design system and not do it in the browser. Due to some luck, the “platformisation” of the Dashboard project got prioritised that quarter. However the PM was going to do it without a change to the UI. I convinced her to switch to the new UI. But given the sprint was beginning in 2 weeks, we were short of time. So we got a list of pages to work on a priority basis and started exploring. A lot of work was already done by Hendri however we had to now make the whole site look coherent. \n\n> You can arrive at a different output using the same design system.\n\nWe experimented with spacing and separators, navigation menu designs and modal overlays in the next 10 days to finalise the boilerplate for all the pages. Oh and yeah we also made it responsive. \n\n![](Gobiz-web.png)\n\n\n![After our redesign with Asphalt Web](Gobiz-web3.png)\n#### What we could not do:\n* Fix the information architecture issues in every page. \n* Figure out a table design that works well on mobile and desktop\n\n#### Outcome:\nThe GoMart designers were able to use the design system and build their module on the Dashboard with limited dependency on our team. \n\n\n## The Spots app\n![Left: Original, Right: Redesigned](spots.png)\nThe SPOTS app was a point of sales app on a Landi device. We were selling these to offline merchants to let them collect payment via offline modes like credit card, debit card and QR. \n\nThe app they were using was a reskinned version of the default app provided by Landi(image on the left). \n\nI was asked to help out with it and I worked on a refresh for the app on a short timeline(image on the right) \n\n![](QRIS-gobiz.webp)\n\nWe later integrated this into the POS application on the GoBiz app. \n\n# Midtrans\nIn 2020, the Midtrans merchant onboarding was prioritized due to an external collaboration with Whatsapp. \n\n![](midtrans-old.png)\n\nGiven the urgency, I decided to ask Riyadhi to help the team with the wireframes. Riyadhi had previously worked on the merchant onboarding flow for the GoBiz app and I felt this would help us speed up the process. \n\nWe had just completed the platformization exercise so Hendri and Firman were proficient with the new design system. The dev team too was confident that using the web design system was the best decision. This also made the flow mobile web compatible which was one of the identified merchant pain points. \n\n![](midtrans-onboarding-1.png)\n![](midtrans-onboarding-2.png)\n\nSo we shipped the new onboarding and saw lot of reduction in the drop offs. \n\n![](midtrans-onboarding-impact.png)\n\n### Outcome:\nThis project exposed most of the team to the ‘merchant onboarding’ problem space and a surprising side-effect of this was that project handover of the ‘corporate onboarding’ project could be handled by Hendri when Riyadhi was affected by Covid-19.\n\n#### Miscellaneous:\nI consulted on the GoBiz and the Midtrans marketing website. \n\n[^1]: Road to a Merchant Super App on the Gojek Blog https://www.gojek.io/blog/the-road-to-a-merchant-superapp","src/content/work/gojek/index.md",[748,749,750,751,752,753,754,755,756,757,758,759,760,761,762],"rough-sketches.png","Early-explorations.png","gobiz-v1.png","gobiz-nav.jpg","gobiz-order.png","GoBiz-ratings.webp","Gobiz-web.png","Gobiz-web3.png","spots.png","QRIS-gobiz.webp","midtrans-old.png","midtrans-onboarding-1.png","midtrans-onboarding-2.png","midtrans-onboarding-impact.png","./QRIS-gobiz.webp","525f12ee946b7d28",{"html":765,"metadata":766},"\u003Ch3 id=\"role\">Role\u003C/h3>\n\u003Cp>From 2019-2022, I worked on the merchant side of Gojek. GoBiz, Gojek’s merchant platform, catered to 1M+ merchants across Indonesia, Vietnam(closed down in Sep 2024) and Thailand (sold to AirAsia in July 2021). The GoBiz Platform served GoFood merchants, GoPay Micro-merchants, as well as Enterprise merchants.\u003C/p>\n\u003Cp>I started off as the designer tasked with redesigning the GoBiz Android app and eventually moved to lead the design on the GoBiz Platform contributing towards the design of the GoBiz app and website, the Spots app and the Midtrans website. Over this period of time, the design team at GoBiz grew to 12 designers with the mergers and acquisitions of Midtrans, Kartuku and Moka POS before eventually breaking up pre-IPO.\u003C/p>\n\u003Ch2 id=\"gobiz-app\">GoBiz app\u003C/h2>\n\u003Cp>\u003Ca href=\"https://www.gojek.io/blog/whats-cooking-diving-into-kitchens-for-gobiz\">GO-RESTO\u003C/a> ,released on 2017, was the app that our GO-FOOD partner merchants would use to receive orders, manage their catalogue and other restaurant information. But with the creation of the Merchant vertical, now GO-RESTO was to have a much larger vision. I joined the team as their designer in 2018 and worked on the redesign to convert it into a Super app.\u003C/p>\n\u003Cp>When we started working on this, we were worried that our users would feel isolated by this change in the interface which were driven by our business needs.\u003C/p>\n\u003Cp>So as always, we began with the users.\u003C/p>\n\u003Cp>We did a merchant segmentation study and then selected a few merchants from each of these segments to better understand their needs and came up with the following objectives.\u003C/p>\n\u003Ch4 id=\"the-objectives-of-the-redesign-were\">The objectives of the redesign were\u003C/h4>\n\u003Col>\n\u003Cli>\u003Cins>Scalability:\u003C/ins> The main navigation (shown below) was a hamburger menu. As Go-RESTO had kept adding new features, adding them to the navbar as an when they were ready was how the product had scaled. However now we needed an information architecture that would work for GoFood, GoPay, and other merchants.\u003C/li>\n\u003Cli>\u003Cins>UI refresh:\u003C/ins> With the move, we rebranded from ‘Go-Resto’ to ‘GoBiz’ and adopted the newly minted \u003Ca href=\"https://www.gojek.io/blog/of-dreams-deadlines-and-a-design-system\">Asphalt 1.0\u003C/a> design language system. Due to the timing of the redesign, we were the first app in the Gojek ecosystem to be completely built on the new Asphalt design system.\u003C/li>\n\u003Cli>\u003Cins>Platformization\u003C/ins>: As Gojek grew, in-order to reduce duplication of efforts across multiple verticals, having a platform like GoBiz to build on would be beneficial for teams building for merchant partners like GoPay, GoMart, etc.\u003C/li>\n\u003C/ol>\n\u003Ch4 id=\"design-process\">Design Process:\u003C/h4>\n\u003Cdiv class=\"image-figure-container\">\u003Cfigure class=\"image-figure\">\u003Cimg __ASTRO_IMAGE_=\"{"src":"rough-sketches.png","alt":"Rough Sketches","index":0}\">\u003Cfigcaption>Rough Sketches\u003C/figcaption>\u003C/figure>\u003Cfigure class=\"image-figure\">\u003Cimg __ASTRO_IMAGE_=\"{"src":"Early-explorations.png","alt":"One of the early iterations","index":0}\">\u003Cfigcaption>One of the early iterations\u003C/figcaption>\u003C/figure>\u003Cfigure class=\"image-figure\">\u003Cimg __ASTRO_IMAGE_=\"{"src":"gobiz-v1.png","alt":"Redesigned screens in Sketch for GoBiz","index":0}\">\u003Cfigcaption>Redesigned screens in Sketch for GoBiz\u003C/figcaption>\u003C/figure>\u003C/div>\n\u003Cp>Looking at existing analytics helped me make decision on the information architecture. Once we finalised the navigation with all the stakeholders, we moved into iterating solutions before finalizing on the design.\u003C/p>\n\u003Ch4 id=\"user-testing\">User testing:\u003C/h4>\n\u003Cp>We decided to have a pilot group of merchants for the release and the research team conducted a user diary research with them.\nAs we had not changed any major flow, we did not find any issues.\u003C/p>\n\u003Cfigure class=\"image-figure\">\u003Cimg __ASTRO_IMAGE_=\"{"src":"gobiz-nav.jpg","alt":"GoBiz Navigation; before and after","index":0}\">\u003Cfigcaption>GoBiz Navigation; before and after\u003C/figcaption>\u003C/figure>\n\u003Ch4 id=\"learnings-post-release\">Learnings post release:\u003C/h4>\n\u003Cp>Once we released we started seeing feedback on the playstore asking us why we had hidden the customer contact. In the design, in the interest of showing the list of ordered items, we had moved the customer contact behind an overflow menu. Our analytics had shown low usage of this feature and we felt we could move it and add an onboarding tooltip for the merchants\u003C/p>\n\u003Cp>However these complaints persisted and we followed up with a few merchants to understand the problem. We learned that though the merchants did not end up calling via the app (because the app may not have the phone balance), they would want to see the customer phone number either to collect it for marketing purpose, to call from another number or to identify if its a fraud order.\u003C/p>\n\u003Cfigure class=\"image-figure\">\u003Cimg __ASTRO_IMAGE_=\"{"src":"gobiz-order.png","alt":"There's a lot more back and forth than we expected","index":0}\">\u003Cfigcaption>There's a lot more back and forth than we expected\u003C/figcaption>\u003C/figure>\n\u003Ch4 id=\"impact\">Impact:\u003C/h4>\n\u003Cfigure class=\"image-figure\">\u003Cimg __ASTRO_IMAGE_=\"{"src":"GoBiz-ratings.webp","alt":"GoBiz Ratings","index":0}\">\u003Cfigcaption>GoBiz Ratings\u003C/figcaption>\u003C/figure>\n\u003Cp>The ratings of the GoBiz Super app saw a positive growth from 3.7 when we started work to 4.5+ post release\u003Csup>\u003Ca href=\"#user-content-fn-1\" id=\"user-content-fnref-1\" data-footnote-ref=\"\" aria-describedby=\"footnote-label\">1\u003C/a>\u003C/sup>.\u003C/p>\n\u003Ch2 id=\"gobiz-dashboard\">GoBiz Dashboard\u003C/h2>\n\u003Cp>Sometimes you just inherit a product that has not been loved. The GoBiz dashboard was built for enterprise merchants by forking an internal portal. The portal was built on an internal front end framework “\u003Ca href=\"https://en.wikipedia.org/wiki/Tanjidor\">Tanjidor\u003C/a>” and the designers used to design in the browser and this meant that there were no design files. This meant that there was a dependency on the existing designers. So we decided to pick it up as a design initiative.\u003C/p>\n\u003Ch4 id=\"objectives-of-the-redesign\">Objectives of the redesign:\u003C/h4>\n\u003Col>\n\u003Cli>Reduce dependancy on the existing designer by\u003C/li>\n\u003Cli>Make the dashboard accessible via mobile web\u003C/li>\n\u003C/ol>\n\u003Ch4 id=\"what-we-did\">What we did:\u003C/h4>\n\u003Cp>In 2019, we (product design and research) conducted a heuristic evaluation to identify key issues. But post that due to issues with design bandwidth, the project was deprioritised.\u003C/p>\n\u003Cp>Fast forward to 2020, Hendri joined us on the GoBiz team and I assigned him to start work on the GoBiz Dashboard redesign as a way to familiarise himself with the product.\u003C/p>\n\u003Cp>We decided to design anything new with our web design system and not do it in the browser. Due to some luck, the “platformisation” of the Dashboard project got prioritised that quarter. However the PM was going to do it without a change to the UI. I convinced her to switch to the new UI. But given the sprint was beginning in 2 weeks, we were short of time. So we got a list of pages to work on a priority basis and started exploring. A lot of work was already done by Hendri however we had to now make the whole site look coherent.\u003C/p>\n\u003Cblockquote>\n\u003Cp>You can arrive at a different output using the same design system.\u003C/p>\n\u003C/blockquote>\n\u003Cp>We experimented with spacing and separators, navigation menu designs and modal overlays in the next 10 days to finalise the boilerplate for all the pages. Oh and yeah we also made it responsive.\u003C/p>\n\u003Cfigure class=\"image-figure\">\u003Cimg __ASTRO_IMAGE_=\"{"src":"Gobiz-web.png","alt":"","index":0}\">\u003C/figure>\n\u003Cfigure class=\"image-figure\">\u003Cimg __ASTRO_IMAGE_=\"{"src":"Gobiz-web3.png","alt":"After our redesign with Asphalt Web","index":0}\">\u003Cfigcaption>After our redesign with Asphalt Web\u003C/figcaption>\u003C/figure>\n\u003Ch4 id=\"what-we-could-not-do\">What we could not do:\u003C/h4>\n\u003Cul>\n\u003Cli>Fix the information architecture issues in every page.\u003C/li>\n\u003Cli>Figure out a table design that works well on mobile and desktop\u003C/li>\n\u003C/ul>\n\u003Ch4 id=\"outcome\">Outcome:\u003C/h4>\n\u003Cp>The GoMart designers were able to use the design system and build their module on the Dashboard with limited dependency on our team.\u003C/p>\n\u003Ch2 id=\"the-spots-app\">The Spots app\u003C/h2>\n\u003Cfigure class=\"image-figure\">\u003Cimg __ASTRO_IMAGE_=\"{"src":"spots.png","alt":"Left: Original, Right: Redesigned","index":0}\">\u003Cfigcaption>Left: Original, Right: Redesigned\u003C/figcaption>\u003C/figure>\n\u003Cp>The app they were using was a reskinned version of the default app provided by Landi(image on the left).\u003C/p>\n\u003Cp>I was asked to help out with it and I worked on a refresh for the app on a short timeline(image on the right)\u003C/p>\n\u003Cfigure class=\"image-figure\">\u003Cimg __ASTRO_IMAGE_=\"{"src":"QRIS-gobiz.webp","alt":"","index":0}\">\u003C/figure>\n\u003Cp>We later integrated this into the POS application on the GoBiz app.\u003C/p>\n\u003Ch1 id=\"midtrans\">Midtrans\u003C/h1>\n\u003Cp>In 2020, the Midtrans merchant onboarding was prioritized due to an external collaboration with Whatsapp.\u003C/p>\n\u003Cfigure class=\"image-figure\">\u003Cimg __ASTRO_IMAGE_=\"{"src":"midtrans-old.png","alt":"","index":0}\">\u003C/figure>\n\u003Cp>Given the urgency, I decided to ask Riyadhi to help the team with the wireframes. Riyadhi had previously worked on the merchant onboarding flow for the GoBiz app and I felt this would help us speed up the process.\u003C/p>\n\u003Cp>We had just completed the platformization exercise so Hendri and Firman were proficient with the new design system. The dev team too was confident that using the web design system was the best decision. This also made the flow mobile web compatible which was one of the identified merchant pain points.\u003C/p>\n\u003Cdiv class=\"image-figure-container\">\u003Cfigure class=\"image-figure\">\u003Cimg __ASTRO_IMAGE_=\"{"src":"midtrans-onboarding-1.png","alt":"","index":0}\">\u003C/figure>\u003Cfigure class=\"image-figure\">\u003Cimg __ASTRO_IMAGE_=\"{"src":"midtrans-onboarding-2.png","alt":"","index":0}\">\u003C/figure>\u003C/div>\n\u003Cp>So we shipped the new onboarding and saw lot of reduction in the drop offs.\u003C/p>\n\u003Cfigure class=\"image-figure\">\u003Cimg __ASTRO_IMAGE_=\"{"src":"midtrans-onboarding-impact.png","alt":"","index":0}\">\u003C/figure>\n\u003Ch3 id=\"outcome-1\">Outcome:\u003C/h3>\n\u003Cp>This project exposed most of the team to the ‘merchant onboarding’ problem space and a surprising side-effect of this was that project handover of the ‘corporate onboarding’ project could be handled by Hendri when Riyadhi was affected by Covid-19.\u003C/p>\n\u003Ch4 id=\"miscellaneous\">Miscellaneous:\u003C/h4>\n\u003Cp>I consulted on the GoBiz and the Midtrans marketing website.\u003C/p>\n\u003Csection data-footnotes=\"\" class=\"footnotes\">\u003Ch2 class=\"sr-only\" id=\"footnote-label\">Footnotes\u003C/h2>\n\u003Col>\n\u003Cli id=\"user-content-fn-1\">\n\u003Cp>Road to a Merchant Super App on the Gojek Blog \u003Ca href=\"https://www.gojek.io/blog/the-road-to-a-merchant-superapp\">https://www.gojek.io/blog/the-road-to-a-merchant-superapp\u003C/a> \u003Ca href=\"#user-content-fnref-1\" data-footnote-backref=\"\" aria-label=\"Back to reference 1\" class=\"data-footnote-backref\">↩\u003C/a>\u003C/p>\n\u003C/li>\n\u003C/ol>\n\u003C/section>",{"headings":767,"localImagePaths":814,"remoteImagePaths":815,"frontmatter":816,"imagePaths":817},[768,769,772,775,778,781,784,786,789,792,795,798,801,804,808,810,813],{"depth":101,"slug":392,"text":393},{"depth":117,"slug":770,"text":771},"gobiz-app","GoBiz app",{"depth":143,"slug":773,"text":774},"the-objectives-of-the-redesign-were","The objectives of the redesign were",{"depth":143,"slug":776,"text":777},"design-process","Design Process:",{"depth":143,"slug":779,"text":780},"user-testing","User testing:",{"depth":143,"slug":782,"text":783},"learnings-post-release","Learnings post release:",{"depth":143,"slug":431,"text":785},"Impact:",{"depth":117,"slug":787,"text":788},"gobiz-dashboard","GoBiz Dashboard",{"depth":143,"slug":790,"text":791},"objectives-of-the-redesign","Objectives of the redesign:",{"depth":143,"slug":793,"text":794},"what-we-did","What we did:",{"depth":143,"slug":796,"text":797},"what-we-could-not-do","What we could not do:",{"depth":143,"slug":799,"text":800},"outcome","Outcome:",{"depth":117,"slug":802,"text":803},"the-spots-app","The Spots app",{"depth":805,"slug":806,"text":807},1,"midtrans","Midtrans",{"depth":101,"slug":809,"text":800},"outcome-1",{"depth":143,"slug":811,"text":812},"miscellaneous","Miscellaneous:",{"depth":117,"slug":118,"text":119},[748,749,750,751,752,753,754,755,756,757,758,759,760,761],[],{"title":741,"description":742,"year":744,"company":481,"status":18,"image":757},[748,749,750,751,752,753,754,755,756,757,758,759,760,761],"gojek/index.md"] \ No newline at end of file +[["Map",1,2,9,10,464,465],"meta::meta",["Map",3,4,5,6,7,8],"astro-config-digest","{\"root\":{},\"srcDir\":{},\"publicDir\":{},\"outDir\":{},\"cacheDir\":{},\"site\":\"https://kenneth.dsouza.im\",\"compressHTML\":true,\"base\":\"/\",\"trailingSlash\":\"ignore\",\"output\":\"static\",\"scopedStyleStrategy\":\"attribute\",\"build\":{\"format\":\"directory\",\"client\":{},\"server\":{},\"assets\":\"_astro\",\"serverEntry\":\"entry.mjs\",\"redirects\":true,\"inlineStylesheets\":\"auto\",\"concurrency\":1},\"server\":{\"open\":false,\"host\":false,\"port\":4321,\"streaming\":true,\"allowedHosts\":[]},\"redirects\":{},\"image\":{\"endpoint\":{\"route\":\"/_image\"},\"service\":{\"entrypoint\":\"astro/assets/services/sharp\",\"config\":{}},\"domains\":[],\"remotePatterns\":[],\"responsiveStyles\":false},\"devToolbar\":{\"enabled\":true},\"markdown\":{\"syntaxHighlight\":{\"type\":\"shiki\",\"excludeLangs\":[\"math\"]},\"shikiConfig\":{\"langs\":[],\"langAlias\":{},\"theme\":\"github-dark\",\"themes\":{},\"wrap\":false,\"transformers\":[]},\"remarkPlugins\":[null],\"rehypePlugins\":[[null,{\"className\":\"image-figure\"}]],\"remarkRehype\":{},\"gfm\":true,\"smartypants\":{\"backticks\":true,\"closingQuotes\":{\"double\":\"”\",\"single\":\"’\"},\"dashes\":true,\"ellipses\":true,\"openingQuotes\":{\"double\":\"“\",\"single\":\"‘\"},\"quotes\":true}},\"security\":{\"checkOrigin\":true,\"allowedDomains\":[],\"csp\":false,\"actionBodySizeLimit\":1048576,\"serverIslandBodySizeLimit\":1048576},\"env\":{\"schema\":{},\"validateSecrets\":false},\"prerenderConflictBehavior\":\"warn\",\"experimental\":{\"clientPrerender\":false,\"contentIntellisense\":false,\"chromeDevtoolsWorkspace\":false,\"svgo\":false,\"rustCompiler\":false,\"queuedRendering\":{\"enabled\":false}},\"legacy\":{\"collectionsBackwardsCompat\":false}}","astro-version","6.1.6","content-config-digest","19ec22f26952e973","work",["Map",11,12,91,92,125,126,164,165,244,245,276,277,321,322,412,413,441,442],"akar-design-system",{"id":11,"data":13,"body":20,"filePath":21,"assetImports":22,"digest":31,"rendered":32},{"title":14,"description":15,"image":16,"year":17,"company":18,"status":19},"Building the Akar Design System","The philosophy and design principles behind Jiva’s scalable design system","__ASTRO_IMAGE_./akar.webp","2023-2024","Jiva","published","Design systems often represent an aspirational milestone for product design teams. But they’re often seen as an all-or-nothing project — something that takes months of planning and effort, \nwhile day-to-day product delivery suffers. When everything is moving at breakneck speed, it feels risky to divert resources into building a design system. \n**But is it really?**\n\nIn early 2022, Jiva was deep in the throes of hyper-growth, onboarding new team members almost every week. The chaos hit every part of the company, and the design team wasn’t immune. \nWork was being duplicated across pods, our user experience was inconsistent, accessibility needs were being overlooked, and our app’s \nperformance was lagging behind.\nAt the time, we had a Figma-style guide, but it simply wasn’t enough. We needed more than a set of visual guidelines — we needed a \ncomprehensive design system that could help us keep up with the rapid growth without adding friction to the process. And yet, we faced a tough constraint: \nour design team was tiny (and growing), so we had to approach this in a _lean_ way.\n\n![A snapshot of our Figma Component Library Circa early 2022](styleguide.webp)\n\n\n## Role\nI led the effort on the design system and my responsibilities included managing with various stakeholders(product, engineering, qa), pitching ideas, \ndefining the design system tokens, identifying the right tools and libraries. Post implementation, my focus was towards evangelizing the design system, getting buyin for implementing it onto the various product roadmaps and \ntracking its usage within products.\n\n## Challenge\n\nWe set out with a clear set of goals for the design system:\n\n### Goals\n\n- **Scalability** \nLay a foundation that would allow Jiva to scale across platforms and countries.\n\n- **Speed** \nRemove friction in day-to-day work so designers could focus on designing, while product managers and developers knew exactly which components to use.\n\n- **Output quality** \nImprove the handoff process so what was designed could be built accurately.\n\n- **Accessibility** \nBring typography and color usage in line with minimum WCAG guidelines.\n\n- **Standardization** \nCreate a coherent, consistent feel across all our products, reinforcing a sense of trust and legitimacy.\n\n### Impact on our customers\n\n- **Familiarity** \nFamiliar patterns across products, reducing the learning curve.\n\n- **Readability** \nImproved readability for older MCs, with better support for built-in phone accessibility features.\n\n- **Performance** \nFaster, lighter apps through reduced duplication and a smaller overall app size.\n\n## Getting started\n\nIt's easy to write down what we wanted to achieve with our design system but we had 0 experience designing one. \n\nWe started by studying how well-known design systems such as Material Design, Shopify's Polaris, and Uber's Base were structured. \nWe analyzed their token structures, naming conventions, and the rationale behind their choices. We watched talks, talked to peers, read blog posts and then we got started.\n\n### Design Tokens\n\nDesign tokens represent the small, repeated design decisions that make up a design system's visual style. They replace static values, such as hex codes for color, with self-explanatory names. A token's value can be one of several things: a color, a typeface, a measurement, or even another token. \n\n![The way we envisioned our lean system to work inspired from Spotify’s Encore](design-system-philosophy.webp) [^1]\n\nWe chose **colour** and **typography** as tokens in our system. We chose only these tokens because they gave the team the autonomy to move fast while giving us the flexibility to maintain consistency where it mattered.\nAll without locking us into a rigid design expression. These tokens could be used to create design “atoms” and “molecules” across different platforms, allowing our \ncomponents to adapt naturally to each platform’s native constraints.\nThis flexibility was crucial. It allowed teams to move faster, design for different use cases, and scale without sacrificing brand coherence.\n\n>For example, in 2024, when we built react native apps by adopting [Paper](https://reactnativepaper.com/), our tokens could easily be ported to make Paper-based apps feel like a Jiva product. \n>In tools like Retool, we only ported over colour tokens because that’s all we needed to ensure visual consistency. \n>This token-driven flexibility became the key to scaling design without getting bogged down by unnecessary rigidity like uniformity of components.\n \n#### Typography\n\n![Old type vs New type](type.webp)\n\nFor Typography, we decided to lean on system defaults. On Android, by switching from [Mr. Eaves](https://fonts.adobe.com/fonts/mr-eaves-xl)(our brand font) to Roboto, we addressed the legibility issues we had previously\nfaced, particularly on budget Android devices. However, this wasn’t \na simple swap. We had to design a type scale that ensured our transition was seamless and consistent across various text elements, from headings to body text.\nfor this was taking several key UI screens and replacing text to see how we could map the new type styles to the old ones with minimal effect to the UI.\n\n#### Color\n\n![](color.webp)\n\nColour, on the other hand, posed a unique challenge. Our original primary colour (#0AB858), vibrant as it was, didn’t meet [WCAG](https://www.w3.org/WAI/standards-guidelines/wcag/) contrast requirements, especially for text on white or green backgrounds in smaller font sizes. We knew this was a dealbreaker for accessibility.\nAchieving the right contrast was tough — white on green rarely provides the necessary legibility, particularly on low-resolution displays. Finally with the help of \nEnvoy’s post on [building an accessible colour scheme](https://medium.com/envoy-design/how-to-design-an-accessible-color-scheme-4a13ca12c92b), [Stark’s handy plugin](https://www.figma.com/community/plugin/732603254453395948/stark-contrast-accessibility-checker) and [Tailwind Color Generator plugin](https://www.figma.com/community/plugin/1242548152689430610/tailwind-css-color-generator), we found a modified shade of green(#006E25) \nthat worked visually and was AA compliant. But colour wasn’t just about picking a new shade; \nwe also had to write detailed guidelines for how and where it should be used to maintain consistency and accessibility across our products.\n\n\n### Bringing it all together\nM3 [(Material Design 3)](https://m3.material.io) had just released and we loved the fresh new style it brought with it. Material Design is built around a ‘primary’ color making it easy for \npeople(read: devs) to adopt it. They provide you a [figma plugin](https://www.figma.com/community/plugin/1034969338659738588/material-theme-builder) to generate your color tokens but it lacks customization and is overly technical. \n\nMoreover, the way these tokens styled the components felt awkward to us. It did not fit our brand. So we decided to take control and create our own token system which we would map to these components.\n\nDuring further research, we learned that there's no standardization of naming conventions across companies—each has its own needs and preferences. This situation challenged us, as we're new to design tokens and struggled to decide which approach we can go ahead with. It was only when we watched [this talk from Schema 2021](https://www.youtube.com/watch?v=ylDed18OVdY) titled *\"Design tokens at Asana\"* by Jina Anne, \nAinsley Wagoner, and Ivy Wang that the solution finally dawned on us.\n\n>Color tokens need to be comprehensive enough to clearly describe their usage, yet concise enough to make it easy to determine which tokens to apply.\n\nWe took the ideas from the talk and aimed to create tokens that are direct and self-explanatory. Our goal was to make them easily understandable by all and avoid designers needing to refer back to documentation to use the system. \n\nAfter a lot of discussions, we implemented the following structure structure designed for clarity and ease of use. It wasn't perfect, but it worked with a little bit of documentation better than Material Design's approach.\n![Naming convention of Akar](naming.webp)\n1. \u003Cins>Property\u003C/ins> We start with what we call ‘property’, thus called because it defines what kind of element it is applied to; content, background or border. So for a primary button below, the color token for the text uses the content property while the colour of the button is represented by the background property.\n2. \u003Cins>Roles\u003C/ins> The ‘role’ aspect is where you start to identify the kind of component you are attempting to style. We use ‘Action’ for components that need the user to ‘act’ on them while ‘Highlight’ and ‘Interactive’ are used for communicating a system reaction to the user. We have ‘default’ for neutral colours and ‘decorative’ was introduced at a later point for components like badges and tags that needed to be visually appealing.\n3. \u003Cins>Priority\u003C/ins> Priority is used to optimize the visual hierarchy within the user interface, ensuring that the most important elements stand out and draw the user’s attention. By assigning different priority levels to components, we can guide users through the interface more intuitively, highlighting key actions, content, or information and making the overall experience more seamless and efficient.\n4. \u003Cins>Type\u003C/ins> Type is used to express the tone or meaning of an element, such as information, success, warning, error, or neutrality. These types are applied to components like buttons, banners, and toasts, as well as to elements like icons and text.\n5. \u003Cins>States\u003C/ins> States are visual indicators that communicate the current status or condition of a component or interactive element. They help users understand how an element is behaving at any given moment, such as whether it’s pressed, loading, selected, focused, or disabled.\n\n![How designers can use our tokens](how-to-tokens.webp)\n\n### The Final stretch\nIf your design system exists only in Figma, then its just a style guide. For a design system to be truly complete, it needs to exists outside of Figma and as a code library.\n\nWe were re-writing our Android Front end in Jetpack Compose and decided to merge the two efforts to implement our design system. \nWhile having self-explanatory token naming certainly makes designers' lives easier, by taking this direction of deviating from Material Design's conventions, we increased our developement effort. \nWe had to build a bridge to make our tokens compatible with material design. This wasn’t straightforward. Most big companies that we studied had UX engineering teams to help build such plugins for their use. \nWe came across [Amazon’s style dictionary](https://github.com/style-dictionary/style-dictionary) from [this talk by Doordash](https://www.youtube.com/watch?v=jgueTz72ZMQ&t=760s) and Atlassian’s inhouse plugin in [their schema talk](https://www.youtube.com/watch?v=m8ZSu9eCsQc&t=814s) \nand the popular figma plugin [Tokens Studio](https://tokens.studio). \n\n>So why did we still proceed with this approach? We prioritized ease of use, recognizing that the development work to implement this system is a one-time investment. \n>We believed that it was a worthwhile trade-off.\n\nIt wasn’t really all that straightforward. We were only able to make it work by closely working with our developers(Sivan and Vishnu).\n\n#### Our Approach\nWe used Tokens Studio to export our tokens from Figma as JSON and the devs had to figure out how to translate this to a setup that can be consumed by our apps. \nThe aim was to make sure that the designers had the freedom to take decisions while the devs wouldn’t have to break a sweat in integrating them into the apps.\n\nOur apps are on the Jetpack Compose framework and this meant that the design language and consumption were slightly different from Android’s traditional XML. \nWe found [Lukas Opperman’s Design Token Transformer](https://github.com/lukasoppermann/design-token-transformer) to be a great tool for porting tokens to Web, \niOS and Android’s XML system but we needed something that would support Jetpack Compose as well. So we forked this repo and decided to add support for Jetpack Compose. \nThe overall idea was straightforward. The engine should take in the \nJSON file as the input, and spit out Compose Theming files that can be imported onto your project directly and the devs wouldn’t have to worry too much about the setup.\n\n\u003Cimg src=\"/images/tokens-figma.gif\" alt=\"Tokens in Figma\" style=\"border-radius: 8px;\" />\n\nAnd that’s how we placed the final piece of our design system jigsaw puzzle.\n\n\n## Presenting the Akar Design Sytem: \nAll this while, we had been working hard on the system but we realised we didn’t have a name for our design system. We wanted something that resonated with the agritech space we were in, so we began brainstorming. Finally, with the help of Notion AI, we chose to go with Akar.\n\nAkar, derived from the Bahasa Indonesia word for ‘root,’ perfectly reflects the role of our design system in providing a solid foundation for building products. It’s also symbolic, as Indonesia is where our products first took shape, making the name a meaningful nod to our origins.\n\n![Akar on our screens](akar-screens.webp)\n\n### Post-launch\nA design system's success is measure by its penetration and implementation by the team. Building it in isolation is bound to fail. Throughout the process, we spent time\ninvolving the dev and design teams. We did this by \n- We created Slack channels to communicate updates and invite collaboration. \n- We presented the system at an org-wide ‘Lunch and Learn’ (an org level initiative to talk about work) to bring awareness to the initiative.\n- To track adoption, we created pod-specific slack channels for devs and designers to have discussions around implementation and we set up a Notion page to track migration and adoption.\n- We created a [documentation site](https://zeroheight.com/5c1eb1bd5/p/73e674-akar-design-system) which devs and designers could refer to. \n\n## Impact\n\nHaving Akar, helped us scale faster and build and redesign new apps and products in the Jiva ecosystem. As of September 2025, it was used across various platforms and products at Jiva, \nsupporting our 3 core Android mobile apps (Sahabat Jiva, Jiva Petani, Jiva Agro). We also extended our tokens to be used in our internal React Native apps (Jiva Sales, Field Agent App), as well as internal tools built using Retool.\n\nImplementation of the code components was a slow process as getting it prioritised over business needs was hard. \nWe were able to get like 80% of the product verticals to completely use our libarary within the first 12 months. \n\n## Team\nTyo (who had just joined the team) worked with me and built out the Figma token and components system. Nav, (head of design), helped us take decisions\naround the direction of the design components. Sivan and VIshnu were the devs who we collaborated closely to get the code components out in production. \n\n[^1]: **Spotify's Encore** https://spotify.design/article/can-i-get-an-encore-spotifys-design-system-three-years-on","src/content/work/akar-design-system/index.md",[23,24,25,26,27,28,29,30],"styleguide.webp","design-system-philosophy.webp","type.webp","color.webp","naming.webp","how-to-tokens.webp","akar-screens.webp","./akar.webp","bde199fee499ec2f",{"html":33,"metadata":34},"\u003Cp>Design systems often represent an aspirational milestone for product design teams. But they’re often seen as an all-or-nothing project — something that takes months of planning and effort,\nwhile day-to-day product delivery suffers. When everything is moving at breakneck speed, it feels risky to divert resources into building a design system.\n\u003Cstrong>But is it really?\u003C/strong>\u003C/p>\n\u003Cp>In early 2022, Jiva was deep in the throes of hyper-growth, onboarding new team members almost every week. The chaos hit every part of the company, and the design team wasn’t immune.\nWork was being duplicated across pods, our user experience was inconsistent, accessibility needs were being overlooked, and our app’s\nperformance was lagging behind.\nAt the time, we had a Figma-style guide, but it simply wasn’t enough. We needed more than a set of visual guidelines — we needed a\ncomprehensive design system that could help us keep up with the rapid growth without adding friction to the process. And yet, we faced a tough constraint:\nour design team was tiny (and growing), so we had to approach this in a \u003Cem>lean\u003C/em> way.\u003C/p>\n\u003Cfigure class=\"image-figure\">\u003Cimg __ASTRO_IMAGE_=\"{"src":"styleguide.webp","alt":"A snapshot of our Figma Component Library Circa early 2022","index":0}\">\u003Cfigcaption>A snapshot of our Figma Component Library Circa early 2022\u003C/figcaption>\u003C/figure>\n\u003Ch2 id=\"role\">Role\u003C/h2>\n\u003Cp>I led the effort on the design system and my responsibilities included managing with various stakeholders(product, engineering, qa), pitching ideas,\ndefining the design system tokens, identifying the right tools and libraries. Post implementation, my focus was towards evangelizing the design system, getting buyin for implementing it onto the various product roadmaps and\ntracking its usage within products.\u003C/p>\n\u003Ch2 id=\"challenge\">Challenge\u003C/h2>\n\u003Cp>We set out with a clear set of goals for the design system:\u003C/p>\n\u003Ch3 id=\"goals\">Goals\u003C/h3>\n\u003Cul>\n\u003Cli>\n\u003Cp>\u003Cstrong>Scalability\u003C/strong>\u003Cbr>\nLay a foundation that would allow Jiva to scale across platforms and countries.\u003C/p>\n\u003C/li>\n\u003Cli>\n\u003Cp>\u003Cstrong>Speed\u003C/strong>\u003Cbr>\nRemove friction in day-to-day work so designers could focus on designing, while product managers and developers knew exactly which components to use.\u003C/p>\n\u003C/li>\n\u003Cli>\n\u003Cp>\u003Cstrong>Output quality\u003C/strong>\u003Cbr>\nImprove the handoff process so what was designed could be built accurately.\u003C/p>\n\u003C/li>\n\u003Cli>\n\u003Cp>\u003Cstrong>Accessibility\u003C/strong>\u003Cbr>\nBring typography and color usage in line with minimum WCAG guidelines.\u003C/p>\n\u003C/li>\n\u003Cli>\n\u003Cp>\u003Cstrong>Standardization\u003C/strong>\u003Cbr>\nCreate a coherent, consistent feel across all our products, reinforcing a sense of trust and legitimacy.\u003C/p>\n\u003C/li>\n\u003C/ul>\n\u003Ch3 id=\"impact-on-our-customers\">Impact on our customers\u003C/h3>\n\u003Cul>\n\u003Cli>\n\u003Cp>\u003Cstrong>Familiarity\u003C/strong>\u003Cbr>\nFamiliar patterns across products, reducing the learning curve.\u003C/p>\n\u003C/li>\n\u003Cli>\n\u003Cp>\u003Cstrong>Readability\u003C/strong>\u003Cbr>\nImproved readability for older MCs, with better support for built-in phone accessibility features.\u003C/p>\n\u003C/li>\n\u003Cli>\n\u003Cp>\u003Cstrong>Performance\u003C/strong>\u003Cbr>\nFaster, lighter apps through reduced duplication and a smaller overall app size.\u003C/p>\n\u003C/li>\n\u003C/ul>\n\u003Ch2 id=\"getting-started\">Getting started\u003C/h2>\n\u003Cp>It’s easy to write down what we wanted to achieve with our design system but we had 0 experience designing one.\u003C/p>\n\u003Cp>We started by studying how well-known design systems such as Material Design, Shopify’s Polaris, and Uber’s Base were structured.\nWe analyzed their token structures, naming conventions, and the rationale behind their choices. We watched talks, talked to peers, read blog posts and then we got started.\u003C/p>\n\u003Ch3 id=\"design-tokens\">Design Tokens\u003C/h3>\n\u003Cp>Design tokens represent the small, repeated design decisions that make up a design system’s visual style. They replace static values, such as hex codes for color, with self-explanatory names. A token’s value can be one of several things: a color, a typeface, a measurement, or even another token.\u003C/p>\n\u003Cfigure class=\"image-figure\">\u003Cimg __ASTRO_IMAGE_=\"{"src":"design-system-philosophy.webp","alt":"The way we envisioned our lean system to work inspired from Spotify’s Encore","index":0}\">\u003Cfigcaption>The way we envisioned our lean system to work inspired from Spotify’s Encore\u003C/figcaption>\u003C/figure>\n\u003Cp>We chose \u003Cstrong>colour\u003C/strong> and \u003Cstrong>typography\u003C/strong> as tokens in our system. We chose only these tokens because they gave the team the autonomy to move fast while giving us the flexibility to maintain consistency where it mattered.\nAll without locking us into a rigid design expression. These tokens could be used to create design “atoms” and “molecules” across different platforms, allowing our\ncomponents to adapt naturally to each platform’s native constraints.\nThis flexibility was crucial. It allowed teams to move faster, design for different use cases, and scale without sacrificing brand coherence.\u003C/p>\n\u003Cblockquote>\n\u003Cp>For example, in 2024, when we built react native apps by adopting \u003Ca href=\"https://reactnativepaper.com/\">Paper\u003C/a>, our tokens could easily be ported to make Paper-based apps feel like a Jiva product.\nIn tools like Retool, we only ported over colour tokens because that’s all we needed to ensure visual consistency.\nThis token-driven flexibility became the key to scaling design without getting bogged down by unnecessary rigidity like uniformity of components.\u003C/p>\n\u003C/blockquote>\n\u003Ch4 id=\"typography\">Typography\u003C/h4>\n\u003Cfigure class=\"image-figure\">\u003Cimg __ASTRO_IMAGE_=\"{"src":"type.webp","alt":"Old type vs New type","index":0}\">\u003Cfigcaption>Old type vs New type\u003C/figcaption>\u003C/figure>\n\u003Cp>For Typography, we decided to lean on system defaults. On Android, by switching from \u003Ca href=\"https://fonts.adobe.com/fonts/mr-eaves-xl\">Mr. Eaves\u003C/a>(our brand font) to Roboto, we addressed the legibility issues we had previously\nfaced, particularly on budget Android devices. However, this wasn’t\na simple swap. We had to design a type scale that ensured our transition was seamless and consistent across various text elements, from headings to body text.\nfor this was taking several key UI screens and replacing text to see how we could map the new type styles to the old ones with minimal effect to the UI.\u003C/p>\n\u003Ch4 id=\"color\">Color\u003C/h4>\n\u003Cfigure class=\"image-figure\">\u003Cimg __ASTRO_IMAGE_=\"{"src":"color.webp","alt":"","index":0}\">\u003C/figure>\n\u003Cp>Colour, on the other hand, posed a unique challenge. Our original primary colour (#0AB858), vibrant as it was, didn’t meet \u003Ca href=\"https://www.w3.org/WAI/standards-guidelines/wcag/\">WCAG\u003C/a> contrast requirements, especially for text on white or green backgrounds in smaller font sizes. We knew this was a dealbreaker for accessibility.\nAchieving the right contrast was tough — white on green rarely provides the necessary legibility, particularly on low-resolution displays. Finally with the help of\nEnvoy’s post on \u003Ca href=\"https://medium.com/envoy-design/how-to-design-an-accessible-color-scheme-4a13ca12c92b\">building an accessible colour scheme\u003C/a>, \u003Ca href=\"https://www.figma.com/community/plugin/732603254453395948/stark-contrast-accessibility-checker\">Stark’s handy plugin\u003C/a> and \u003Ca href=\"https://www.figma.com/community/plugin/1242548152689430610/tailwind-css-color-generator\">Tailwind Color Generator plugin\u003C/a>, we found a modified shade of green(#006E25)\nthat worked visually and was AA compliant. But colour wasn’t just about picking a new shade;\nwe also had to write detailed guidelines for how and where it should be used to maintain consistency and accessibility across our products.\u003C/p>\n\u003Ch3 id=\"bringing-it-all-together\">Bringing it all together\u003C/h3>\n\u003Cp>M3 \u003Ca href=\"https://m3.material.io\">(Material Design 3)\u003C/a> had just released and we loved the fresh new style it brought with it. Material Design is built around a ‘primary’ color making it easy for\npeople(read: devs) to adopt it. They provide you a \u003Ca href=\"https://www.figma.com/community/plugin/1034969338659738588/material-theme-builder\">figma plugin\u003C/a> to generate your color tokens but it lacks customization and is overly technical.\u003C/p>\n\u003Cp>Moreover, the way these tokens styled the components felt awkward to us. It did not fit our brand. So we decided to take control and create our own token system which we would map to these components.\u003C/p>\n\u003Cp>During further research, we learned that there’s no standardization of naming conventions across companies—each has its own needs and preferences. This situation challenged us, as we’re new to design tokens and struggled to decide which approach we can go ahead with. It was only when we watched \u003Ca href=\"https://www.youtube.com/watch?v=ylDed18OVdY\">this talk from Schema 2021\u003C/a> titled \u003Cem>“Design tokens at Asana”\u003C/em> by Jina Anne,\nAinsley Wagoner, and Ivy Wang that the solution finally dawned on us.\u003C/p>\n\u003Cblockquote>\n\u003Cp>Color tokens need to be comprehensive enough to clearly describe their usage, yet concise enough to make it easy to determine which tokens to apply.\u003C/p>\n\u003C/blockquote>\n\u003Cp>We took the ideas from the talk and aimed to create tokens that are direct and self-explanatory. Our goal was to make them easily understandable by all and avoid designers needing to refer back to documentation to use the system.\u003C/p>\n\u003Cfigure class=\"image-figure\">\u003Cimg __ASTRO_IMAGE_=\"{"src":"naming.webp","alt":"Naming convention of Akar","index":0}\">\u003Cfigcaption>Naming convention of Akar\u003C/figcaption>\u003C/figure>\n\u003Col>\n\u003Cli>\u003Cins>Property\u003C/ins> We start with what we call ‘property’, thus called because it defines what kind of element it is applied to; content, background or border. So for a primary button below, the color token for the text uses the content property while the colour of the button is represented by the background property.\u003C/li>\n\u003Cli>\u003Cins>Roles\u003C/ins> The ‘role’ aspect is where you start to identify the kind of component you are attempting to style. We use ‘Action’ for components that need the user to ‘act’ on them while ‘Highlight’ and ‘Interactive’ are used for communicating a system reaction to the user. We have ‘default’ for neutral colours and ‘decorative’ was introduced at a later point for components like badges and tags that needed to be visually appealing.\u003C/li>\n\u003Cli>\u003Cins>Priority\u003C/ins> Priority is used to optimize the visual hierarchy within the user interface, ensuring that the most important elements stand out and draw the user’s attention. By assigning different priority levels to components, we can guide users through the interface more intuitively, highlighting key actions, content, or information and making the overall experience more seamless and efficient.\u003C/li>\n\u003Cli>\u003Cins>Type\u003C/ins> Type is used to express the tone or meaning of an element, such as information, success, warning, error, or neutrality. These types are applied to components like buttons, banners, and toasts, as well as to elements like icons and text.\u003C/li>\n\u003Cli>\u003Cins>States\u003C/ins> States are visual indicators that communicate the current status or condition of a component or interactive element. They help users understand how an element is behaving at any given moment, such as whether it’s pressed, loading, selected, focused, or disabled.\u003C/li>\n\u003C/ol>\n\u003Cfigure class=\"image-figure\">\u003Cimg __ASTRO_IMAGE_=\"{"src":"how-to-tokens.webp","alt":"How designers can use our tokens","index":0}\">\u003Cfigcaption>How designers can use our tokens\u003C/figcaption>\u003C/figure>\n\u003Ch3 id=\"the-final-stretch\">The Final stretch\u003C/h3>\n\u003Cp>If your design system exists only in Figma, then its just a style guide. For a design system to be truly complete, it needs to exists outside of Figma and as a code library.\u003C/p>\n\u003Cp>We were re-writing our Android Front end in Jetpack Compose and decided to merge the two efforts to implement our design system.\nWhile having self-explanatory token naming certainly makes designers’ lives easier, by taking this direction of deviating from Material Design’s conventions, we increased our developement effort.\nWe had to build a bridge to make our tokens compatible with material design. This wasn’t straightforward. Most big companies that we studied had UX engineering teams to help build such plugins for their use.\nWe came across \u003Ca href=\"https://github.com/style-dictionary/style-dictionary\">Amazon’s style dictionary\u003C/a> from \u003Ca href=\"https://www.youtube.com/watch?v=jgueTz72ZMQ&t=760s\">this talk by Doordash\u003C/a> and Atlassian’s inhouse plugin in \u003Ca href=\"https://www.youtube.com/watch?v=m8ZSu9eCsQc&t=814s\">their schema talk\u003C/a>\nand the popular figma plugin \u003Ca href=\"https://tokens.studio\">Tokens Studio\u003C/a>.\u003C/p>\n\u003Cblockquote>\n\u003Cp>So why did we still proceed with this approach? We prioritized ease of use, recognizing that the development work to implement this system is a one-time investment.\nWe believed that it was a worthwhile trade-off.\u003C/p>\n\u003C/blockquote>\n\u003Cp>It wasn’t really all that straightforward. We were only able to make it work by closely working with our developers(Sivan and Vishnu).\u003C/p>\n\u003Ch4 id=\"our-approach\">Our Approach\u003C/h4>\n\u003Cp>We used Tokens Studio to export our tokens from Figma as JSON and the devs had to figure out how to translate this to a setup that can be consumed by our apps.\nThe aim was to make sure that the designers had the freedom to take decisions while the devs wouldn’t have to break a sweat in integrating them into the apps.\u003C/p>\n\u003Cp>Our apps are on the Jetpack Compose framework and this meant that the design language and consumption were slightly different from Android’s traditional XML.\nWe found \u003Ca href=\"https://github.com/lukasoppermann/design-token-transformer\">Lukas Opperman’s Design Token Transformer\u003C/a> to be a great tool for porting tokens to Web,\niOS and Android’s XML system but we needed something that would support Jetpack Compose as well. So we forked this repo and decided to add support for Jetpack Compose.\nThe overall idea was straightforward. The engine should take in the\nJSON file as the input, and spit out Compose Theming files that can be imported onto your project directly and the devs wouldn’t have to worry too much about the setup.\u003C/p>\n\u003Cimg src=\"/images/tokens-figma.gif\" alt=\"Tokens in Figma\" style=\"border-radius: 8px;\">\n\u003Cp>And that’s how we placed the final piece of our design system jigsaw puzzle.\u003C/p>\n\u003Ch2 id=\"presenting-the-akar-design-sytem\">Presenting the Akar Design Sytem:\u003C/h2>\n\u003Cp>All this while, we had been working hard on the system but we realised we didn’t have a name for our design system. We wanted something that resonated with the agritech space we were in, so we began brainstorming. Finally, with the help of Notion AI, we chose to go with Akar.\u003C/p>\n\u003Cp>Akar, derived from the Bahasa Indonesia word for ‘root,’ perfectly reflects the role of our design system in providing a solid foundation for building products. It’s also symbolic, as Indonesia is where our products first took shape, making the name a meaningful nod to our origins.\u003C/p>\n\u003Cfigure class=\"image-figure\">\u003Cimg __ASTRO_IMAGE_=\"{"src":"akar-screens.webp","alt":"Akar on our screens","index":0}\">\u003Cfigcaption>Akar on our screens\u003C/figcaption>\u003C/figure>\n\u003Ch3 id=\"post-launch\">Post-launch\u003C/h3>\n\u003Cp>A design system’s success is measure by its penetration and implementation by the team. Building it in isolation is bound to fail. Throughout the process, we spent time\ninvolving the dev and design teams. We did this by\u003C/p>\n\u003Cul>\n\u003Cli>We created Slack channels to communicate updates and invite collaboration.\u003C/li>\n\u003Cli>We presented the system at an org-wide ‘Lunch and Learn’ (an org level initiative to talk about work) to bring awareness to the initiative.\u003C/li>\n\u003Cli>To track adoption, we created pod-specific slack channels for devs and designers to have discussions around implementation and we set up a Notion page to track migration and adoption.\u003C/li>\n\u003Cli>We created a \u003Ca href=\"https://zeroheight.com/5c1eb1bd5/p/73e674-akar-design-system\">documentation site\u003C/a> which devs and designers could refer to.\u003C/li>\n\u003C/ul>\n\u003Ch2 id=\"impact\">Impact\u003C/h2>\n\u003Cp>Having Akar, helped us scale faster and build and redesign new apps and products in the Jiva ecosystem. As of September 2025, it was used across various platforms and products at Jiva,\nsupporting our 3 core Android mobile apps (Sahabat Jiva, Jiva Petani, Jiva Agro). We also extended our tokens to be used in our internal React Native apps (Jiva Sales, Field Agent App), as well as internal tools built using Retool.\u003C/p>\n\u003Cp>Implementation of the code components was a slow process as getting it prioritised over business needs was hard.\nWe were able to get like 80% of the product verticals to completely use our libarary within the first 12 months.\u003C/p>\n\u003Ch2 id=\"team\">Team\u003C/h2>\n\u003Cp>Tyo (who had just joined the team) worked with me and built out the Figma token and components system. Nav, (head of design), helped us take decisions\naround the direction of the design components. Sivan and VIshnu were the devs who we collaborated closely to get the code components out in production.\u003C/p>\n\u003Csection data-footnotes=\"\" class=\"footnotes\">\u003Ch2 class=\"sr-only\" id=\"footnote-label\">Footnotes\u003C/h2>\n\u003Col>\n\u003Cli id=\"user-content-fn-1\">\n\u003Cp>\u003Cstrong>Spotify’s Encore\u003C/strong> \u003Ca href=\"https://spotify.design/article/can-i-get-an-encore-spotifys-design-system-three-years-on\">https://spotify.design/article/can-i-get-an-encore-spotifys-design-system-three-years-on\u003C/a> \u003Ca href=\"#user-content-fnref-1\" data-footnote-backref=\"\" aria-label=\"Back to reference 1\" class=\"data-footnote-backref\">↩\u003C/a>\u003C/p>\n\u003C/li>\n\u003C/ol>\n\u003C/section>",{"headings":35,"localImagePaths":87,"remoteImagePaths":88,"frontmatter":89,"imagePaths":90},[36,40,43,47,50,53,56,60,63,66,69,72,75,78,81,84],{"depth":37,"slug":38,"text":39},2,"role","Role",{"depth":37,"slug":41,"text":42},"challenge","Challenge",{"depth":44,"slug":45,"text":46},3,"goals","Goals",{"depth":44,"slug":48,"text":49},"impact-on-our-customers","Impact on our customers",{"depth":37,"slug":51,"text":52},"getting-started","Getting started",{"depth":44,"slug":54,"text":55},"design-tokens","Design Tokens",{"depth":57,"slug":58,"text":59},4,"typography","Typography",{"depth":57,"slug":61,"text":62},"color","Color",{"depth":44,"slug":64,"text":65},"bringing-it-all-together","Bringing it all together",{"depth":44,"slug":67,"text":68},"the-final-stretch","The Final stretch",{"depth":57,"slug":70,"text":71},"our-approach","Our Approach",{"depth":37,"slug":73,"text":74},"presenting-the-akar-design-sytem","Presenting the Akar Design Sytem:",{"depth":44,"slug":76,"text":77},"post-launch","Post-launch",{"depth":37,"slug":79,"text":80},"impact","Impact",{"depth":37,"slug":82,"text":83},"team","Team",{"depth":37,"slug":85,"text":86},"footnote-label","Footnotes",[23,24,25,26,27,28,29],[],{"title":14,"description":15,"year":17,"company":18,"image":30},[23,24,25,26,27,28,29],"claim-profile",{"id":91,"data":93,"body":100,"filePath":101,"assetImports":102,"digest":104,"rendered":105},{"title":94,"description":95,"image":96,"year":97,"company":98,"status":99},"Practo.com doctor profiles","Designing the onboarding experience for new doctors on Practo.com","__ASTRO_IMAGE_./practo-profile.png","2016-2017","Practo","draft","## Overview\n\nPracto has around 100k doctor profiles and another 70k clinic profiles currently live on its marketplace.\nThis accounts for barely 50% of coverage in our T6 cities. So during the Q3-Q4 of 2016-17, the primary\nobjective of the unified app; Practo Partner, was to get more profiles published and live.\n\nAround November 2016, to get a profile live on Practo.com, a doctor needed to fill in 20 fields which\nwere separated into 2 forms. We had taken the approach as an informational option but realized that\nlot of profiles were not being completed and we did not communicate what was necessary to go live to\na doctor within the app.\n\n\n[before we began]\n\n## Understanding the problem\n\nAs seen above, we did communicate that a profile was incomplete but the interface didn't\ncommunicate what was necessary for a doctor to go live. Our completion data showed us that major\ndropoffs occurred during profile completion, proof upload and clinic profile addition.\n\nWe studied onboarding flows of other applications like Airbnb and Gyroscope which deal with filling lot\nof mandatory data as well as Doximity which deals with the claiming of doctor profiles to get started.\nExploring a solution\n\nAfter some discussions with the stakeholders, we decided the best way to deliver impact was if we\nbreak this project into phases. For the first phase, we designed and shipped out with an intent page\nand a quick fix stitching the two forms together. At the same time, the app was going through the new\nbrand implementation which explains the choice of color palette and the change in typography.\n\n[designs from phase 1]\n\nPost this change, we saw an increase(approx 34%) in the profiles going towards completion in the\nmonth of March vs February and January numbers. This validated the brief and the direction that we\nwere going towards.\n\nAs part of the feet-on-street model adopted by Practo, we had several profiles that had been created\nby the salesguy, however those profiles were not being used by the doctor and instead the doctor\nwould create a new profile when they logged in leading to duplicates which would be an overhead for\noperations and decreased efficiency. We also needed doctors to keep their profile data fresh. So with\nthis in mind, Claim profile became a company objective so the next phase was integrating this into the\nonboarding\n\nThe various usecases and catering to both new and existing users kept us busy for almost a month\nwhere we iterated on various designs before narrowing down on one. We worked closely with the\nprofiles product team whenever we had to make a decision, since they knew best about the way profile\nclaim worked.\n\n\n[early explorations]\n\nBased on all these inputs, we were able to narrow down on the direction that we wanted to take for the\nproject.\nevolution of the ‘checkout’ screen\n\n\n### Things we are trying out with this\n– The design accommodated for problems with the flow with keeping a way to access our hotline on all\nthe decision making pages.\n– Users dropping off would be asked if they would want to be reminded to fill the form at a later time.\nThe form needs document proofs to be complete and these would not always be at hand.\n\n## Final screens\n\n\n**Footnote:**\nThanks to Sonal, Suhas, Preet, Rafiq, Pramod, Rachit and the rest of the Practo Pro team for their\ninputs and help in making this design come true","src/content/work/claim-profile/index.md",[103],"./practo-profile.png","a77ca723bf32625f",{"html":106,"metadata":107},"\u003Ch2 id=\"overview\">Overview\u003C/h2>\n\u003Cp>Practo has around 100k doctor profiles and another 70k clinic profiles currently live on its marketplace.\nThis accounts for barely 50% of coverage in our T6 cities. So during the Q3-Q4 of 2016-17, the primary\nobjective of the unified app; Practo Partner, was to get more profiles published and live.\u003C/p>\n\u003Cp>Around November 2016, to get a profile live on Practo.com, a doctor needed to fill in 20 fields which\nwere separated into 2 forms. We had taken the approach as an informational option but realized that\nlot of profiles were not being completed and we did not communicate what was necessary to go live to\na doctor within the app.\u003C/p>\n\u003Cp>[before we began]\u003C/p>\n\u003Ch2 id=\"understanding-the-problem\">Understanding the problem\u003C/h2>\n\u003Cp>As seen above, we did communicate that a profile was incomplete but the interface didn’t\ncommunicate what was necessary for a doctor to go live. Our completion data showed us that major\ndropoffs occurred during profile completion, proof upload and clinic profile addition.\u003C/p>\n\u003Cp>We studied onboarding flows of other applications like Airbnb and Gyroscope which deal with filling lot\nof mandatory data as well as Doximity which deals with the claiming of doctor profiles to get started.\nExploring a solution\u003C/p>\n\u003Cp>After some discussions with the stakeholders, we decided the best way to deliver impact was if we\nbreak this project into phases. For the first phase, we designed and shipped out with an intent page\nand a quick fix stitching the two forms together. At the same time, the app was going through the new\nbrand implementation which explains the choice of color palette and the change in typography.\u003C/p>\n\u003Cp>[designs from phase 1]\u003C/p>\n\u003Cp>Post this change, we saw an increase(approx 34%) in the profiles going towards completion in the\nmonth of March vs February and January numbers. This validated the brief and the direction that we\nwere going towards.\u003C/p>\n\u003Cp>As part of the feet-on-street model adopted by Practo, we had several profiles that had been created\nby the salesguy, however those profiles were not being used by the doctor and instead the doctor\nwould create a new profile when they logged in leading to duplicates which would be an overhead for\noperations and decreased efficiency. We also needed doctors to keep their profile data fresh. So with\nthis in mind, Claim profile became a company objective so the next phase was integrating this into the\nonboarding\u003C/p>\n\u003Cp>The various usecases and catering to both new and existing users kept us busy for almost a month\nwhere we iterated on various designs before narrowing down on one. We worked closely with the\nprofiles product team whenever we had to make a decision, since they knew best about the way profile\nclaim worked.\u003C/p>\n\u003Cp>[early explorations]\u003C/p>\n\u003Cp>Based on all these inputs, we were able to narrow down on the direction that we wanted to take for the\nproject.\nevolution of the ‘checkout’ screen\u003C/p>\n\u003Ch3 id=\"things-we-are-trying-out-with-this\">Things we are trying out with this\u003C/h3>\n\u003Cp>– The design accommodated for problems with the flow with keeping a way to access our hotline on all\nthe decision making pages.\n– Users dropping off would be asked if they would want to be reminded to fill the form at a later time.\nThe form needs document proofs to be complete and these would not always be at hand.\u003C/p>\n\u003Ch2 id=\"final-screens\">Final screens\u003C/h2>\n\u003Cp>\u003Cstrong>Footnote:\u003C/strong>\nThanks to Sonal, Suhas, Preet, Rafiq, Pramod, Rachit and the rest of the Practo Pro team for their\ninputs and help in making this design come true\u003C/p>",{"headings":108,"localImagePaths":121,"remoteImagePaths":122,"frontmatter":123,"imagePaths":124},[109,112,115,118],{"depth":37,"slug":110,"text":111},"overview","Overview",{"depth":37,"slug":113,"text":114},"understanding-the-problem","Understanding the problem",{"depth":44,"slug":116,"text":117},"things-we-are-trying-out-with-this","Things we are trying out with this",{"depth":37,"slug":119,"text":120},"final-screens","Final screens",[],[],{"title":94,"description":95,"year":97,"company":98,"image":103,"status":99},[],"gobiz-inbox",{"id":125,"data":127,"body":132,"filePath":133,"digest":134,"rendered":135},{"title":128,"description":129,"year":130,"company":131,"status":99},"Designing the Inbox experience for GoBiz","How we designed the in-app comms channel","2021","Gojek","The Gojek Chat SDK was built to support products wanting to integrate chat into their flows. However like many other platformized products, they end up being looked as solutions for use cases they were not designed for. The GoBiz inbox requirement wasn't my first experience with dog fooding, but it was one that I was able to influence positively for the benefit of the users.\n\nWe wanted to build an Inbox, an in-app channel for notifying our users. We just needed one-way communication. I do not understand the reason behind why product pushed to use the SDK, despite the arguments that the SDK wasn't able to support our web product and wasn't designed to communicate business updates.\n\n### Chat is chat, not inbox:\n\nI created a document to explain what that decision meant for the app.\nIf we use the chat sdk, then in the future as other teams build on the chat platform, we should plan to group all kinds of chat in a single space. This would align with the mental model of the user. This space would be the go-to place to follow up on your \"conversations\", whether its about onboarding a new outlet or following up about your GoFresh order.\n\n_Decision:_ We decided that all chats will show up in Inbox but we will need to visually separate them from the business chats. This is something that the Chat team had not yet designed for.\n\n### Where should Inbox/chat go?\n\nGiven that Inbox is something we are considering for communication, it should be easily accessible and indicate unread chats. Given the current structure of the GoBiz app, we could only think of 2 possible positions for the Inbox.\n\nHowever neither of these positions fulfill the conditions of\n\n1. Visibility of new messages: The red dot on Lainnya can't showcase a number since there are several other modules which have a no-number indication.\n\n2. Accessible from various parts of our app: A gofood merchant would jump right to the Orders inbox when they open the app and has no need to aware of this \"notification'\n\n_Decision:_ However without the redesign being prioritized, we decided to keep the entry point on the top right of the 'Lainnya' page.\n\n### Shuffle vs Inbox:\n\n1. Currently there can be overlaps. Overlaps may lead to reduction in importance of Inbox content.\n\n2. Can 'Promo' channel in Inbox be completely replaced by a shuffle card channel on lainnya? because promos need segmentation. Inbox may not work that way.\n\n_Decision:_ No decision yet\n\n### Design iterations\n\nThe Inbox requirement wasn't a new one. 11 months ago, Saneef had worked on how we could introduce communication channels(banner and inbox) in our /existing/ app. [(Aside: His redesign had 'Inbox' as a tab on the bottom navigation)](https://share.goabstract.com/8af61eee-de93-4f63-b0f8-64922742a29e?mode=design&sha=875263ee629f633ddd9229602605e3870884c3da)\n\nWhat was good about this iteration was that latest messages would be visible on the Lainnya page with a way for users to filter different kinds of messages. However this design wouldn't scale well if there were many channels. Think how filters work on Gojek Home's shuffles. Same problem.\n\nWhen we decided to adopt the Chat SDK, it came with a constraint that the view would be a chat window.\n\nSo this constraint causes us to have limited explorations for the channel view. Based on this, here are two iterations that could be possible.\n\n#### Iteration 1:\n\nIteration 1 is having a list of channels on the second page, but without the full message so users would need to make an additional click through to get the full message.\n\n#### Iteration 2:\n\nThis exploration attempts to use a notifier informing user about a new message. It could include the text of the message or a generic '1 new message'. In the chat window, we can see the latest message of a channel up front without clicking again to see the message. Even CTAs could be visible here.\n\nSo we went ahead with user-testing with both these iterations, and 'Iteration 2' came out successful.\n\n#### Key Learnings from the research\n\n1. People may ignore the position of the Inbox because of its proximity to the logout button\n\n2. The inbox icon was not understood, so we switched to the envelope icon and called it 'Kotak Pesan'","src/content/work/gobiz-inbox/index.md","e41b0d64e917328f",{"html":136,"metadata":137},"\u003Cp>The Gojek Chat SDK was built to support products wanting to integrate chat into their flows. However like many other platformized products, they end up being looked as solutions for use cases they were not designed for. The GoBiz inbox requirement wasn’t my first experience with dog fooding, but it was one that I was able to influence positively for the benefit of the users.\u003C/p>\n\u003Cp>We wanted to build an Inbox, an in-app channel for notifying our users. We just needed one-way communication. I do not understand the reason behind why product pushed to use the SDK, despite the arguments that the SDK wasn’t able to support our web product and wasn’t designed to communicate business updates.\u003C/p>\n\u003Ch3 id=\"chat-is-chat-not-inbox\">Chat is chat, not inbox:\u003C/h3>\n\u003Cp>I created a document to explain what that decision meant for the app.\nIf we use the chat sdk, then in the future as other teams build on the chat platform, we should plan to group all kinds of chat in a single space. This would align with the mental model of the user. This space would be the go-to place to follow up on your “conversations”, whether its about onboarding a new outlet or following up about your GoFresh order.\u003C/p>\n\u003Cp>\u003Cem>Decision:\u003C/em> We decided that all chats will show up in Inbox but we will need to visually separate them from the business chats. This is something that the Chat team had not yet designed for.\u003C/p>\n\u003Ch3 id=\"where-should-inboxchat-go\">Where should Inbox/chat go?\u003C/h3>\n\u003Cp>Given that Inbox is something we are considering for communication, it should be easily accessible and indicate unread chats. Given the current structure of the GoBiz app, we could only think of 2 possible positions for the Inbox.\u003C/p>\n\u003Cp>However neither of these positions fulfill the conditions of\u003C/p>\n\u003Col>\n\u003Cli>\n\u003Cp>Visibility of new messages: The red dot on Lainnya can’t showcase a number since there are several other modules which have a no-number indication.\u003C/p>\n\u003C/li>\n\u003Cli>\n\u003Cp>Accessible from various parts of our app: A gofood merchant would jump right to the Orders inbox when they open the app and has no need to aware of this “notification’\u003C/p>\n\u003C/li>\n\u003C/ol>\n\u003Cp>\u003Cem>Decision:\u003C/em> However without the redesign being prioritized, we decided to keep the entry point on the top right of the ‘Lainnya’ page.\u003C/p>\n\u003Ch3 id=\"shuffle-vs-inbox\">Shuffle vs Inbox:\u003C/h3>\n\u003Col>\n\u003Cli>\n\u003Cp>Currently there can be overlaps. Overlaps may lead to reduction in importance of Inbox content.\u003C/p>\n\u003C/li>\n\u003Cli>\n\u003Cp>Can ‘Promo’ channel in Inbox be completely replaced by a shuffle card channel on lainnya? because promos need segmentation. Inbox may not work that way.\u003C/p>\n\u003C/li>\n\u003C/ol>\n\u003Cp>\u003Cem>Decision:\u003C/em> No decision yet\u003C/p>\n\u003Ch3 id=\"design-iterations\">Design iterations\u003C/h3>\n\u003Cp>The Inbox requirement wasn’t a new one. 11 months ago, Saneef had worked on how we could introduce communication channels(banner and inbox) in our /existing/ app. \u003Ca href=\"https://share.goabstract.com/8af61eee-de93-4f63-b0f8-64922742a29e?mode=design&sha=875263ee629f633ddd9229602605e3870884c3da\">(Aside: His redesign had ‘Inbox’ as a tab on the bottom navigation)\u003C/a>\u003C/p>\n\u003Cp>What was good about this iteration was that latest messages would be visible on the Lainnya page with a way for users to filter different kinds of messages. However this design wouldn’t scale well if there were many channels. Think how filters work on Gojek Home’s shuffles. Same problem.\u003C/p>\n\u003Cp>When we decided to adopt the Chat SDK, it came with a constraint that the view would be a chat window.\u003C/p>\n\u003Cp>So this constraint causes us to have limited explorations for the channel view. Based on this, here are two iterations that could be possible.\u003C/p>\n\u003Ch4 id=\"iteration-1\">Iteration 1:\u003C/h4>\n\u003Cp>Iteration 1 is having a list of channels on the second page, but without the full message so users would need to make an additional click through to get the full message.\u003C/p>\n\u003Ch4 id=\"iteration-2\">Iteration 2:\u003C/h4>\n\u003Cp>This exploration attempts to use a notifier informing user about a new message. It could include the text of the message or a generic ‘1 new message’. In the chat window, we can see the latest message of a channel up front without clicking again to see the message. Even CTAs could be visible here.\u003C/p>\n\u003Cp>So we went ahead with user-testing with both these iterations, and ‘Iteration 2’ came out successful.\u003C/p>\n\u003Ch4 id=\"key-learnings-from-the-research\">Key Learnings from the research\u003C/h4>\n\u003Col>\n\u003Cli>\n\u003Cp>People may ignore the position of the Inbox because of its proximity to the logout button\u003C/p>\n\u003C/li>\n\u003Cli>\n\u003Cp>The inbox icon was not understood, so we switched to the envelope icon and called it ‘Kotak Pesan’\u003C/p>\n\u003C/li>\n\u003C/ol>",{"headings":138,"localImagePaths":160,"remoteImagePaths":161,"frontmatter":162,"imagePaths":163},[139,142,145,148,151,154,157],{"depth":44,"slug":140,"text":141},"chat-is-chat-not-inbox","Chat is chat, not inbox:",{"depth":44,"slug":143,"text":144},"where-should-inboxchat-go","Where should Inbox/chat go?",{"depth":44,"slug":146,"text":147},"shuffle-vs-inbox","Shuffle vs Inbox:",{"depth":44,"slug":149,"text":150},"design-iterations","Design iterations",{"depth":57,"slug":152,"text":153},"iteration-1","Iteration 1:",{"depth":57,"slug":155,"text":156},"iteration-2","Iteration 2:",{"depth":57,"slug":158,"text":159},"key-learnings-from-the-research","Key Learnings from the research",[],[],{"title":128,"description":129,"year":130,"company":131,"status":99},[],"gojek",{"id":164,"data":166,"body":171,"filePath":172,"assetImports":173,"digest":189,"rendered":190},{"title":167,"description":168,"image":169,"year":170,"company":131,"status":19},"Designing for Gojek's Merchants","A brief overview of the work I did at GoBiz, Gojek's Merchant Platform","__ASTRO_IMAGE_./QRIS-gobiz.webp","2019-2021","### Role\nFrom 2019-2022, I worked on the merchant side of Gojek. GoBiz, Gojek's merchant platform, catered to 1M+ merchants across Indonesia, Vietnam(closed down in Sep 2024) and Thailand (sold to AirAsia in July 2021). The GoBiz Platform served GoFood merchants, GoPay Micro-merchants, as well as Enterprise merchants.\n\nI started off as the designer tasked with redesigning the GoBiz Android app and eventually moved to lead the design on the GoBiz Platform contributing towards the design of the GoBiz app and website, the Spots app and the Midtrans website. Over this period of time, the design team at GoBiz grew to 12 designers with the mergers and acquisitions of Midtrans, Kartuku and Moka POS before eventually breaking up pre-IPO. \n\n## GoBiz app\n[GO-RESTO](https://www.gojek.io/blog/whats-cooking-diving-into-kitchens-for-gobiz) ,released on 2017, was the app that our GO-FOOD partner merchants would use to receive orders, manage their catalogue and other restaurant information. But with the creation of the Merchant vertical, now GO-RESTO was to have a much larger vision. I joined the team as their designer in 2018 and worked on the redesign to convert it into a Super app. \n\nWhen we started working on this, we were worried that our users would feel isolated by this change in the interface which were driven by our business needs. \n\nSo as always, we began with the users.\n\nWe did a merchant segmentation study and then selected a few merchants from each of these segments to better understand their needs and came up with the following objectives.\n\n#### The objectives of the redesign were\n1. \u003Cins>Scalability:\u003C/ins> The main navigation (shown below) was a hamburger menu. As Go-RESTO had kept adding new features, adding them to the navbar as an when they were ready was how the product had scaled. However now we needed an information architecture that would work for GoFood, GoPay, and other merchants.\n2. \u003Cins>UI refresh:\u003C/ins> With the move, we rebranded from 'Go-Resto' to 'GoBiz' and adopted the newly minted [Asphalt 1.0](https://www.gojek.io/blog/of-dreams-deadlines-and-a-design-system) design language system. Due to the timing of the redesign, we were the first app in the Gojek ecosystem to be completely built on the new Asphalt design system. \n3. \u003Cins>Platformization\u003C/ins>: As Gojek grew, in-order to reduce duplication of efforts across multiple verticals, having a platform like GoBiz to build on would be beneficial for teams building for merchant partners like GoPay, GoMart, etc.\n\n#### Design Process:\n\n![Rough Sketches](rough-sketches.png)\n![One of the early iterations](Early-explorations.png)\n![Redesigned screens in Sketch for GoBiz](gobiz-v1.png)\n\nLooking at existing analytics helped me make decision on the information architecture. Once we finalised the navigation with all the stakeholders, we moved into iterating solutions before finalizing on the design.\n\n#### User testing:\nWe decided to have a pilot group of merchants for the release and the research team conducted a user diary research with them. \nAs we had not changed any major flow, we did not find any issues. \n\n![GoBiz Navigation; before and after](gobiz-nav.jpg)\n#### Learnings post release:\nOnce we released we started seeing feedback on the playstore asking us why we had hidden the customer contact. In the design, in the interest of showing the list of ordered items, we had moved the customer contact behind an overflow menu. Our analytics had shown low usage of this feature and we felt we could move it and add an onboarding tooltip for the merchants\n\nHowever these complaints persisted and we followed up with a few merchants to understand the problem. We learned that though the merchants did not end up calling via the app (because the app may not have the phone balance), they would want to see the customer phone number either to collect it for marketing purpose, to call from another number or to identify if its a fraud order. \n\nBased on the feedback, we took a call to re-instate the customer number back on the order details screen. \n![There's a lot more back and forth than we expected](gobiz-order.png)\n\n#### Impact:\n\n![GoBiz Ratings](GoBiz-ratings.webp)\n\nThe ratings of the GoBiz Super app saw a positive growth from 3.7 when we started work to 4.5+ post release[^1].\n\n## GoBiz Dashboard\nSometimes you just inherit a product that has not been loved. The GoBiz dashboard was built for enterprise merchants by forking an internal portal. The portal was built on an internal front end framework “[Tanjidor](https://en.wikipedia.org/wiki/Tanjidor)” and the designers used to design in the browser and this meant that there were no design files. This meant that there was a dependency on the existing designers. So we decided to pick it up as a design initiative.\n\n#### Objectives of the redesign:\n1. Reduce dependancy on the existing designer by\n2. Make the dashboard accessible via mobile web\n\n#### What we did:\nIn 2019, we (product design and research) conducted a heuristic evaluation to identify key issues. But post that due to issues with design bandwidth, the project was deprioritised. \n\nFast forward to 2020, Hendri joined us on the GoBiz team and I assigned him to start work on the GoBiz Dashboard redesign as a way to familiarise himself with the product. \n\nWe decided to design anything new with our web design system and not do it in the browser. Due to some luck, the “platformisation” of the Dashboard project got prioritised that quarter. However the PM was going to do it without a change to the UI. I convinced her to switch to the new UI. But given the sprint was beginning in 2 weeks, we were short of time. So we got a list of pages to work on a priority basis and started exploring. A lot of work was already done by Hendri however we had to now make the whole site look coherent. \n\n> You can arrive at a different output using the same design system.\n\nWe experimented with spacing and separators, navigation menu designs and modal overlays in the next 10 days to finalise the boilerplate for all the pages. Oh and yeah we also made it responsive. \n\n![](Gobiz-web.png)\n\n\n![After our redesign with Asphalt Web](Gobiz-web3.png)\n#### What we could not do:\n* Fix the information architecture issues in every page. \n* Figure out a table design that works well on mobile and desktop\n\n#### Outcome:\nThe GoMart designers were able to use the design system and build their module on the Dashboard with limited dependency on our team. \n\n\n## The Spots app\n![Left: Original, Right: Redesigned](spots.png)\nThe SPOTS app was a point of sales app on a Landi device. We were selling these to offline merchants to let them collect payment via offline modes like credit card, debit card and QR. \n\nThe app they were using was a reskinned version of the default app provided by Landi(image on the left). \n\nI was asked to help out with it and I worked on a refresh for the app on a short timeline(image on the right) \n\n![](QRIS-gobiz.webp)\n\nWe later integrated this into the POS application on the GoBiz app. \n\n# Midtrans\nIn 2020, the Midtrans merchant onboarding was prioritized due to an external collaboration with Whatsapp. \n\n![](midtrans-old.png)\n\nGiven the urgency, I decided to ask Riyadhi to help the team with the wireframes. Riyadhi had previously worked on the merchant onboarding flow for the GoBiz app and I felt this would help us speed up the process. \n\nWe had just completed the platformization exercise so Hendri and Firman were proficient with the new design system. The dev team too was confident that using the web design system was the best decision. This also made the flow mobile web compatible which was one of the identified merchant pain points. \n\n![](midtrans-onboarding-1.png)\n![](midtrans-onboarding-2.png)\n\nSo we shipped the new onboarding and saw lot of reduction in the drop offs. \n\n![](midtrans-onboarding-impact.png)\n\n### Outcome:\nThis project exposed most of the team to the ‘merchant onboarding’ problem space and a surprising side-effect of this was that project handover of the ‘corporate onboarding’ project could be handled by Hendri when Riyadhi was affected by Covid-19.\n\n#### Miscellaneous:\nI consulted on the GoBiz and the Midtrans marketing website. \n\n[^1]: Road to a Merchant Super App on the Gojek Blog https://www.gojek.io/blog/the-road-to-a-merchant-superapp","src/content/work/gojek/index.md",[174,175,176,177,178,179,180,181,182,183,184,185,186,187,188],"rough-sketches.png","Early-explorations.png","gobiz-v1.png","gobiz-nav.jpg","gobiz-order.png","GoBiz-ratings.webp","Gobiz-web.png","Gobiz-web3.png","spots.png","QRIS-gobiz.webp","midtrans-old.png","midtrans-onboarding-1.png","midtrans-onboarding-2.png","midtrans-onboarding-impact.png","./QRIS-gobiz.webp","525f12ee946b7d28",{"html":191,"metadata":192},"\u003Ch3 id=\"role\">Role\u003C/h3>\n\u003Cp>From 2019-2022, I worked on the merchant side of Gojek. GoBiz, Gojek’s merchant platform, catered to 1M+ merchants across Indonesia, Vietnam(closed down in Sep 2024) and Thailand (sold to AirAsia in July 2021). The GoBiz Platform served GoFood merchants, GoPay Micro-merchants, as well as Enterprise merchants.\u003C/p>\n\u003Cp>I started off as the designer tasked with redesigning the GoBiz Android app and eventually moved to lead the design on the GoBiz Platform contributing towards the design of the GoBiz app and website, the Spots app and the Midtrans website. Over this period of time, the design team at GoBiz grew to 12 designers with the mergers and acquisitions of Midtrans, Kartuku and Moka POS before eventually breaking up pre-IPO.\u003C/p>\n\u003Ch2 id=\"gobiz-app\">GoBiz app\u003C/h2>\n\u003Cp>\u003Ca href=\"https://www.gojek.io/blog/whats-cooking-diving-into-kitchens-for-gobiz\">GO-RESTO\u003C/a> ,released on 2017, was the app that our GO-FOOD partner merchants would use to receive orders, manage their catalogue and other restaurant information. But with the creation of the Merchant vertical, now GO-RESTO was to have a much larger vision. I joined the team as their designer in 2018 and worked on the redesign to convert it into a Super app.\u003C/p>\n\u003Cp>When we started working on this, we were worried that our users would feel isolated by this change in the interface which were driven by our business needs.\u003C/p>\n\u003Cp>So as always, we began with the users.\u003C/p>\n\u003Cp>We did a merchant segmentation study and then selected a few merchants from each of these segments to better understand their needs and came up with the following objectives.\u003C/p>\n\u003Ch4 id=\"the-objectives-of-the-redesign-were\">The objectives of the redesign were\u003C/h4>\n\u003Col>\n\u003Cli>\u003Cins>Scalability:\u003C/ins> The main navigation (shown below) was a hamburger menu. As Go-RESTO had kept adding new features, adding them to the navbar as an when they were ready was how the product had scaled. However now we needed an information architecture that would work for GoFood, GoPay, and other merchants.\u003C/li>\n\u003Cli>\u003Cins>UI refresh:\u003C/ins> With the move, we rebranded from ‘Go-Resto’ to ‘GoBiz’ and adopted the newly minted \u003Ca href=\"https://www.gojek.io/blog/of-dreams-deadlines-and-a-design-system\">Asphalt 1.0\u003C/a> design language system. Due to the timing of the redesign, we were the first app in the Gojek ecosystem to be completely built on the new Asphalt design system.\u003C/li>\n\u003Cli>\u003Cins>Platformization\u003C/ins>: As Gojek grew, in-order to reduce duplication of efforts across multiple verticals, having a platform like GoBiz to build on would be beneficial for teams building for merchant partners like GoPay, GoMart, etc.\u003C/li>\n\u003C/ol>\n\u003Ch4 id=\"design-process\">Design Process:\u003C/h4>\n\u003Cdiv class=\"image-figure-container\">\u003Cfigure class=\"image-figure\">\u003Cimg __ASTRO_IMAGE_=\"{"src":"rough-sketches.png","alt":"Rough Sketches","index":0}\">\u003Cfigcaption>Rough Sketches\u003C/figcaption>\u003C/figure>\u003Cfigure class=\"image-figure\">\u003Cimg __ASTRO_IMAGE_=\"{"src":"Early-explorations.png","alt":"One of the early iterations","index":0}\">\u003Cfigcaption>One of the early iterations\u003C/figcaption>\u003C/figure>\u003Cfigure class=\"image-figure\">\u003Cimg __ASTRO_IMAGE_=\"{"src":"gobiz-v1.png","alt":"Redesigned screens in Sketch for GoBiz","index":0}\">\u003Cfigcaption>Redesigned screens in Sketch for GoBiz\u003C/figcaption>\u003C/figure>\u003C/div>\n\u003Cp>Looking at existing analytics helped me make decision on the information architecture. Once we finalised the navigation with all the stakeholders, we moved into iterating solutions before finalizing on the design.\u003C/p>\n\u003Ch4 id=\"user-testing\">User testing:\u003C/h4>\n\u003Cp>We decided to have a pilot group of merchants for the release and the research team conducted a user diary research with them.\nAs we had not changed any major flow, we did not find any issues.\u003C/p>\n\u003Cfigure class=\"image-figure\">\u003Cimg __ASTRO_IMAGE_=\"{"src":"gobiz-nav.jpg","alt":"GoBiz Navigation; before and after","index":0}\">\u003Cfigcaption>GoBiz Navigation; before and after\u003C/figcaption>\u003C/figure>\n\u003Ch4 id=\"learnings-post-release\">Learnings post release:\u003C/h4>\n\u003Cp>Once we released we started seeing feedback on the playstore asking us why we had hidden the customer contact. In the design, in the interest of showing the list of ordered items, we had moved the customer contact behind an overflow menu. Our analytics had shown low usage of this feature and we felt we could move it and add an onboarding tooltip for the merchants\u003C/p>\n\u003Cp>However these complaints persisted and we followed up with a few merchants to understand the problem. We learned that though the merchants did not end up calling via the app (because the app may not have the phone balance), they would want to see the customer phone number either to collect it for marketing purpose, to call from another number or to identify if its a fraud order.\u003C/p>\n\u003Cfigure class=\"image-figure\">\u003Cimg __ASTRO_IMAGE_=\"{"src":"gobiz-order.png","alt":"There's a lot more back and forth than we expected","index":0}\">\u003Cfigcaption>There's a lot more back and forth than we expected\u003C/figcaption>\u003C/figure>\n\u003Ch4 id=\"impact\">Impact:\u003C/h4>\n\u003Cfigure class=\"image-figure\">\u003Cimg __ASTRO_IMAGE_=\"{"src":"GoBiz-ratings.webp","alt":"GoBiz Ratings","index":0}\">\u003Cfigcaption>GoBiz Ratings\u003C/figcaption>\u003C/figure>\n\u003Cp>The ratings of the GoBiz Super app saw a positive growth from 3.7 when we started work to 4.5+ post release\u003Csup>\u003Ca href=\"#user-content-fn-1\" id=\"user-content-fnref-1\" data-footnote-ref=\"\" aria-describedby=\"footnote-label\">1\u003C/a>\u003C/sup>.\u003C/p>\n\u003Ch2 id=\"gobiz-dashboard\">GoBiz Dashboard\u003C/h2>\n\u003Cp>Sometimes you just inherit a product that has not been loved. The GoBiz dashboard was built for enterprise merchants by forking an internal portal. The portal was built on an internal front end framework “\u003Ca href=\"https://en.wikipedia.org/wiki/Tanjidor\">Tanjidor\u003C/a>” and the designers used to design in the browser and this meant that there were no design files. This meant that there was a dependency on the existing designers. So we decided to pick it up as a design initiative.\u003C/p>\n\u003Ch4 id=\"objectives-of-the-redesign\">Objectives of the redesign:\u003C/h4>\n\u003Col>\n\u003Cli>Reduce dependancy on the existing designer by\u003C/li>\n\u003Cli>Make the dashboard accessible via mobile web\u003C/li>\n\u003C/ol>\n\u003Ch4 id=\"what-we-did\">What we did:\u003C/h4>\n\u003Cp>In 2019, we (product design and research) conducted a heuristic evaluation to identify key issues. But post that due to issues with design bandwidth, the project was deprioritised.\u003C/p>\n\u003Cp>Fast forward to 2020, Hendri joined us on the GoBiz team and I assigned him to start work on the GoBiz Dashboard redesign as a way to familiarise himself with the product.\u003C/p>\n\u003Cp>We decided to design anything new with our web design system and not do it in the browser. Due to some luck, the “platformisation” of the Dashboard project got prioritised that quarter. However the PM was going to do it without a change to the UI. I convinced her to switch to the new UI. But given the sprint was beginning in 2 weeks, we were short of time. So we got a list of pages to work on a priority basis and started exploring. A lot of work was already done by Hendri however we had to now make the whole site look coherent.\u003C/p>\n\u003Cblockquote>\n\u003Cp>You can arrive at a different output using the same design system.\u003C/p>\n\u003C/blockquote>\n\u003Cp>We experimented with spacing and separators, navigation menu designs and modal overlays in the next 10 days to finalise the boilerplate for all the pages. Oh and yeah we also made it responsive.\u003C/p>\n\u003Cfigure class=\"image-figure\">\u003Cimg __ASTRO_IMAGE_=\"{"src":"Gobiz-web.png","alt":"","index":0}\">\u003C/figure>\n\u003Cfigure class=\"image-figure\">\u003Cimg __ASTRO_IMAGE_=\"{"src":"Gobiz-web3.png","alt":"After our redesign with Asphalt Web","index":0}\">\u003Cfigcaption>After our redesign with Asphalt Web\u003C/figcaption>\u003C/figure>\n\u003Ch4 id=\"what-we-could-not-do\">What we could not do:\u003C/h4>\n\u003Cul>\n\u003Cli>Fix the information architecture issues in every page.\u003C/li>\n\u003Cli>Figure out a table design that works well on mobile and desktop\u003C/li>\n\u003C/ul>\n\u003Ch4 id=\"outcome\">Outcome:\u003C/h4>\n\u003Cp>The GoMart designers were able to use the design system and build their module on the Dashboard with limited dependency on our team.\u003C/p>\n\u003Ch2 id=\"the-spots-app\">The Spots app\u003C/h2>\n\u003Cfigure class=\"image-figure\">\u003Cimg __ASTRO_IMAGE_=\"{"src":"spots.png","alt":"Left: Original, Right: Redesigned","index":0}\">\u003Cfigcaption>Left: Original, Right: Redesigned\u003C/figcaption>\u003C/figure>\n\u003Cp>The app they were using was a reskinned version of the default app provided by Landi(image on the left).\u003C/p>\n\u003Cp>I was asked to help out with it and I worked on a refresh for the app on a short timeline(image on the right)\u003C/p>\n\u003Cfigure class=\"image-figure\">\u003Cimg __ASTRO_IMAGE_=\"{"src":"QRIS-gobiz.webp","alt":"","index":0}\">\u003C/figure>\n\u003Cp>We later integrated this into the POS application on the GoBiz app.\u003C/p>\n\u003Ch1 id=\"midtrans\">Midtrans\u003C/h1>\n\u003Cp>In 2020, the Midtrans merchant onboarding was prioritized due to an external collaboration with Whatsapp.\u003C/p>\n\u003Cfigure class=\"image-figure\">\u003Cimg __ASTRO_IMAGE_=\"{"src":"midtrans-old.png","alt":"","index":0}\">\u003C/figure>\n\u003Cp>Given the urgency, I decided to ask Riyadhi to help the team with the wireframes. Riyadhi had previously worked on the merchant onboarding flow for the GoBiz app and I felt this would help us speed up the process.\u003C/p>\n\u003Cp>We had just completed the platformization exercise so Hendri and Firman were proficient with the new design system. The dev team too was confident that using the web design system was the best decision. This also made the flow mobile web compatible which was one of the identified merchant pain points.\u003C/p>\n\u003Cdiv class=\"image-figure-container\">\u003Cfigure class=\"image-figure\">\u003Cimg __ASTRO_IMAGE_=\"{"src":"midtrans-onboarding-1.png","alt":"","index":0}\">\u003C/figure>\u003Cfigure class=\"image-figure\">\u003Cimg __ASTRO_IMAGE_=\"{"src":"midtrans-onboarding-2.png","alt":"","index":0}\">\u003C/figure>\u003C/div>\n\u003Cp>So we shipped the new onboarding and saw lot of reduction in the drop offs.\u003C/p>\n\u003Cfigure class=\"image-figure\">\u003Cimg __ASTRO_IMAGE_=\"{"src":"midtrans-onboarding-impact.png","alt":"","index":0}\">\u003C/figure>\n\u003Ch3 id=\"outcome-1\">Outcome:\u003C/h3>\n\u003Cp>This project exposed most of the team to the ‘merchant onboarding’ problem space and a surprising side-effect of this was that project handover of the ‘corporate onboarding’ project could be handled by Hendri when Riyadhi was affected by Covid-19.\u003C/p>\n\u003Ch4 id=\"miscellaneous\">Miscellaneous:\u003C/h4>\n\u003Cp>I consulted on the GoBiz and the Midtrans marketing website.\u003C/p>\n\u003Csection data-footnotes=\"\" class=\"footnotes\">\u003Ch2 class=\"sr-only\" id=\"footnote-label\">Footnotes\u003C/h2>\n\u003Col>\n\u003Cli id=\"user-content-fn-1\">\n\u003Cp>Road to a Merchant Super App on the Gojek Blog \u003Ca href=\"https://www.gojek.io/blog/the-road-to-a-merchant-superapp\">https://www.gojek.io/blog/the-road-to-a-merchant-superapp\u003C/a> \u003Ca href=\"#user-content-fnref-1\" data-footnote-backref=\"\" aria-label=\"Back to reference 1\" class=\"data-footnote-backref\">↩\u003C/a>\u003C/p>\n\u003C/li>\n\u003C/ol>\n\u003C/section>",{"headings":193,"localImagePaths":240,"remoteImagePaths":241,"frontmatter":242,"imagePaths":243},[194,195,198,201,204,207,210,212,215,218,221,224,227,230,234,236,239],{"depth":44,"slug":38,"text":39},{"depth":37,"slug":196,"text":197},"gobiz-app","GoBiz app",{"depth":57,"slug":199,"text":200},"the-objectives-of-the-redesign-were","The objectives of the redesign were",{"depth":57,"slug":202,"text":203},"design-process","Design Process:",{"depth":57,"slug":205,"text":206},"user-testing","User testing:",{"depth":57,"slug":208,"text":209},"learnings-post-release","Learnings post release:",{"depth":57,"slug":79,"text":211},"Impact:",{"depth":37,"slug":213,"text":214},"gobiz-dashboard","GoBiz Dashboard",{"depth":57,"slug":216,"text":217},"objectives-of-the-redesign","Objectives of the redesign:",{"depth":57,"slug":219,"text":220},"what-we-did","What we did:",{"depth":57,"slug":222,"text":223},"what-we-could-not-do","What we could not do:",{"depth":57,"slug":225,"text":226},"outcome","Outcome:",{"depth":37,"slug":228,"text":229},"the-spots-app","The Spots app",{"depth":231,"slug":232,"text":233},1,"midtrans","Midtrans",{"depth":44,"slug":235,"text":226},"outcome-1",{"depth":57,"slug":237,"text":238},"miscellaneous","Miscellaneous:",{"depth":37,"slug":85,"text":86},[174,175,176,177,178,179,180,181,182,183,184,185,186,187],[],{"title":167,"description":168,"year":170,"company":131,"status":19,"image":183},[174,175,176,177,178,179,180,181,182,183,184,185,186,187],"hiring-jiva",{"id":244,"data":246,"body":250,"filePath":251,"digest":252,"rendered":253},{"title":247,"description":248,"year":249,"status":99},"Hiring Product Designers at Jiva","An overview of the product design hiring process at Jiva that we used to scale to 11+ designers","2022-2024","When I joined Jiva in January of 2022, as the Senior Design Manager of Product Design, we were a team of 2; me and Sai. We had to start building a team. I’ve never had the opportunity to build a team from scratch and it felt scary at first.\nWe had no defined process nor an evaluation criteria, just a product designer job description. It was well structured job description and spoke to the generalist designers we wanted to recruit but we were aware we needed to scale.\n\nSo with Nav's guidance, we designed a simple hiring flow keeping the good part of the older scrappy process while being mindful about the candidates and their time. \n\nOur process therefore was quite simple; \n\n### Round 0: Shortlisting Candidates\nWith our job description posted, we looked for candidates and their submissions to shortlist the ones we wanted to speak to. When Jiva was less known, we barely had any interested candidates and shortlisting was very easy.\nBut for the last set of job openings, we had a lot of demand making it impossible to screen efficiently. We encouraged people to send us Cover letters while applying rather than applying via the portal.\nThis acted as a fairly effective screening condition as not many ended up emailing us.\n\n### Round 1: Screening Call\nThis is the first experience a candidate has of Jiva’s design team and we want it to be the best.\nWe want to make the candidate comfortable and help them understand what Jiva is and what working here would be like.\nThis was the round where we discussed compensation in brief so that we could set expectations both upstream (with HR and leadership) and downstream (with the candidate).\nThe hiring manager (i.e., me) was the best person to have this conversation with the candidate.\n\nFor a candidate to make it through, they just needed to feel like they knew how to design, work in the team and someone I would want to have on my team.\nThe folks who blew my mind in this round inadvertently went to be key members of the team and probably the best skilled designers I've worked with.\n\n### Round 2: Presentation Round\nSince we were a small team with a short candidate pipeline, we didn't see value in having take home assignments or whiteboarding sessions, instead we opted for the presentation round. The jury for this round was composed\nof the other designers. We designed the jury based on the candidate. There would be a cultural mix of nationalities, genders and design disciplines in every jury panel. What we mainly measured in this round was\nthe capabilities of a product designer, (eventually we used our Job levels for this evaluation) and how they vibed with the jury panel. It wasn't enough that you had good work, you needed\nto fit in. Controversial maybe? but I felt strongly that getting people to play well together is key to building good design teams. In time, I've come to realize that just because you have technical chops\ndoesn't make you a good product designer. You also need to be kind, empathetic and collaborative. Technical skills can be learned, these values can not.\n\nIf you made it past this round, \"Congrats, welcome to the Jiva design team\" 🙌🏽\n\nFor everyone we rejected in Round 2, I tried to send a personal email to them explaining why they didn't make it. But this was hard to follow 100% of the time and I'm sure I forgot to send a few.\n\n### Round 3(?): Stakeholder Round\nFor L3 (our highest IC level) hiring, we added an extra round. \nThis was a chat with a Lead product manager to help gauge how the designer would fit within the Product and their product thinking abilities.\nThese designers would function like leads and own design for their product vertical. \n\n### Round 4: HR Round\nThere was a final round(or two) where either Nav or HR would have a conversation with the employee and dealt with the technicalities around compensation and hiring policies.\n\nIn time, we grew the team to 11 product designers working on 5+ mobile and web apps across multiple business systems (farmer, collector, retailer).","src/content/work/hiring-jiva/index.md","a71264957ff07f2d",{"html":254,"metadata":255},"\u003Cp>When I joined Jiva in January of 2022, as the Senior Design Manager of Product Design, we were a team of 2; me and Sai. We had to start building a team. I’ve never had the opportunity to build a team from scratch and it felt scary at first.\nWe had no defined process nor an evaluation criteria, just a product designer job description. It was well structured job description and spoke to the generalist designers we wanted to recruit but we were aware we needed to scale.\u003C/p>\n\u003Cp>So with Nav’s guidance, we designed a simple hiring flow keeping the good part of the older scrappy process while being mindful about the candidates and their time.\u003C/p>\n\u003Cp>Our process therefore was quite simple;\u003C/p>\n\u003Ch3 id=\"round-0-shortlisting-candidates\">Round 0: Shortlisting Candidates\u003C/h3>\n\u003Cp>With our job description posted, we looked for candidates and their submissions to shortlist the ones we wanted to speak to. When Jiva was less known, we barely had any interested candidates and shortlisting was very easy.\nBut for the last set of job openings, we had a lot of demand making it impossible to screen efficiently. We encouraged people to send us Cover letters while applying rather than applying via the portal.\nThis acted as a fairly effective screening condition as not many ended up emailing us.\u003C/p>\n\u003Ch3 id=\"round-1-screening-call\">Round 1: Screening Call\u003C/h3>\n\u003Cp>This is the first experience a candidate has of Jiva’s design team and we want it to be the best.\nWe want to make the candidate comfortable and help them understand what Jiva is and what working here would be like.\nThis was the round where we discussed compensation in brief so that we could set expectations both upstream (with HR and leadership) and downstream (with the candidate).\nThe hiring manager (i.e., me) was the best person to have this conversation with the candidate.\u003C/p>\n\u003Cp>For a candidate to make it through, they just needed to feel like they knew how to design, work in the team and someone I would want to have on my team.\nThe folks who blew my mind in this round inadvertently went to be key members of the team and probably the best skilled designers I’ve worked with.\u003C/p>\n\u003Ch3 id=\"round-2-presentation-round\">Round 2: Presentation Round\u003C/h3>\n\u003Cp>Since we were a small team with a short candidate pipeline, we didn’t see value in having take home assignments or whiteboarding sessions, instead we opted for the presentation round. The jury for this round was composed\nof the other designers. We designed the jury based on the candidate. There would be a cultural mix of nationalities, genders and design disciplines in every jury panel. What we mainly measured in this round was\nthe capabilities of a product designer, (eventually we used our Job levels for this evaluation) and how they vibed with the jury panel. It wasn’t enough that you had good work, you needed\nto fit in. Controversial maybe? but I felt strongly that getting people to play well together is key to building good design teams. In time, I’ve come to realize that just because you have technical chops\ndoesn’t make you a good product designer. You also need to be kind, empathetic and collaborative. Technical skills can be learned, these values can not.\u003C/p>\n\u003Cp>If you made it past this round, “Congrats, welcome to the Jiva design team” 🙌🏽\u003C/p>\n\u003Cp>For everyone we rejected in Round 2, I tried to send a personal email to them explaining why they didn’t make it. But this was hard to follow 100% of the time and I’m sure I forgot to send a few.\u003C/p>\n\u003Ch3 id=\"round-3-stakeholder-round\">Round 3(?): Stakeholder Round\u003C/h3>\n\u003Cp>For L3 (our highest IC level) hiring, we added an extra round.\nThis was a chat with a Lead product manager to help gauge how the designer would fit within the Product and their product thinking abilities.\nThese designers would function like leads and own design for their product vertical.\u003C/p>\n\u003Ch3 id=\"round-4-hr-round\">Round 4: HR Round\u003C/h3>\n\u003Cp>There was a final round(or two) where either Nav or HR would have a conversation with the employee and dealt with the technicalities around compensation and hiring policies.\u003C/p>\n\u003Cp>In time, we grew the team to 11 product designers working on 5+ mobile and web apps across multiple business systems (farmer, collector, retailer).\u003C/p>",{"headings":256,"localImagePaths":272,"remoteImagePaths":273,"frontmatter":274,"imagePaths":275},[257,260,263,266,269],{"depth":44,"slug":258,"text":259},"round-0-shortlisting-candidates","Round 0: Shortlisting Candidates",{"depth":44,"slug":261,"text":262},"round-1-screening-call","Round 1: Screening Call",{"depth":44,"slug":264,"text":265},"round-2-presentation-round","Round 2: Presentation Round",{"depth":44,"slug":267,"text":268},"round-3-stakeholder-round","Round 3(?): Stakeholder Round",{"depth":44,"slug":270,"text":271},"round-4-hr-round","Round 4: HR Round",[],[],{"title":247,"description":248,"year":249,"status":99},[],"international",{"id":276,"data":278,"body":282,"filePath":283,"assetImports":284,"digest":294,"rendered":295},{"title":279,"description":280,"image":281,"year":130,"company":131,"status":19},"Taking GoBiz international","What I learnt from launching Gojek's GoBiz app for different Southeast Asian Countries","__ASTRO_IMAGE_./thai-header.jpeg","At Practo, I had my first experience designing for markets outside India. Singapore was one of the strongest regions for the Practo Ray product, and it encouraged us to build features tailored to their dentists like [Dental Charting](https://help.practo.com/practo-ray/emr/dental-emr/all-about-dental-charting/).\n\nBy 2015, we began rolling out the Practo Ray app to Malaysia, Indonesia, the Philippines, and Brazil. Looking back, our localisation efforts were still fairly shallow. Most of the adjustments were limited to currency, date and number formatting, or small copy tweaks.\n\nScaling the GoBiz app to Thailand, Vietnam, and Singapore was completely different. Just translating the interface was not an option. We did research to understand local restaurant workflows (e.g., Hawker Centres in Singapore), worked with the local team to understand local terminologies and cultural nuances, and studied how food ordering worked.\n\n### Collaboration and Organization\nBut first, every project needs a start. GoBiz functioned as a platform with multiple teams contributing to it. So when we prepared for a new country launch, it became crucial to have a transparent and collaborative approach. That's where Asana came in. I created the 'GoBiz International Design' template and assigned tasks to the different designers. This functioned as our team's design tracker and was referenced during the weekly SOS meetings (Scrum of Scrums) run by the program managers.\n\n![The GoBiz International Design template in Asana](./asana.png)\n\nFor the design work itself, we set up a new Sketch file in Abstract for every country launch instead of adding changes to the existing files. This kept file sizes manageable and reduced merge conflicts in the Master branch. It also made it much easier for other teams to locate the relevant designs without needing to check with us.\n\n### Typography\nDesigning for languages that use only Latin characters is fairly straightforward because most fonts support them. But when you need to support non-latin scripts like Thai, Vietnamese, and Simplified Chinese, things get a little complicated typographically.\nOur brand typeface, Maison Neue, did not support these scripts, so the app fell back to system fonts. In Thailand, this caused visible inconsistencies in size and styling.\nThis led to many merchants using their device accessibility settings to increase their font size, which caused our layouts to break.\n![Vietnamese rendering in Maison Neue](./viet.png)\n\nVietnamese had its own challenges. Missing glyphs resulted in broken, mismatched text because unsupported characters were rendered in a different fallback format. \nMaison Neue does not support several important Vietnamese glyphs such as ờ, ư, ằ, ố, ế, ữ, ả, ẻ, ễ, ỉ, ỏ, ủ, ư, ứ, ừ, ử, ữ, ự, ỷ.\n\nBy the time we started work on the Singapore app, I realized we needed to address this and sat down with the brand and design system leads to select a reliable fallback font. \nWe chose Noto Sans, which is free, widely supported, and covered all the scripts we needed. We replaced Maison Neue with Noto Sans in our GoBiz International app.\n\n##### P.S. \"wkwkwkwk\" and \"5555555\" are common ways of typing laughter in Indonesian and Thai texting culture.\n\n\u003Cdiv class=\"impact-images\" style=\"display: grid; grid-template-columns: 1fr 1fr 1fr; gap: 1rem;\">\n\n![Placing an order to test our flow](./dogfooding.png)\n\n![Observing how they track orders](./user-behaviour.png)\n\n![Checking out the competitors](./competitors.png)\n\n\u003C/div>\n\n### Managing Copy\nManaging design files is relatively easy compared to managing multi-country copy. When we started supporting multiple languages, tools like Lokalise did not exist in our workflow. We relied entirely on Google Docs and Google Sheets.\n\n![How we managed copy in Google Docs](./copy-doc.png)\n\nWhen the product supported only Bahasa Indonesia, all GoBiz copy lived inside a single Google Doc. Over time, the document grew extremely long and slow. I had seen other teams use sheets for managing multi-language copy, so I worked with our UX writer, Lauditta, to create a template suited to our needs.\n\nDevelopers manage strings using “keys,” and we needed a way to map each key to the right line of copy. We realised too late how important this mapping was. Migrating retroactively meant spending a large amount of time copy-pasting, verifying strings, and searching through sheets.\n\n![How we managed copy in Google Sheets](./copy-sheets.png)\n\nWe also wanted screen references to help reviewers see copy in context. This was especially useful for UX writers in other countries, as well as QA and designers who did not speak the local languages. The release of Google Sheets’ “Insert picture in cell” feature was a huge help for this.\nGojek eventually moved to using [Lokalise](https://lokalise.com) for its copy management [^1] \n\n[^1]: You can read more about their International copy process on the blog by the Thai and Viet UX writer https://www.gojek.io/blog/language-no-bar-how-we-localise-ux-copies-at-gojek\n\n### Learnings\n- Scaling GoBiz across Thailand, Vietnam, and Singapore taught me that localisation is never something you add after the product is built. Even after launch, every new feature needs to be evaluated through the lens of each country. The same care you put into the initial rollout has to continue, otherwise the product quietly drifts back toward the needs of the base market.\n\n- There's also an organizational reality that often gets ignored. Supporting multiple markets properly sometimes requires reshaping how teams work, how decisions are made, and who is involved in the roadmap. But these shifts take time, and they rarely get prioritised unless there is a clear business outcome tied to them. \nAt Gojek, this misalignment became clear. Each international market operated under its own brand and leadership, which meant we couldn’t consistently involve those teams in product planning. As a result, our roadmaps naturally skewed toward Indonesia, and we only built out some must-have features for other countries. \n\n### Closing thoughts\n\nGojek eventually exited Thailand and Vietnam, and its presence in Singapore today is minimal. Looking back, designing GoBiz for other countries was a highly rewarding and learning experience. I got to experience new cultures and work with people from different nationalities. Those lessons stayed with us long after the product lines, org charts, and roadmaps changed.\n\n![The Gojek research team with a restaurant owner in Bangkok](./thai-research.jpeg)","src/content/work/international/index.md",[285,286,287,288,289,290,291,292,293],"./asana.png","./viet.png","./dogfooding.png","./user-behaviour.png","./competitors.png","./copy-doc.png","./copy-sheets.png","./thai-research.jpeg","./thai-header.jpeg","9be9459a81518519",{"html":296,"metadata":297},"\u003Cp>At Practo, I had my first experience designing for markets outside India. Singapore was one of the strongest regions for the Practo Ray product, and it encouraged us to build features tailored to their dentists like \u003Ca href=\"https://help.practo.com/practo-ray/emr/dental-emr/all-about-dental-charting/\">Dental Charting\u003C/a>.\u003C/p>\n\u003Cp>By 2015, we began rolling out the Practo Ray app to Malaysia, Indonesia, the Philippines, and Brazil. Looking back, our localisation efforts were still fairly shallow. Most of the adjustments were limited to currency, date and number formatting, or small copy tweaks.\u003C/p>\n\u003Cp>Scaling the GoBiz app to Thailand, Vietnam, and Singapore was completely different. Just translating the interface was not an option. We did research to understand local restaurant workflows (e.g., Hawker Centres in Singapore), worked with the local team to understand local terminologies and cultural nuances, and studied how food ordering worked.\u003C/p>\n\u003Ch3 id=\"collaboration-and-organization\">Collaboration and Organization\u003C/h3>\n\u003Cp>But first, every project needs a start. GoBiz functioned as a platform with multiple teams contributing to it. So when we prepared for a new country launch, it became crucial to have a transparent and collaborative approach. That’s where Asana came in. I created the ‘GoBiz International Design’ template and assigned tasks to the different designers. This functioned as our team’s design tracker and was referenced during the weekly SOS meetings (Scrum of Scrums) run by the program managers.\u003C/p>\n\u003Cfigure class=\"image-figure\">\u003Cimg __ASTRO_IMAGE_=\"{"src":"./asana.png","alt":"The GoBiz International Design template in Asana","index":0}\">\u003Cfigcaption>The GoBiz International Design template in Asana\u003C/figcaption>\u003C/figure>\n\u003Cp>For the design work itself, we set up a new Sketch file in Abstract for every country launch instead of adding changes to the existing files. This kept file sizes manageable and reduced merge conflicts in the Master branch. It also made it much easier for other teams to locate the relevant designs without needing to check with us.\u003C/p>\n\u003Ch3 id=\"typography\">Typography\u003C/h3>\n\u003Cfigure class=\"image-figure\">\u003Cimg __ASTRO_IMAGE_=\"{"src":"./viet.png","alt":"Vietnamese rendering in Maison Neue","index":0}\">\u003Cfigcaption>Vietnamese rendering in Maison Neue\u003C/figcaption>\u003C/figure>\n\u003Cp>Vietnamese had its own challenges. Missing glyphs resulted in broken, mismatched text because unsupported characters were rendered in a different fallback format.\u003Cbr>\nMaison Neue does not support several important Vietnamese glyphs such as ờ, ư, ằ, ố, ế, ữ, ả, ẻ, ễ, ỉ, ỏ, ủ, ư, ứ, ừ, ử, ữ, ự, ỷ.\u003C/p>\n\u003Cp>By the time we started work on the Singapore app, I realized we needed to address this and sat down with the brand and design system leads to select a reliable fallback font.\nWe chose Noto Sans, which is free, widely supported, and covered all the scripts we needed. We replaced Maison Neue with Noto Sans in our GoBiz International app.\u003C/p>\n\u003Ch5 id=\"ps-wkwkwkwk-and-5555555-are-common-ways-of-typing-laughter-in-indonesian-and-thai-texting-culture\">P.S. “wkwkwkwk” and “5555555” are common ways of typing laughter in Indonesian and Thai texting culture.\u003C/h5>\n\u003Cdiv class=\"impact-images\" style=\"display: grid; grid-template-columns: 1fr 1fr 1fr; gap: 1rem;\">\n\u003Cfigure class=\"image-figure\">\u003Cimg __ASTRO_IMAGE_=\"{"src":"./dogfooding.png","alt":"Placing an order to test our flow","index":0}\">\u003Cfigcaption>Placing an order to test our flow\u003C/figcaption>\u003C/figure>\n\u003Cfigure class=\"image-figure\">\u003Cimg __ASTRO_IMAGE_=\"{"src":"./user-behaviour.png","alt":"Observing how they track orders","index":0}\">\u003Cfigcaption>Observing how they track orders\u003C/figcaption>\u003C/figure>\n\u003Cfigure class=\"image-figure\">\u003Cimg __ASTRO_IMAGE_=\"{"src":"./competitors.png","alt":"Checking out the competitors","index":0}\">\u003Cfigcaption>Checking out the competitors\u003C/figcaption>\u003C/figure>\n\u003C/div>\n\u003Ch3 id=\"managing-copy\">Managing Copy\u003C/h3>\n\u003Cp>Managing design files is relatively easy compared to managing multi-country copy. When we started supporting multiple languages, tools like Lokalise did not exist in our workflow. We relied entirely on Google Docs and Google Sheets.\u003C/p>\n\u003Cfigure class=\"image-figure\">\u003Cimg __ASTRO_IMAGE_=\"{"src":"./copy-doc.png","alt":"How we managed copy in Google Docs","index":0}\">\u003Cfigcaption>How we managed copy in Google Docs\u003C/figcaption>\u003C/figure>\n\u003Cp>When the product supported only Bahasa Indonesia, all GoBiz copy lived inside a single Google Doc. Over time, the document grew extremely long and slow. I had seen other teams use sheets for managing multi-language copy, so I worked with our UX writer, Lauditta, to create a template suited to our needs.\u003C/p>\n\u003Cp>Developers manage strings using “keys,” and we needed a way to map each key to the right line of copy. We realised too late how important this mapping was. Migrating retroactively meant spending a large amount of time copy-pasting, verifying strings, and searching through sheets.\u003C/p>\n\u003Cfigure class=\"image-figure\">\u003Cimg __ASTRO_IMAGE_=\"{"src":"./copy-sheets.png","alt":"How we managed copy in Google Sheets","index":0}\">\u003Cfigcaption>How we managed copy in Google Sheets\u003C/figcaption>\u003C/figure>\n\u003Cp>We also wanted screen references to help reviewers see copy in context. This was especially useful for UX writers in other countries, as well as QA and designers who did not speak the local languages. The release of Google Sheets’ “Insert picture in cell” feature was a huge help for this.\nGojek eventually moved to using \u003Ca href=\"https://lokalise.com\">Lokalise\u003C/a> for its copy management \u003Csup>\u003Ca href=\"#user-content-fn-1\" id=\"user-content-fnref-1\" data-footnote-ref=\"\" aria-describedby=\"footnote-label\">1\u003C/a>\u003C/sup>\u003C/p>\n\u003Ch3 id=\"learnings\">Learnings\u003C/h3>\n\u003Cul>\n\u003Cli>\n\u003Cp>Scaling GoBiz across Thailand, Vietnam, and Singapore taught me that localisation is never something you add after the product is built. Even after launch, every new feature needs to be evaluated through the lens of each country. The same care you put into the initial rollout has to continue, otherwise the product quietly drifts back toward the needs of the base market.\u003C/p>\n\u003C/li>\n\u003Cli>\n\u003Cp>There’s also an organizational reality that often gets ignored. Supporting multiple markets properly sometimes requires reshaping how teams work, how decisions are made, and who is involved in the roadmap. But these shifts take time, and they rarely get prioritised unless there is a clear business outcome tied to them.\nAt Gojek, this misalignment became clear. Each international market operated under its own brand and leadership, which meant we couldn’t consistently involve those teams in product planning. As a result, our roadmaps naturally skewed toward Indonesia, and we only built out some must-have features for other countries.\u003C/p>\n\u003C/li>\n\u003C/ul>\n\u003Ch3 id=\"closing-thoughts\">Closing thoughts\u003C/h3>\n\u003Cp>Gojek eventually exited Thailand and Vietnam, and its presence in Singapore today is minimal. Looking back, designing GoBiz for other countries was a highly rewarding and learning experience. I got to experience new cultures and work with people from different nationalities. Those lessons stayed with us long after the product lines, org charts, and roadmaps changed.\u003C/p>\n\u003Cfigure class=\"image-figure\">\u003Cimg __ASTRO_IMAGE_=\"{"src":"./thai-research.jpeg","alt":"The Gojek research team with a restaurant owner in Bangkok","index":0}\">\u003Cfigcaption>The Gojek research team with a restaurant owner in Bangkok\u003C/figcaption>\u003C/figure>\n\u003Csection data-footnotes=\"\" class=\"footnotes\">\u003Ch2 class=\"sr-only\" id=\"footnote-label\">Footnotes\u003C/h2>\n\u003Col>\n\u003Cli id=\"user-content-fn-1\">\n\u003Cp>You can read more about their International copy process on the blog by the Thai and Viet UX writer \u003Ca href=\"https://www.gojek.io/blog/language-no-bar-how-we-localise-ux-copies-at-gojek\">https://www.gojek.io/blog/language-no-bar-how-we-localise-ux-copies-at-gojek\u003C/a> \u003Ca href=\"#user-content-fnref-1\" data-footnote-backref=\"\" aria-label=\"Back to reference 1\" class=\"data-footnote-backref\">↩\u003C/a>\u003C/p>\n\u003C/li>\n\u003C/ol>\n\u003C/section>",{"headings":298,"localImagePaths":317,"remoteImagePaths":318,"frontmatter":319,"imagePaths":320},[299,302,303,307,310,313,316],{"depth":44,"slug":300,"text":301},"collaboration-and-organization","Collaboration and Organization",{"depth":44,"slug":58,"text":59},{"depth":304,"slug":305,"text":306},5,"ps-wkwkwkwk-and-5555555-are-common-ways-of-typing-laughter-in-indonesian-and-thai-texting-culture","P.S. “wkwkwkwk” and “5555555” are common ways of typing laughter in Indonesian and Thai texting culture.",{"depth":44,"slug":308,"text":309},"managing-copy","Managing Copy",{"depth":44,"slug":311,"text":312},"learnings","Learnings",{"depth":44,"slug":314,"text":315},"closing-thoughts","Closing thoughts",{"depth":37,"slug":85,"text":86},[285,286,287,288,289,290,291,292],[],{"title":279,"description":280,"year":130,"company":131,"image":293,"status":19},[285,286,287,288,289,290,291,292],"jiva-lite",{"id":321,"data":323,"body":328,"filePath":329,"assetImports":330,"digest":342,"rendered":343},{"title":324,"description":325,"image":326,"year":327,"company":18,"status":19},"Jiva Lite","Building a farmer-centric experience for buying Corn in rural Indonesia leveraging Whatsapp","__ASTRO_IMAGE_./jivalite.jpg","2024-2025","When I joined Jiva in 2022, we had been leveraging collectors in rural areas to facilitate our business model.\n\nThe harvest of a smallholder corn farmer is typically around 2.5k-3k tons. The economics of sending it to the buyer isn't economically viable for such a small quantity when you factor in labour cost & transport cost. Additionally the ability to evaluate quality at the farmer level is approximate.\nCollectors helped fill this gap by aggregating corn for dispatch from multiple farmers and using moisture meters to estimate quality of the corn. \n\nJiva’s business model was working with buyers to acquire purchase orders for the corn and coordinate with the collectors to dispatch to feedmills to get the best price. \nThis wasn't a disruptionary model. The concept of middlemen have always existed in agricultural systems. What was different was the concept of a single entity who's presence across provinces helped get better prices. \nOur Collectors earned commission for selling through us and our Farmers got the best price. \n\nBut the question remained.. **could we do even better?** and that's where Jiva Lite came in.\n\n\n## Challenge\n\n- One of the reasons we resorted to the micro-collector model was the technical literacy and mobile device penetration in rural Indonesia. Most farmers still used feature phones and many families just had a shared single device usually operated by the children or the wife. For those who did have a smartphone device, local storage and internet were critical constraints. \nIt didn't make sense for them to keep our apps on their phones across seasons and our churn data suggested that as well.\n\n- Our research had shown us that the Sahabat Jiva android app was a complex system compared to the real world way to buying and selling corn\n\n- From the business side, this meant our customer acqusition funnel was fairly expensive and with the commissions and price fluctuations of the market, the Gross Contribution (GC) that we earned per kg was far below what we wanted to be at.\n\n## Role\nMy role was a fluid one in the project where at the start I was leading the product design effort and managing stakeholders but eventually transitioned to co-owning the project and focusing on the digital marketing efforts over the 1 year of operation. \n\n## Solution\n\n![Early Jiva Lite app wireframes](./lite-wire.png \"Early Jiva Lite app wireframes\")\n\nThe first idea for Jiva Lite came out of our efforts to simplify the Sahabat Jiva App information architecture and workflows. But it took a few more months before we got a chance to try to solve this.\nThe overwhelming idea at that time was to make another app albeit a \"lite\" one. But a few of us felt that Whatsapp was the way to go. So I used Landbot to quickly prototype how a Whatsapp based flow would look like.\n\n#### Why Whatsapp? \nMeta has deep penetration in Indonesia. Indonesia doesnt have net neutrality laws and hence Meta, Google, Netflix, etc have mobile plans that enabled unlimited usage of their services. \nThis is one of the reason that Facebook and Whatsapp are the communication tool of choice in our users. This meant that \nwe could be assured that unlike a mobile app, our target audience would definitely have Whatsapp on their phones.\n\nAfter pitching this to leadership, we got buyin to use the Whatsapp flow as a pilot project to test out the viability of the Jiva Lite business model.\n\n#### Why was Jiva Lite different?\n- If Jiva Lite had to succeed then it should be economically viable while at the same time, it should not cannibalize our existing businesses. So the pricing logic we set was to keep our offering price at 100idr/kg less than the price we showed in our Sahabat Jiva app. \n- A recent tax exemption made it easy for us to operate at the small scale without needing unnecessary documentation like KTPs\n- For the first time (probably), small holders could sell direct to our buyers irrespective of the volume of their harvest and get paid within a few hours.\n- Meta Ads and Whatsapp QRs let users quickly get into our flow and check prices.\n\n### Building the MVP\nA small team got together to work on this part time. Designing the first flow to be as simple took a few iterations. We used Figma and FigJam a lot to align everyone and used Slack's inbuilt project management system to keep us on track.\nWeekly syncs were run to share progress with the larger group of stakeholders and monthly meetings with the CEO.\n\n![Figjam](./figjam.png \"Blueprinting\")\n\nOur first version was built using Whatsapp Flows and simplified the crop buying flow to just 3 steps; View Prices, Register and Send Truck. \nWe offered farmers the option of selecting between 3 feedmills based on their corn quality. Prices would be updated everyday.\n\n![Designs for the first release version on Figma](./jivalitev1.png \"Designs for the first release version on Figma\")\n\n### Preparing for Go-To-Market\n\n#### Onboarding internal teams:\nWe ran sessions with our field agents, customer service agents and marketing teams to onboard them onto the pilot project. I prepared an \"objection handling\" (a FAQ document) for CX team to use for answering any queries they may receive on their channels.\nSpeaking to our on-ground field agents helped us address their concerns about Jiva Lite and its impact on their operations.\n\n#### Selecting a region for piloting:\nWe had to negotiate with stakeholders for selecting regions due to concerns around our existing micro-collector density as well as time of the year and , we decided to go with the regencies closest to Makassar (South Sulawesi) ; Maros and Takalar. \nThis meant that the distances to be travelled by the farmers to our buyers were just a few hours away.\n\n#### On field marketing:\nWe got 1 field marketer, Erwin, on loan from the growth team for the efforts on on-ground canvassing by meeting farmer groups (Gapoktans).\n\n#### Jiva Lite Website:\nWe built a website so that we could provide a social proof that Jiva Lite was infact an offering from Jiva and not a scam. The website had prices which we manually updated and directed users to the Whatsapp number.\n\n\u003Ciframe width=\"560\" height=\"315\" src=\"https://www.youtube.com/embed/kCQByHg5kBI?si=MZe2Z8pwF-LeETQI\" title=\"YouTube video player\" frameborder=\"0\" allow=\"accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" allowfullscreen>\u003C/iframe>\n\n#### Doing things that don't scale:\nWe didn't build an in-flow way to add a farmer's bank account details. We resorted instead to use a manual system of getting the information from the farmer and getting CX team to add them to the system. This enabled us to ship faster and prevented user error from entering the wrong information. Where possible we pre-filled dummy data (e.g., user address) in the backend because we didnt want to build without valdiating our idea at this stage.\n\n## Post Launch of the MVP\n\n![Karan, Nav, Idul and Erwin meeting Saripuddin and other farmers](./jivalite-ground.png)\n\nWe launched the first version to production on August 7th, but we didnt get our first transaction till Nav, Karan, Idul and Erwin visited Mr. Saripuddin and convinced him to send the corn to our collection centre.\nOn August 23rd, Saripuddin (seen in the cover image) became the first farmer to have sent us the corn directly. That first transaction was the litmus test that our systems failed, however with Karan co-ordinating with Erwin, we somehow managed to pull through.\n\n>“I made over IDR 3,000,000 with my truck! I invite all my friends to send trucks using Jiva Lite.”\n> — Saripuddin\n\nSaripuddin immediately saw the value Jiva Lite brought to him and instantly became our ambassador convincing multiple farmers in his village to send us corn over the year.\nWithin a month, we hit the milestone of 50 MT and started thinking of the next iteration for Jiva Lite.\n\nPersonally, the first transaction was a feeling unlike any other that my body had experienced. That day, I was unable to act rationally because I was completely blown away by the fact that 14 days after release we secured our first farmer and he saw the value we were providing. \nThere was a lot of time and effort that went into reaching this exact point and it felt glorious.\n\n## Learnings from the Pilot\n#### Selling breakdown:\nWe made a simple google sheets template to generate a breakdown that we sent to every farmer which helped them understand how much they were earning and what was the quality of their corn.\n\n#### Backend Issues: \nWe had not handled user creation of churned/deleted users and this is what caused our first transaction to fail. (Murphy's Law, amirite?)\n\n![spiderkaran](./spiderkaran.png)\n\n#### Changing behaviour isn't easy:\nWhen farmers are used to dealing with a broken system, 'a too-good to be true' deal like Jiva Lite feels unrealistic. Furthermore, farmers and local buyers tend to have a personal relationship that isnt easy to overcome. At the end of the day, Jiva is an external entity while the buyer may be a neighbour, a relative or their money lender.\n\n#### Flow still complex:\nWithout our on-field agents, getting users to navigate Whatsapp Flows wasnt easy. Whatsapp flows may seem simple to us, but for our target users, they were complex. We realized that just because they used Facebook and Whatsapp didn't mean that they were familiar navigating similar interfaces. We needed to re-do our flow.\n\n## Building V2\n\nFrom a product point of view, we realised the following shortcomings:\n- The current implementation didn't enable us to A/B test our flow fast enough. \n- There was no way for us to intervene in the flow to guide users through it if required\n- There was no way to re-target and engage our users\n\nWe decided to look if any pre-existing solutions would help us solve this. After an evaluation of several Whatsapp business providers, we decided to go ahead with Landbot. We were already familiar with Landbot and it met all the above criteria.\n\n![A small portion of the Landbot flow](./landbot.png)\n\n**Product:** We re-designed the whole flow to be more like a chat-bot conversation as Landbot didnt support Whatsapp flows. This unfortunately took longer than we planned for and we finally released in early January 2025.\n\n**Marketing:** While we built, we went ahead and started Meta Ads and sending Price Update notifications to users in our funnel. We felt the ads themselves may not be efficient at communicating the concept of Jiva Lite so Tyo and Nav created a few marketing videos to help us.\n\n## Post V2\n\n- Once Landbot released interacting with our users in the funnel became easy. Our Research Coordinators stepped in to own the role of helping guide our users through the funnel. They did a wonderful job (outside of their job description) and even converted a few sales purely via chat.\n\n- Our successful pilot had enabled us to get a small budget approved which allowed us to hire a few more Jive Lite Operators (or JLO's as we called them) to do outreach on ground. We also explored using Sentinel satellite data to help our JLOs narrow their canvassing regions to those being harvested.\n\n![Shakti, Abhishek and I travelled to Gorontalo to figure out if we could launch Jiva Lite there](./gorontalo.jpeg)\n\n- We wanted to scale our solution to other regions so we started expanding to Lampung, Sumatra and Central Java and explored building out Jiva Lite for other crops like Rubber. \n\n- We ran A/B tests and simplified our flow futher. Designed different types of ads; static, videos, localized (Bugis and Bahasa Indonesia) and even engaged social media influencers.\n\n## Final thoughts\n\n- Our digital conversion (Ads - Whatsapp)was near 0 throughout the time of operation. We tried a lot of different approaches but weren't able to get any organic sale from the digital channel. \n\n- Almost 98% of our sales came via our JLOs. This meant scaling volume would directly need more feet on ground and that was seen as expensive.\n\n![Some ads we made for recruiting drossers](./dross.png)\n\n- We uncovered certain systemic issues like Farmer debt, Cash payments (to avoid tax), Drossing systems. We attempted to solve Drossing (separating Corn kernels from Cob) by procuring and \nrenting out drossing machines and even built a simple advertising based funnel to acquire potential customers for this service. But we couldn't solve for the others with our budgetary constraints and the high level of risk associated with them.\n\n- Though I have attempted to write out the project in detail, there is still a lot that I feel I have left out because building a product and running it takes you in so many different directions. You encounter various problems and inefficiencies, some you solve and others you can't.\nThe experience takes a lot out of you but in the end, I am glad I got the opportunity to build a product with this level of ownership.\n\n## Impact\nIn the one year of operation, we scaled Jiva Lite from 0 to 600 registered users who sold 4102 MT of corn. With a margin of 100 IDR/kg, we generated around 24k USD of gross contribution (Additional earnings from sales from trading this corn added an additional 200 IDR/kg, which has not been counted here)\n\n\u003Cdiv class=\"impact-images\" style=\"display: grid; grid-template-columns: 1fr 3fr; gap: 1rem;\">\n\n![](./jl-impact-1.png)\n\n![](./jl-impact-2.png)\n\n\u003C/div>\n\nBehaviourally though, we were able to bring meaningful improvements into the lives of the Farmers in a few provinces of South Sulawesi. Most farmers who transacted with us made about 2.5-3 million IDR(~$180 USD) more than they would otherwise.\nEven after Jiva Lite shut down, a few of the farmers continued to deal directly with the collection centres and improve their collective earnings.\n\n## Team\nIt takes a village to run a project like this and almost everyone in the Jiva design team contributed towards this project. I couldnt have done this without Karan owning the offline side, Nilesh running the product sprint and Shakti managing the JLO's. \n\nNav, Sai and Tyo worked on the initial flow designs and Niraj took the reigns towards the end, Kesha on the UX copy, and Karan and Bharath on the Service Design. \nAsa, Idul, Aldi and El contributed heavily on the User research side often intervening in our workflow to helpg guide our Farmers. \nAkshay Koul led the Engineering team with Kalpesh and Mani, Rajlakshmi on QA. DJ for Data Dashboards. Gada and Salma on Marketing. Aiko & Idayanti helped us from the CX team.\n\nAnd we really couldnt have done as much as we did without our Jiva Lite Operators Erwin, Firman, Rahma, Nur Faisyah, Ainun, Irsyam, Rajab & Fery.","src/content/work/jiva-lite/index.md",[331,332,333,334,335,336,337,338,339,340,341],"./lite-wire.png","./figjam.png","./jivalitev1.png","./jivalite-ground.png","./spiderkaran.png","./landbot.png","./gorontalo.jpeg","./dross.png","./jl-impact-1.png","./jl-impact-2.png","./jivalite.jpg","d755c686dd4dbcfe",{"html":344,"metadata":345},"\u003Cp>When I joined Jiva in 2022, we had been leveraging collectors in rural areas to facilitate our business model.\u003C/p>\n\u003Cp>The harvest of a smallholder corn farmer is typically around 2.5k-3k tons. The economics of sending it to the buyer isn’t economically viable for such a small quantity when you factor in labour cost & transport cost. Additionally the ability to evaluate quality at the farmer level is approximate.\nCollectors helped fill this gap by aggregating corn for dispatch from multiple farmers and using moisture meters to estimate quality of the corn.\u003C/p>\n\u003Cp>Jiva’s business model was working with buyers to acquire purchase orders for the corn and coordinate with the collectors to dispatch to feedmills to get the best price.\nThis wasn’t a disruptionary model. The concept of middlemen have always existed in agricultural systems. What was different was the concept of a single entity who’s presence across provinces helped get better prices.\nOur Collectors earned commission for selling through us and our Farmers got the best price.\u003C/p>\n\u003Cp>But the question remained.. \u003Cstrong>could we do even better?\u003C/strong> and that’s where Jiva Lite came in.\u003C/p>\n\u003Ch2 id=\"challenge\">Challenge\u003C/h2>\n\u003Cul>\n\u003Cli>\n\u003Cp>One of the reasons we resorted to the micro-collector model was the technical literacy and mobile device penetration in rural Indonesia. Most farmers still used feature phones and many families just had a shared single device usually operated by the children or the wife. For those who did have a smartphone device, local storage and internet were critical constraints.\nIt didn’t make sense for them to keep our apps on their phones across seasons and our churn data suggested that as well.\u003C/p>\n\u003C/li>\n\u003Cli>\n\u003Cp>Our research had shown us that the Sahabat Jiva android app was a complex system compared to the real world way to buying and selling corn\u003C/p>\n\u003C/li>\n\u003Cli>\n\u003Cp>From the business side, this meant our customer acqusition funnel was fairly expensive and with the commissions and price fluctuations of the market, the Gross Contribution (GC) that we earned per kg was far below what we wanted to be at.\u003C/p>\n\u003C/li>\n\u003C/ul>\n\u003Ch2 id=\"role\">Role\u003C/h2>\n\u003Cp>My role was a fluid one in the project where at the start I was leading the product design effort and managing stakeholders but eventually transitioned to co-owning the project and focusing on the digital marketing efforts over the 1 year of operation.\u003C/p>\n\u003Ch2 id=\"solution\">Solution\u003C/h2>\n\u003Cfigure class=\"image-figure\">\u003Cimg __ASTRO_IMAGE_=\"{"src":"./lite-wire.png","alt":"Early Jiva Lite app wireframes","title":"Early Jiva Lite app wireframes","index":0}\">\u003Cfigcaption>Early Jiva Lite app wireframes\u003C/figcaption>\u003C/figure>\n\u003Cp>The first idea for Jiva Lite came out of our efforts to simplify the Sahabat Jiva App information architecture and workflows. But it took a few more months before we got a chance to try to solve this.\nThe overwhelming idea at that time was to make another app albeit a “lite” one. But a few of us felt that Whatsapp was the way to go. So I used Landbot to quickly prototype how a Whatsapp based flow would look like.\u003C/p>\n\u003Ch4 id=\"why-whatsapp\">Why Whatsapp?\u003C/h4>\n\u003Cp>Meta has deep penetration in Indonesia. Indonesia doesnt have net neutrality laws and hence Meta, Google, Netflix, etc have mobile plans that enabled unlimited usage of their services.\nThis is one of the reason that Facebook and Whatsapp are the communication tool of choice in our users. This meant that\nwe could be assured that unlike a mobile app, our target audience would definitely have Whatsapp on their phones.\u003C/p>\n\u003Cp>After pitching this to leadership, we got buyin to use the Whatsapp flow as a pilot project to test out the viability of the Jiva Lite business model.\u003C/p>\n\u003Ch4 id=\"why-was-jiva-lite-different\">Why was Jiva Lite different?\u003C/h4>\n\u003Cul>\n\u003Cli>If Jiva Lite had to succeed then it should be economically viable while at the same time, it should not cannibalize our existing businesses. So the pricing logic we set was to keep our offering price at 100idr/kg less than the price we showed in our Sahabat Jiva app.\u003C/li>\n\u003Cli>A recent tax exemption made it easy for us to operate at the small scale without needing unnecessary documentation like KTPs\u003C/li>\n\u003Cli>For the first time (probably), small holders could sell direct to our buyers irrespective of the volume of their harvest and get paid within a few hours.\u003C/li>\n\u003Cli>Meta Ads and Whatsapp QRs let users quickly get into our flow and check prices.\u003C/li>\n\u003C/ul>\n\u003Ch3 id=\"building-the-mvp\">Building the MVP\u003C/h3>\n\u003Cp>A small team got together to work on this part time. Designing the first flow to be as simple took a few iterations. We used Figma and FigJam a lot to align everyone and used Slack’s inbuilt project management system to keep us on track.\nWeekly syncs were run to share progress with the larger group of stakeholders and monthly meetings with the CEO.\u003C/p>\n\u003Cfigure class=\"image-figure\">\u003Cimg __ASTRO_IMAGE_=\"{"src":"./figjam.png","alt":"Figjam","title":"Blueprinting","index":0}\">\u003Cfigcaption>Figjam\u003C/figcaption>\u003C/figure>\n\u003Cp>Our first version was built using Whatsapp Flows and simplified the crop buying flow to just 3 steps; View Prices, Register and Send Truck.\nWe offered farmers the option of selecting between 3 feedmills based on their corn quality. Prices would be updated everyday.\u003C/p>\n\u003Cfigure class=\"image-figure\">\u003Cimg __ASTRO_IMAGE_=\"{"src":"./jivalitev1.png","alt":"Designs for the first release version on Figma","title":"Designs for the first release version on Figma","index":0}\">\u003Cfigcaption>Designs for the first release version on Figma\u003C/figcaption>\u003C/figure>\n\u003Ch3 id=\"preparing-for-go-to-market\">Preparing for Go-To-Market\u003C/h3>\n\u003Ch4 id=\"onboarding-internal-teams\">Onboarding internal teams:\u003C/h4>\n\u003Cp>We ran sessions with our field agents, customer service agents and marketing teams to onboard them onto the pilot project. I prepared an “objection handling” (a FAQ document) for CX team to use for answering any queries they may receive on their channels.\nSpeaking to our on-ground field agents helped us address their concerns about Jiva Lite and its impact on their operations.\u003C/p>\n\u003Ch4 id=\"selecting-a-region-for-piloting\">Selecting a region for piloting:\u003C/h4>\n\u003Cp>We had to negotiate with stakeholders for selecting regions due to concerns around our existing micro-collector density as well as time of the year and , we decided to go with the regencies closest to Makassar (South Sulawesi) ; Maros and Takalar.\nThis meant that the distances to be travelled by the farmers to our buyers were just a few hours away.\u003C/p>\n\u003Ch4 id=\"on-field-marketing\">On field marketing:\u003C/h4>\n\u003Cp>We got 1 field marketer, Erwin, on loan from the growth team for the efforts on on-ground canvassing by meeting farmer groups (Gapoktans).\u003C/p>\n\u003Ch4 id=\"jiva-lite-website\">Jiva Lite Website:\u003C/h4>\n\u003Cp>We built a website so that we could provide a social proof that Jiva Lite was infact an offering from Jiva and not a scam. The website had prices which we manually updated and directed users to the Whatsapp number.\u003C/p>\n\u003Ciframe width=\"560\" height=\"315\" src=\"https://www.youtube.com/embed/kCQByHg5kBI?si=MZe2Z8pwF-LeETQI\" title=\"YouTube video player\" frameborder=\"0\" allow=\"accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" allowfullscreen>\u003C/iframe>\n\u003Ch4 id=\"doing-things-that-dont-scale\">Doing things that don’t scale:\u003C/h4>\n\u003Cp>We didn’t build an in-flow way to add a farmer’s bank account details. We resorted instead to use a manual system of getting the information from the farmer and getting CX team to add them to the system. This enabled us to ship faster and prevented user error from entering the wrong information. Where possible we pre-filled dummy data (e.g., user address) in the backend because we didnt want to build without valdiating our idea at this stage.\u003C/p>\n\u003Ch2 id=\"post-launch-of-the-mvp\">Post Launch of the MVP\u003C/h2>\n\u003Cfigure class=\"image-figure\">\u003Cimg __ASTRO_IMAGE_=\"{"src":"./jivalite-ground.png","alt":"Karan, Nav, Idul and Erwin meeting Saripuddin and other farmers","index":0}\">\u003Cfigcaption>Karan, Nav, Idul and Erwin meeting Saripuddin and other farmers\u003C/figcaption>\u003C/figure>\n\u003Cp>We launched the first version to production on August 7th, but we didnt get our first transaction till Nav, Karan, Idul and Erwin visited Mr. Saripuddin and convinced him to send the corn to our collection centre.\nOn August 23rd, Saripuddin (seen in the cover image) became the first farmer to have sent us the corn directly. That first transaction was the litmus test that our systems failed, however with Karan co-ordinating with Erwin, we somehow managed to pull through.\u003C/p>\n\u003Cblockquote>\n\u003Cp>“I made over IDR 3,000,000 with my truck! I invite all my friends to send trucks using Jiva Lite.”\n— Saripuddin\u003C/p>\n\u003C/blockquote>\n\u003Cp>Saripuddin immediately saw the value Jiva Lite brought to him and instantly became our ambassador convincing multiple farmers in his village to send us corn over the year.\nWithin a month, we hit the milestone of 50 MT and started thinking of the next iteration for Jiva Lite.\u003C/p>\n\u003Cp>Personally, the first transaction was a feeling unlike any other that my body had experienced. That day, I was unable to act rationally because I was completely blown away by the fact that 14 days after release we secured our first farmer and he saw the value we were providing.\nThere was a lot of time and effort that went into reaching this exact point and it felt glorious.\u003C/p>\n\u003Ch2 id=\"learnings-from-the-pilot\">Learnings from the Pilot\u003C/h2>\n\u003Ch4 id=\"selling-breakdown\">Selling breakdown:\u003C/h4>\n\u003Cp>We made a simple google sheets template to generate a breakdown that we sent to every farmer which helped them understand how much they were earning and what was the quality of their corn.\u003C/p>\n\u003Ch4 id=\"backend-issues\">Backend Issues:\u003C/h4>\n\u003Cp>We had not handled user creation of churned/deleted users and this is what caused our first transaction to fail. (Murphy’s Law, amirite?)\u003C/p>\n\u003Cfigure class=\"image-figure\">\u003Cimg __ASTRO_IMAGE_=\"{"src":"./spiderkaran.png","alt":"spiderkaran","index":0}\">\u003Cfigcaption>spiderkaran\u003C/figcaption>\u003C/figure>\n\u003Ch4 id=\"changing-behaviour-isnt-easy\">Changing behaviour isn’t easy:\u003C/h4>\n\u003Cp>When farmers are used to dealing with a broken system, ‘a too-good to be true’ deal like Jiva Lite feels unrealistic. Furthermore, farmers and local buyers tend to have a personal relationship that isnt easy to overcome. At the end of the day, Jiva is an external entity while the buyer may be a neighbour, a relative or their money lender.\u003C/p>\n\u003Ch4 id=\"flow-still-complex\">Flow still complex:\u003C/h4>\n\u003Cp>Without our on-field agents, getting users to navigate Whatsapp Flows wasnt easy. Whatsapp flows may seem simple to us, but for our target users, they were complex. We realized that just because they used Facebook and Whatsapp didn’t mean that they were familiar navigating similar interfaces. We needed to re-do our flow.\u003C/p>\n\u003Ch2 id=\"building-v2\">Building V2\u003C/h2>\n\u003Cp>From a product point of view, we realised the following shortcomings:\u003C/p>\n\u003Cul>\n\u003Cli>The current implementation didn’t enable us to A/B test our flow fast enough.\u003C/li>\n\u003Cli>There was no way for us to intervene in the flow to guide users through it if required\u003C/li>\n\u003Cli>There was no way to re-target and engage our users\u003C/li>\n\u003C/ul>\n\u003Cp>We decided to look if any pre-existing solutions would help us solve this. After an evaluation of several Whatsapp business providers, we decided to go ahead with Landbot. We were already familiar with Landbot and it met all the above criteria.\u003C/p>\n\u003Cfigure class=\"image-figure\">\u003Cimg __ASTRO_IMAGE_=\"{"src":"./landbot.png","alt":"A small portion of the Landbot flow","index":0}\">\u003Cfigcaption>A small portion of the Landbot flow\u003C/figcaption>\u003C/figure>\n\u003Cp>\u003Cstrong>Product:\u003C/strong> We re-designed the whole flow to be more like a chat-bot conversation as Landbot didnt support Whatsapp flows. This unfortunately took longer than we planned for and we finally released in early January 2025.\u003C/p>\n\u003Cp>\u003Cstrong>Marketing:\u003C/strong> While we built, we went ahead and started Meta Ads and sending Price Update notifications to users in our funnel. We felt the ads themselves may not be efficient at communicating the concept of Jiva Lite so Tyo and Nav created a few marketing videos to help us.\u003C/p>\n\u003Ch2 id=\"post-v2\">Post V2\u003C/h2>\n\u003Cul>\n\u003Cli>\n\u003Cp>Once Landbot released interacting with our users in the funnel became easy. Our Research Coordinators stepped in to own the role of helping guide our users through the funnel. They did a wonderful job (outside of their job description) and even converted a few sales purely via chat.\u003C/p>\n\u003C/li>\n\u003Cli>\n\u003Cp>Our successful pilot had enabled us to get a small budget approved which allowed us to hire a few more Jive Lite Operators (or JLO’s as we called them) to do outreach on ground. We also explored using Sentinel satellite data to help our JLOs narrow their canvassing regions to those being harvested.\u003C/p>\n\u003C/li>\n\u003C/ul>\n\u003Cfigure class=\"image-figure\">\u003Cimg __ASTRO_IMAGE_=\"{"src":"./gorontalo.jpeg","alt":"Shakti, Abhishek and I travelled to Gorontalo to figure out if we could launch Jiva Lite there","index":0}\">\u003Cfigcaption>Shakti, Abhishek and I travelled to Gorontalo to figure out if we could launch Jiva Lite there\u003C/figcaption>\u003C/figure>\n\u003Cul>\n\u003Cli>\n\u003Cp>We wanted to scale our solution to other regions so we started expanding to Lampung, Sumatra and Central Java and explored building out Jiva Lite for other crops like Rubber.\u003C/p>\n\u003C/li>\n\u003Cli>\n\u003Cp>We ran A/B tests and simplified our flow futher. Designed different types of ads; static, videos, localized (Bugis and Bahasa Indonesia) and even engaged social media influencers.\u003C/p>\n\u003C/li>\n\u003C/ul>\n\u003Ch2 id=\"final-thoughts\">Final thoughts\u003C/h2>\n\u003Cul>\n\u003Cli>\n\u003Cp>Our digital conversion (Ads - Whatsapp)was near 0 throughout the time of operation. We tried a lot of different approaches but weren’t able to get any organic sale from the digital channel.\u003C/p>\n\u003C/li>\n\u003Cli>\n\u003Cp>Almost 98% of our sales came via our JLOs. This meant scaling volume would directly need more feet on ground and that was seen as expensive.\u003C/p>\n\u003C/li>\n\u003C/ul>\n\u003Cfigure class=\"image-figure\">\u003Cimg __ASTRO_IMAGE_=\"{"src":"./dross.png","alt":"Some ads we made for recruiting drossers","index":0}\">\u003Cfigcaption>Some ads we made for recruiting drossers\u003C/figcaption>\u003C/figure>\n\u003Cul>\n\u003Cli>\n\u003Cp>We uncovered certain systemic issues like Farmer debt, Cash payments (to avoid tax), Drossing systems. We attempted to solve Drossing (separating Corn kernels from Cob) by procuring and\nrenting out drossing machines and even built a simple advertising based funnel to acquire potential customers for this service. But we couldn’t solve for the others with our budgetary constraints and the high level of risk associated with them.\u003C/p>\n\u003C/li>\n\u003Cli>\n\u003Cp>Though I have attempted to write out the project in detail, there is still a lot that I feel I have left out because building a product and running it takes you in so many different directions. You encounter various problems and inefficiencies, some you solve and others you can’t.\nThe experience takes a lot out of you but in the end, I am glad I got the opportunity to build a product with this level of ownership.\u003C/p>\n\u003C/li>\n\u003C/ul>\n\u003Ch2 id=\"impact\">Impact\u003C/h2>\n\u003Cp>In the one year of operation, we scaled Jiva Lite from 0 to 600 registered users who sold 4102 MT of corn. With a margin of 100 IDR/kg, we generated around 24k USD of gross contribution (Additional earnings from sales from trading this corn added an additional 200 IDR/kg, which has not been counted here)\u003C/p>\n\u003Cdiv class=\"impact-images\" style=\"display: grid; grid-template-columns: 1fr 3fr; gap: 1rem;\">\n\u003Cfigure class=\"image-figure\">\u003Cimg __ASTRO_IMAGE_=\"{"src":"./jl-impact-1.png","alt":"","index":0}\">\u003C/figure>\n\u003Cfigure class=\"image-figure\">\u003Cimg __ASTRO_IMAGE_=\"{"src":"./jl-impact-2.png","alt":"","index":0}\">\u003C/figure>\n\u003C/div>\n\u003Cp>Behaviourally though, we were able to bring meaningful improvements into the lives of the Farmers in a few provinces of South Sulawesi. Most farmers who transacted with us made about 2.5-3 million IDR(~$180 USD) more than they would otherwise.\nEven after Jiva Lite shut down, a few of the farmers continued to deal directly with the collection centres and improve their collective earnings.\u003C/p>\n\u003Ch2 id=\"team\">Team\u003C/h2>\n\u003Cp>It takes a village to run a project like this and almost everyone in the Jiva design team contributed towards this project. I couldnt have done this without Karan owning the offline side, Nilesh running the product sprint and Shakti managing the JLO’s.\u003C/p>\n\u003Cp>Nav, Sai and Tyo worked on the initial flow designs and Niraj took the reigns towards the end, Kesha on the UX copy, and Karan and Bharath on the Service Design.\nAsa, Idul, Aldi and El contributed heavily on the User research side often intervening in our workflow to helpg guide our Farmers.\nAkshay Koul led the Engineering team with Kalpesh and Mani, Rajlakshmi on QA. DJ for Data Dashboards. Gada and Salma on Marketing. Aiko & Idayanti helped us from the CX team.\u003C/p>\n\u003Cp>And we really couldnt have done as much as we did without our Jiva Lite Operators Erwin, Firman, Rahma, Nur Faisyah, Ainun, Irsyam, Rajab & Fery.\u003C/p>",{"headings":346,"localImagePaths":408,"remoteImagePaths":409,"frontmatter":410,"imagePaths":411},[347,348,349,352,355,358,361,364,367,370,373,376,379,382,385,388,391,394,397,400,403,406,407],{"depth":37,"slug":41,"text":42},{"depth":37,"slug":38,"text":39},{"depth":37,"slug":350,"text":351},"solution","Solution",{"depth":57,"slug":353,"text":354},"why-whatsapp","Why Whatsapp?",{"depth":57,"slug":356,"text":357},"why-was-jiva-lite-different","Why was Jiva Lite different?",{"depth":44,"slug":359,"text":360},"building-the-mvp","Building the MVP",{"depth":44,"slug":362,"text":363},"preparing-for-go-to-market","Preparing for Go-To-Market",{"depth":57,"slug":365,"text":366},"onboarding-internal-teams","Onboarding internal teams:",{"depth":57,"slug":368,"text":369},"selecting-a-region-for-piloting","Selecting a region for piloting:",{"depth":57,"slug":371,"text":372},"on-field-marketing","On field marketing:",{"depth":57,"slug":374,"text":375},"jiva-lite-website","Jiva Lite Website:",{"depth":57,"slug":377,"text":378},"doing-things-that-dont-scale","Doing things that don’t scale:",{"depth":37,"slug":380,"text":381},"post-launch-of-the-mvp","Post Launch of the MVP",{"depth":37,"slug":383,"text":384},"learnings-from-the-pilot","Learnings from the Pilot",{"depth":57,"slug":386,"text":387},"selling-breakdown","Selling breakdown:",{"depth":57,"slug":389,"text":390},"backend-issues","Backend Issues:",{"depth":57,"slug":392,"text":393},"changing-behaviour-isnt-easy","Changing behaviour isn’t easy:",{"depth":57,"slug":395,"text":396},"flow-still-complex","Flow still complex:",{"depth":37,"slug":398,"text":399},"building-v2","Building V2",{"depth":37,"slug":401,"text":402},"post-v2","Post V2",{"depth":37,"slug":404,"text":405},"final-thoughts","Final thoughts",{"depth":37,"slug":79,"text":80},{"depth":37,"slug":82,"text":83},[331,332,333,334,335,336,337,338,339,340],[],{"title":324,"description":325,"year":327,"company":18,"image":341},[331,332,333,334,335,336,337,338,339,340],"practo-pro",{"id":412,"data":414,"body":419,"filePath":420,"assetImports":421,"digest":423,"rendered":424},{"title":415,"description":416,"image":417,"year":418,"company":98,"status":99},"Practo Pro v1","Designing a unified mobile experience for providers using Practo products","__ASTRO_IMAGE_./practo-pro.png","2015-2016","## Overview\nAround Dec 2015, Practo had 3 mobile apps (Profile, Ray and Qikwell Pulse), each of which served a\nparticular purpose and worked independent of each other. Ray had been the mainstay app for most of\nPracto’s existence, while Profile was created to onboard doctors easily to the marketplace. The Qikwell\napp entered into this mix when we acquired their company earlier in 2015. Maintaining 3 separate\nmobile applications was an overhead for our internal teams as well as for our users. Thus **Project\nSingularity** was born.\n\n## Understanding the problem\nI was not involved in the user research phase of this project. I started work on this project at the\nconceptualisation stage. I worked with Jonathan during this phase. The three apps had different visual\nstyles and interactions and were structured as per their workflows. We needed to integrate these\ntogether without alienating their existing user base while also providing a scalable structure for the\nfuture.\n\n>Our vision was to build one app which needs to become the defacto app for doctors and eventually\nother provider segments\n\nBased on the research conducted, it was understood that a healthcare professional had the following\nneeds; Reputation, Productivity, Marketing, Money and Networking.\n\n[Personas for the unified app]\n\nThe new application had to cater to these needs if it had to be a central point of their life. However,\nthese needs vary as per the standing of the doctor. For e.g., a just graduated doctor would seek to\nlearn more from experienced doctors and would rarely have their own clinic while a doctor with 10\nyears of experience would be focussing on setting up her own business and getting more patients.\nFirst we needed to figure out the information architecture. We started putting all the existing parts\nof the various apps into an excel sheet to get an idea of what the pieces were and we also listed out\nfeatures that we felt could be integrated into the app at a later stage.\n\n[arriving at the information architecture]\n\nWe then started organising this based on how the users would be interacting with them. This is when\nwe started realising that some features seemed redundant while others were incomplete. We then\nlooked at how these various features would be impacted with respect to our user roles.\nWe looked at what are the requirements for a user to access our products as well as how the app\nwould be for users of any of the apps. Thus we were able to finalise the information architecture of the app.\n\n[final information architecture]\n\n## Concepts\nBased on this information architecture, I created few app concepts which we evaluated before\nfinalising on the one we would present to the stakeholders. The final concept was presented as an\nInVision prototype.\n\n[final information architecture]\n\nNotifications, Summary and Settings were concepts that we proposed as part of the new app.\n\n**Notifications:**\nAt that point of time, we did not have a single in-product channel of communication. Most\ncommunication happened either by emails, message bars or blocking dialogs. We wanted to change\nthis so we proposed a Notification Drawer. Further, we categorised as notifications as promotional and\ntransactional and provided users with a way to customise what kind of notifications they would like to\nreceive.\n\n**Summary:**\nThe Summary section was conceived as the newsfeed that would be the landing page for returning\nusers to jump directly into their workflow. It was comprised of stationary widgets and a refreshing\ninfinite newsfeed. The widgets were devised only for transactional products like Ray and Consult. The\nrest of the feed was to be powered by content from our other products like Healthfeed, Synapse and\nConsult.\n\n**Settings:**\nJust like notifications, this did not exist but was an obvious thing to build. We didn't want the user to\nexperience the internal product separations that existed.\nThere were many many meetings and back and forth before we could get everyone to agree that this\nwas the way we should go ahead. During the final discussion with the stakeholders, It was decided\nthat the workflow based structure was too futuristic and we would need to have an interface that lets\nour users understand our offerings. So we shifted to an app grid and widget landing as shown below\ninstead of a feed based landing.\n[final app navigation]\n\n## Detailing\nI led this effort with a team of 3 other designers. Hetang, Akshay and me worked to create the various\nproduct screens while Saloni was responsible for the theme and illustrations. Jonathan was overseeing\nthe entire operation and he gradually transitioned the responsibility to me.\nWe chose a clean content first approach that was becoming popular at that time. It was decided to\nmake the android and iOS apps similar in experience and independent of platforms. I set down the core\nguidelines that we would need to follow to align the various parts of the products. We decided to use\nthe system fonts i.e., Roboto on Android and SF on iOS, when available, for the design. To finalise on\nthe elements, we mocked up key screens within the product to understand and added to our\nguidelines when we found a component that was being used in multiple places.\n[singularity stickersheet]\n\nI created a stickersheet which functioned as a Master file for all the designers. We used a primitive\npeer review process so that the various parts would be consistent and present a coherent experience.\nOur core files would reside within Google Drive and we would work on our versions separately before I\nwould go through everyone’s files before replacing the versions in our core Drive folder.\n\n## Final screens\n\nDuring the implementation, I was the only designer assigned to the project and worked closely with the\ndevelopers to get things right which was how I earned the moniker ‘ceo’ from them. The android app\nshipped on June 25th, 2016 to 100% while the iOS app took another month before it was ready for\nrelease.\n\n\nThanks to Jonathan, Hetang, Akshay, Saloni and the rest of the Practo Partner team for coming\ntogether to bring this once-in-a-lifetime project to life.","src/content/work/practo-pro/index.md",[422],"./practo-pro.png","9357b996caae3882",{"html":425,"metadata":426},"\u003Ch2 id=\"overview\">Overview\u003C/h2>\n\u003Cp>Around Dec 2015, Practo had 3 mobile apps (Profile, Ray and Qikwell Pulse), each of which served a\nparticular purpose and worked independent of each other. Ray had been the mainstay app for most of\nPracto’s existence, while Profile was created to onboard doctors easily to the marketplace. The Qikwell\napp entered into this mix when we acquired their company earlier in 2015. Maintaining 3 separate\nmobile applications was an overhead for our internal teams as well as for our users. Thus \u003Cstrong>Project\nSingularity\u003C/strong> was born.\u003C/p>\n\u003Ch2 id=\"understanding-the-problem\">Understanding the problem\u003C/h2>\n\u003Cp>I was not involved in the user research phase of this project. I started work on this project at the\nconceptualisation stage. I worked with Jonathan during this phase. The three apps had different visual\nstyles and interactions and were structured as per their workflows. We needed to integrate these\ntogether without alienating their existing user base while also providing a scalable structure for the\nfuture.\u003C/p>\n\u003Cblockquote>\n\u003Cp>Our vision was to build one app which needs to become the defacto app for doctors and eventually\nother provider segments\u003C/p>\n\u003C/blockquote>\n\u003Cp>Based on the research conducted, it was understood that a healthcare professional had the following\nneeds; Reputation, Productivity, Marketing, Money and Networking.\u003C/p>\n\u003Cp>[Personas for the unified app]\u003C/p>\n\u003Cp>The new application had to cater to these needs if it had to be a central point of their life. However,\nthese needs vary as per the standing of the doctor. For e.g., a just graduated doctor would seek to\nlearn more from experienced doctors and would rarely have their own clinic while a doctor with 10\nyears of experience would be focussing on setting up her own business and getting more patients.\nFirst we needed to figure out the information architecture. We started putting all the existing parts\nof the various apps into an excel sheet to get an idea of what the pieces were and we also listed out\nfeatures that we felt could be integrated into the app at a later stage.\u003C/p>\n\u003Cp>[arriving at the information architecture]\u003C/p>\n\u003Cp>We then started organising this based on how the users would be interacting with them. This is when\nwe started realising that some features seemed redundant while others were incomplete. We then\nlooked at how these various features would be impacted with respect to our user roles.\nWe looked at what are the requirements for a user to access our products as well as how the app\nwould be for users of any of the apps. Thus we were able to finalise the information architecture of the app.\u003C/p>\n\u003Cp>[final information architecture]\u003C/p>\n\u003Ch2 id=\"concepts\">Concepts\u003C/h2>\n\u003Cp>Based on this information architecture, I created few app concepts which we evaluated before\nfinalising on the one we would present to the stakeholders. The final concept was presented as an\nInVision prototype.\u003C/p>\n\u003Cp>[final information architecture]\u003C/p>\n\u003Cp>Notifications, Summary and Settings were concepts that we proposed as part of the new app.\u003C/p>\n\u003Cp>\u003Cstrong>Notifications:\u003C/strong>\nAt that point of time, we did not have a single in-product channel of communication. Most\ncommunication happened either by emails, message bars or blocking dialogs. We wanted to change\nthis so we proposed a Notification Drawer. Further, we categorised as notifications as promotional and\ntransactional and provided users with a way to customise what kind of notifications they would like to\nreceive.\u003C/p>\n\u003Cp>\u003Cstrong>Summary:\u003C/strong>\nThe Summary section was conceived as the newsfeed that would be the landing page for returning\nusers to jump directly into their workflow. It was comprised of stationary widgets and a refreshing\ninfinite newsfeed. The widgets were devised only for transactional products like Ray and Consult. The\nrest of the feed was to be powered by content from our other products like Healthfeed, Synapse and\nConsult.\u003C/p>\n\u003Cp>\u003Cstrong>Settings:\u003C/strong>\nJust like notifications, this did not exist but was an obvious thing to build. We didn’t want the user to\nexperience the internal product separations that existed.\nThere were many many meetings and back and forth before we could get everyone to agree that this\nwas the way we should go ahead. During the final discussion with the stakeholders, It was decided\nthat the workflow based structure was too futuristic and we would need to have an interface that lets\nour users understand our offerings. So we shifted to an app grid and widget landing as shown below\ninstead of a feed based landing.\n[final app navigation]\u003C/p>\n\u003Ch2 id=\"detailing\">Detailing\u003C/h2>\n\u003Cp>I led this effort with a team of 3 other designers. Hetang, Akshay and me worked to create the various\nproduct screens while Saloni was responsible for the theme and illustrations. Jonathan was overseeing\nthe entire operation and he gradually transitioned the responsibility to me.\nWe chose a clean content first approach that was becoming popular at that time. It was decided to\nmake the android and iOS apps similar in experience and independent of platforms. I set down the core\nguidelines that we would need to follow to align the various parts of the products. We decided to use\nthe system fonts i.e., Roboto on Android and SF on iOS, when available, for the design. To finalise on\nthe elements, we mocked up key screens within the product to understand and added to our\nguidelines when we found a component that was being used in multiple places.\n[singularity stickersheet]\u003C/p>\n\u003Cp>I created a stickersheet which functioned as a Master file for all the designers. We used a primitive\npeer review process so that the various parts would be consistent and present a coherent experience.\nOur core files would reside within Google Drive and we would work on our versions separately before I\nwould go through everyone’s files before replacing the versions in our core Drive folder.\u003C/p>\n\u003Ch2 id=\"final-screens\">Final screens\u003C/h2>\n\u003Cp>During the implementation, I was the only designer assigned to the project and worked closely with the\ndevelopers to get things right which was how I earned the moniker ‘ceo’ from them. The android app\nshipped on June 25th, 2016 to 100% while the iOS app took another month before it was ready for\nrelease.\u003C/p>\n\u003Cp>Thanks to Jonathan, Hetang, Akshay, Saloni and the rest of the Practo Partner team for coming\ntogether to bring this once-in-a-lifetime project to life.\u003C/p>",{"headings":427,"localImagePaths":437,"remoteImagePaths":438,"frontmatter":439,"imagePaths":440},[428,429,430,433,436],{"depth":37,"slug":110,"text":111},{"depth":37,"slug":113,"text":114},{"depth":37,"slug":431,"text":432},"concepts","Concepts",{"depth":37,"slug":434,"text":435},"detailing","Detailing",{"depth":37,"slug":119,"text":120},[],[],{"title":415,"description":416,"year":418,"company":98,"image":422,"status":99},[],"sahabat-jiva-redesign",{"id":441,"data":443,"body":448,"filePath":449,"assetImports":450,"digest":452,"rendered":453},{"title":444,"description":445,"image":446,"year":447,"company":18,"status":99},"Fixing the Information Architecture of the Sahabat Jiva app","Redesigning the Sahabat Jiva Android app to fit the user's mental model and making it an intuitive experience","__ASTRO_IMAGE_./sjhome.webp","2022-2023","\u003C!-- Add your project content here -->\n\nWhen I joined Jiva in 2022, we had been leveraging collectors in rural areas to facilitate our business model.\n\nThe harvest of a smallholder corn farmer is typically around 2.5k-3k tons. The economics of sending it to the buyer isn't economically viable for such a small quantity when you factor in labour cost & transport cost. Additionally the ability to evaluate quality at the farmer level is approximate. \n\nCollectors helped fill this gap by aggregating corn for dispatch from multiple farmers and using moisture meters to estimate quality of the corn. \n\nJiva's business model was working with buyers to acquire purchase orders for the corn and coordinate with the collectors to dispatch to feedmills to get the best price.\n\nThis wasn't a disruptionary model. The concept of middlemen have always existed in agricultural systems. Jiva and it's Collectors operated at a country level scale that hadn't been tried before. \nThe Sahabat Jiva android app was used by our Collectors to manage their Harvest Procurement, their Input sales (In the Agriculture business; Seeds, Chemicals, Fertilizers, Equipments are collectively termed as Inputs) and view their Earnings.\n\n## Challenge\nJiva had started off in the pandemic and we hadnt got a chance to observe our users on the ground. Moving to mobile apps had led to most of our transactions now flowing through a digital channel. However our qualitative research, quickly showed us that our users really struggled with our app. \n\nThese could be narrowed down to\n1. The app's localization was a mess since there had not been a dedicated UX Writer who was involved in the app in the past which led to wrong translations, english terms in various pages and alien terminology being used.\n2. Every new user had to sit through multiple training sessions to learn how to use the various features on the app and there was no guarantee that they remembered how to use it.\n3. There were many disconnected user flows which needed to be followed in a particular sequence.\n4. The Collector's privileges on the application were managed by the province's branch manager and finance team due to the financial risk. This led to a non-uniform user experience and rogue user behaviour. \n\nBusiness-wise, this was leading to: \n\n1. High investment into canvassing, recruiting, training and onboarding \n2. Churn increasing Season-on-Season \n\nWhat this really meant was that the Android app was not the primary channel used by the Collector but more of a digitization system while most of the actual activity happened on Whatsapp. \n\nThere were even cases where our field agents (Activation Co-ordinators, Finance Co-ordinators) may actually be the operators of the application as it had been mandated to digitize every transaction that flows through the system.\n\nSo our data had been lying all this while about product adoption and usage.\n\n## Solution\n\nCan you really solve a problem this systemic and prevalent at so many different levels? \n\nFor sure! but could we do it at one go? No way. \n\nI advocated to break these problems into multiple phases and prioritized the Information Architecture overhaul as the first step.\n\n\n## Impact","src/content/work/sahabat-jiva-redesign/index.md",[451],"./sjhome.webp","4bbe7b5304d9dfb5",{"html":454,"metadata":455},"\u003C!-- Add your project content here -->\n\u003Cp>When I joined Jiva in 2022, we had been leveraging collectors in rural areas to facilitate our business model.\u003C/p>\n\u003Cp>The harvest of a smallholder corn farmer is typically around 2.5k-3k tons. The economics of sending it to the buyer isn’t economically viable for such a small quantity when you factor in labour cost & transport cost. Additionally the ability to evaluate quality at the farmer level is approximate.\u003C/p>\n\u003Cp>Collectors helped fill this gap by aggregating corn for dispatch from multiple farmers and using moisture meters to estimate quality of the corn.\u003C/p>\n\u003Cp>Jiva’s business model was working with buyers to acquire purchase orders for the corn and coordinate with the collectors to dispatch to feedmills to get the best price.\u003C/p>\n\u003Cp>This wasn’t a disruptionary model. The concept of middlemen have always existed in agricultural systems. Jiva and it’s Collectors operated at a country level scale that hadn’t been tried before.\nThe Sahabat Jiva android app was used by our Collectors to manage their Harvest Procurement, their Input sales (In the Agriculture business; Seeds, Chemicals, Fertilizers, Equipments are collectively termed as Inputs) and view their Earnings.\u003C/p>\n\u003Ch2 id=\"challenge\">Challenge\u003C/h2>\n\u003Cp>Jiva had started off in the pandemic and we hadnt got a chance to observe our users on the ground. Moving to mobile apps had led to most of our transactions now flowing through a digital channel. However our qualitative research, quickly showed us that our users really struggled with our app.\u003C/p>\n\u003Cp>These could be narrowed down to\u003C/p>\n\u003Col>\n\u003Cli>The app’s localization was a mess since there had not been a dedicated UX Writer who was involved in the app in the past which led to wrong translations, english terms in various pages and alien terminology being used.\u003C/li>\n\u003Cli>Every new user had to sit through multiple training sessions to learn how to use the various features on the app and there was no guarantee that they remembered how to use it.\u003C/li>\n\u003Cli>There were many disconnected user flows which needed to be followed in a particular sequence.\u003C/li>\n\u003Cli>The Collector’s privileges on the application were managed by the province’s branch manager and finance team due to the financial risk. This led to a non-uniform user experience and rogue user behaviour.\u003C/li>\n\u003C/ol>\n\u003Cp>Business-wise, this was leading to:\u003C/p>\n\u003Col>\n\u003Cli>High investment into canvassing, recruiting, training and onboarding\u003C/li>\n\u003Cli>Churn increasing Season-on-Season\u003C/li>\n\u003C/ol>\n\u003Cp>What this really meant was that the Android app was not the primary channel used by the Collector but more of a digitization system while most of the actual activity happened on Whatsapp.\u003C/p>\n\u003Cp>There were even cases where our field agents (Activation Co-ordinators, Finance Co-ordinators) may actually be the operators of the application as it had been mandated to digitize every transaction that flows through the system.\u003C/p>\n\u003Cp>So our data had been lying all this while about product adoption and usage.\u003C/p>\n\u003Ch2 id=\"solution\">Solution\u003C/h2>\n\u003Cp>Can you really solve a problem this systemic and prevalent at so many different levels?\u003C/p>\n\u003Cp>For sure! but could we do it at one go? No way.\u003C/p>\n\u003Cp>I advocated to break these problems into multiple phases and prioritized the Information Architecture overhaul as the first step.\u003C/p>\n\u003Ch2 id=\"impact\">Impact\u003C/h2>",{"headings":456,"localImagePaths":460,"remoteImagePaths":461,"frontmatter":462,"imagePaths":463},[457,458,459],{"depth":37,"slug":41,"text":42},{"depth":37,"slug":350,"text":351},{"depth":37,"slug":79,"text":80},[],[],{"title":444,"description":445,"year":447,"company":18,"image":451,"status":99},[],"writing",["Map",466,467,487,488,512,513,533,534,564,565,602,603,626,627,655,656,694,695,723,724,753,754,774,775],"design-in-tech-2024",{"id":466,"data":468,"body":473,"filePath":474,"assetImports":475,"digest":477,"rendered":478},{"title":469,"description":470,"date":471,"image":472,"status":19},"An Insider's perspective on Design in Tech 2024","Reflections on the state of design leadership and the industry in India and Indonesia",["Date","2024-01-01T00:00:00.000Z"],"__ASTRO_IMAGE_./4IiQQOEdmqPcCsjTqlta-1.png","After the Great Layoffs, I've been seeing too many people declaring the [death](https://www.fastcompany.com/91027996/the-big-design-freak-out-a-generation-of-design-leaders-grapple-with-their-future) of [design](https://medium.com/@martynreding/how-to-survive-the-design-leadership-reckoning-ff2856bf4733) leadership and with the rise of AI, the death of the digital design industry as well. but I find that it's a poorly informed take and no offence, but in my opinion, written by outsiders or written about a specific industry/region/designer. In fact, there are a lot of highly [priced](https://maven.com/rachel-kobetz/dls-career-architecture) [leadership](https://www.designdept.co/series/design-leadership-fundamentals) [training](https://www.aiga.org/design/design-leadership) courses out there these days.\n\nOver my career of 10 odd years, I’ve had the honour of being an observer in the product design industry of 2 countries; India and Indonesia. My perspective comes from my vantage point of living in the Silicon Valley of India and professionally, from being part of the growth stage of the well funded startups.\n\nFor this article(rant?), I will use Startups vs Big Tech for sake of categorisation. Big tech would have the minimum expectation of being a listed company operating across more than 1 geographical region. Meta and the other MAANG companies would fall into big tech but do remember that they are the new entrants in a space already filled by CISCO, Intuit, Adobe.\n\nPost the dot-com bust, we saw the slow rise of today’s modern digital startups. First in the Silicon Valley and then in the rest of the world. This was mainly fuelled by the VC funding and still is. This lead us to look up to the Silicon Valley companies and the folks there as thought leaders for design. And rightly so since they were working on products we admired and used half a world away. That scale and magnitude is definitely something to be proud of. They encountered and solved problems at scale, establishing standards, registering patents and forming user behaviours that we take for granted today\n\nBut in our part of the world, even today, digital product design is still attempting to break out of its UI and UX tags. When I started out in 2014, UI/UX was the predominant way of describing designers in big tech, and even startups. Of course there were exceptions, but I will ignore them as outliers. The startup I worked at back then, was one of the first in India to adopt Facebook's popular convention to start using the term 'Product Designer'. Back then, the Indian digital design industry was so small. You were separated by 1-2 degrees from everyone and arguably, it's still that small. The VC funding, however, gave rise to a notion that tech startups are a lucrative career compared to the dominant IT/ITES industry. This led to a gold rush fuelled by opportunistic bootcamps and certification courses, most of which churned out low skill designers. However, unlike the West, few companies thrived and hardly any have scaled and now we have a supply-demand problem at hand.\n\nThis leads us to where we are today:\n\n1. Local companies are not getting 'Big' enough or if they are, once they get listed, they need to justify costs and respond to the market. It's quite easy for decision makers to take that call and cut a few roles to keep costs in check. Easier than getting out of your software license contracts to cut costs. Also much easier to do this when others in the industry are also doing layoffs. Smaller companies mean there are fewer senior roles to be filled especially when most teams out there are feature factories who know what to build next.\n\n2. In my experience, Design leaders in startups have always been expected to play a dual role of designer + manager. In fact the designer aspect is valued a lot more while the manager title is granted to keep designers happy. That said, Most companies do not know what to do with the design leaders that they hire. So often, what you encounter is the Design Leader who is a figurehead to appease the junior designers with almost 0 influence on business outcomes or worst case, to be head of design of a design team of 1. This explains the short tenures because those roles are just not fulfilling.\n\n3. This may anger a few, but in the current state of the industry, design progression ladders don’t need an IC track beyond the level of a senior designer of 5-6 years of experience. If you are not a Meta/Google, I don’t expect there to be scope or complexity that needs Staff Designers. So where have these senior designers been going? Well some of them move into “Manager” roles without the skills to operate in them while others tend to move out of the country to join companies which may have grown to a larger size or worst case at least they get to experience a new culture.\n\n4. The skills you need as a manager are different from the ones you polished as an IC designer. Being good at Figma can only take you so far, if you don’t have an affinity for bureaucracy, then being a manager is a bad fit. On the other extreme are the managers and heads of design, usually from a background in older big tech companies, who were at positions where their job was to pontificate about design and innovation. These folk tend to be disconnected from the day-to-day work and that’s bad for the team as well. Both of these are highly replaceable roles.\n\n5. And finally, we have not moved away from the worker productivity categorisation of industrialisation. Bell curves are common, business wants to keep control and budgets are paramount. I would like to argue that Design never got a seat at the table. The \"Design Thinking\" hype that got thrown around by IBM, McKinsey, IDEO was for their own PR and has run its due course. Everyone likes an optimistic story but rarely would you find actual organization leaders(CXOs) believing in the value that Design brings to the business and actually investing into Design. That is as true today, as it was a decade ago and hence good fulfilling design jobs are few and far between.\n\n This does not paint a very rosy picture of today's design industry but after all these years, this is my honest take on the state of affairs. Perhaps we've been swayed by all the positive marketing around design, perhaps we've believed that design in tech can save the world, but in reality, designers find themselves in a dystopia that they don't want to acknowledge. The old folks of the industry who have survived, will continue to do so but if you are a beginner, if you want to stick to design in tech, I recommend that you choose a discipline like engineering or product instead and leave your empathy at the door.","src/content/writing/design-in-tech-2024/index.md",[476],"./4IiQQOEdmqPcCsjTqlta-1.png","810211681d2c5d00",{"html":479,"metadata":480},"\u003Cp>After the Great Layoffs, I’ve been seeing too many people declaring the \u003Ca href=\"https://www.fastcompany.com/91027996/the-big-design-freak-out-a-generation-of-design-leaders-grapple-with-their-future\">death\u003C/a> of \u003Ca href=\"https://medium.com/@martynreding/how-to-survive-the-design-leadership-reckoning-ff2856bf4733\">design\u003C/a> leadership and with the rise of AI, the death of the digital design industry as well. but I find that it’s a poorly informed take and no offence, but in my opinion, written by outsiders or written about a specific industry/region/designer. In fact, there are a lot of highly \u003Ca href=\"https://maven.com/rachel-kobetz/dls-career-architecture\">priced\u003C/a> \u003Ca href=\"https://www.designdept.co/series/design-leadership-fundamentals\">leadership\u003C/a> \u003Ca href=\"https://www.aiga.org/design/design-leadership\">training\u003C/a> courses out there these days.\u003C/p>\n\u003Cp>Over my career of 10 odd years, I’ve had the honour of being an observer in the product design industry of 2 countries; India and Indonesia. My perspective comes from my vantage point of living in the Silicon Valley of India and professionally, from being part of the growth stage of the well funded startups.\u003C/p>\n\u003Cp>For this article(rant?), I will use Startups vs Big Tech for sake of categorisation. Big tech would have the minimum expectation of being a listed company operating across more than 1 geographical region. Meta and the other MAANG companies would fall into big tech but do remember that they are the new entrants in a space already filled by CISCO, Intuit, Adobe.\u003C/p>\n\u003Cp>Post the dot-com bust, we saw the slow rise of today’s modern digital startups. First in the Silicon Valley and then in the rest of the world. This was mainly fuelled by the VC funding and still is. This lead us to look up to the Silicon Valley companies and the folks there as thought leaders for design. And rightly so since they were working on products we admired and used half a world away. That scale and magnitude is definitely something to be proud of. They encountered and solved problems at scale, establishing standards, registering patents and forming user behaviours that we take for granted today\u003C/p>\n\u003Cp>But in our part of the world, even today, digital product design is still attempting to break out of its UI and UX tags. When I started out in 2014, UI/UX was the predominant way of describing designers in big tech, and even startups. Of course there were exceptions, but I will ignore them as outliers. The startup I worked at back then, was one of the first in India to adopt Facebook’s popular convention to start using the term ‘Product Designer’. Back then, the Indian digital design industry was so small. You were separated by 1-2 degrees from everyone and arguably, it’s still that small. The VC funding, however, gave rise to a notion that tech startups are a lucrative career compared to the dominant IT/ITES industry. This led to a gold rush fuelled by opportunistic bootcamps and certification courses, most of which churned out low skill designers. However, unlike the West, few companies thrived and hardly any have scaled and now we have a supply-demand problem at hand.\u003C/p>\n\u003Cp>This leads us to where we are today:\u003C/p>\n\u003Col>\n\u003Cli>\n\u003Cp>Local companies are not getting ‘Big’ enough or if they are, once they get listed, they need to justify costs and respond to the market. It’s quite easy for decision makers to take that call and cut a few roles to keep costs in check. Easier than getting out of your software license contracts to cut costs. Also much easier to do this when others in the industry are also doing layoffs. Smaller companies mean there are fewer senior roles to be filled especially when most teams out there are feature factories who know what to build next.\u003C/p>\n\u003C/li>\n\u003Cli>\n\u003Cp>In my experience, Design leaders in startups have always been expected to play a dual role of designer + manager. In fact the designer aspect is valued a lot more while the manager title is granted to keep designers happy. That said, Most companies do not know what to do with the design leaders that they hire. So often, what you encounter is the Design Leader who is a figurehead to appease the junior designers with almost 0 influence on business outcomes or worst case, to be head of design of a design team of 1. This explains the short tenures because those roles are just not fulfilling.\u003C/p>\n\u003C/li>\n\u003Cli>\n\u003Cp>This may anger a few, but in the current state of the industry, design progression ladders don’t need an IC track beyond the level of a senior designer of 5-6 years of experience. If you are not a Meta/Google, I don’t expect there to be scope or complexity that needs Staff Designers. So where have these senior designers been going? Well some of them move into “Manager” roles without the skills to operate in them while others tend to move out of the country to join companies which may have grown to a larger size or worst case at least they get to experience a new culture.\u003C/p>\n\u003C/li>\n\u003Cli>\n\u003Cp>The skills you need as a manager are different from the ones you polished as an IC designer. Being good at Figma can only take you so far, if you don’t have an affinity for bureaucracy, then being a manager is a bad fit. On the other extreme are the managers and heads of design, usually from a background in older big tech companies, who were at positions where their job was to pontificate about design and innovation. These folk tend to be disconnected from the day-to-day work and that’s bad for the team as well. Both of these are highly replaceable roles.\u003C/p>\n\u003C/li>\n\u003Cli>\n\u003Cp>And finally, we have not moved away from the worker productivity categorisation of industrialisation. Bell curves are common, business wants to keep control and budgets are paramount. I would like to argue that Design never got a seat at the table. The “Design Thinking” hype that got thrown around by IBM, McKinsey, IDEO was for their own PR and has run its due course. Everyone likes an optimistic story but rarely would you find actual organization leaders(CXOs) believing in the value that Design brings to the business and actually investing into Design. That is as true today, as it was a decade ago and hence good fulfilling design jobs are few and far between.\u003C/p>\n\u003Cp>This does not paint a very rosy picture of today’s design industry but after all these years, this is my honest take on the state of affairs. Perhaps we’ve been swayed by all the positive marketing around design, perhaps we’ve believed that design in tech can save the world, but in reality, designers find themselves in a dystopia that they don’t want to acknowledge. The old folks of the industry who have survived, will continue to do so but if you are a beginner, if you want to stick to design in tech, I recommend that you choose a discipline like engineering or product instead and leave your empathy at the door.\u003C/p>\n\u003C/li>\n\u003C/ol>",{"headings":481,"localImagePaths":482,"remoteImagePaths":483,"frontmatter":484,"imagePaths":486},[],[],[],{"title":469,"description":470,"date":485,"image":476},"2024-01-01",[],"design-tools-decade",{"id":487,"data":489,"body":494,"filePath":495,"assetImports":496,"digest":502,"rendered":503},{"title":490,"description":491,"date":492,"image":493,"status":19},"How far we've come: The last decade of design tools","A lookback at the evolution of design tools from Photoshop to Figma",["Date","2024-01-15T00:00:00.000Z"],"__ASTRO_IMAGE_./lookback-design-tools-1.jpg","Last night, I was thinking about how much the interface design and prototyping landscape has changed in the last decade. I started using Sketch and Marvelapp in 2014 when the predominant tools were Adobe Illustrator/Photoshop/Fireworks for UI, Balsamiq for low fidelity, Axure, Omnigraffle and Keynote for clickable prototypes. Some of these still exist today. While others like Antetype, Invision are no more.\n\nI was taught to design on [Photoshop](https://graphicdesign.stackexchange.com/questions/17928/what-is-the-exact-role-relationship-of-photoshop-in-web-design) at my first job. Even though, modern app stores had released three years earlier, websites was what we were designing back then. The Photoshop art boards we designed, would be ‘sliced’ and used in our HTML/CSS mockups. '[Redlining](https://x.com/teehanlax/status/560820287953195008)' was common practice for dev handovers. For personal projects and at hackathons, new age CSS/JS libraries like [Twitter Bootstrap](https://getbootstrap.com/1.0.0/) started being used. The designs I made back then are horrible and still exist in un-recoverable file formats (Okay, I actually found a photo of [one design](https://photos.app.goo.gl/yx1heXKvGiAFAkNn7)). Back then, I was a developer with an engineering degree working in a MNC IT company so I can’t blame myself for it.\n\n![A wireframe of mine from March 2012 for an event discovery startup idea.](./lookback-design-tools-1.jpg)\n\nWhen I was at Design school, using Adobe Illustrator for its vector capabilities became common place. We worked on information graphics and photoshop just didn't cut it for our workflow. It was largely a skill problem since we had no teachers for our tools, whatever we did was with knowledge from the internet and our peers. Outside in the world, the industry was using tools like Axure, Omnigraffle and Keynote and Teehan+Lax had legendary status in their community for their annual release of their iOS kits.\n\n![Teehan+Lax pictured in their iconic profile photo](./lookback-design-tools-2.jpg)\n\nBy the time we graduated, there had been changes in this ecosystem. Sketch started picking up market share, smart phone penetration was trending up and collaboration became an important buzzword. It was 2014.\n\nBy the time, I started my internship, Material Design had launched and I upgraded from my ancient Sony Viao to a MacBook Air (on EMI). We adopted Sketch and Marvelapp at my workplace.\n\n![My first Marvelapp prototype - June 2014. Created for my Master's submission, still seems to work.](./lookback-design-tools-3.png)\n\nBack then, Sketch files were saved in Google Drive Shared Drives for archival and access across the team. You still needed a license to access proprietary content so we still needed to redline screens and share exports in folders. This lead to tools like Zeplin, Invision and Marvelapp coming in to fill this gap. The next year, Facebook released [Origami](https://engineering.fb.com/2015/02/24/ios/introducing-origami-live/) built on top of Quartz Composer followed by [Framer 1.0](https://medium.com/insightdesign/this-is-how-i-tried-framer-in-8-active-hours-trial-c4a8a0392267) in the next year. That was the start of making prototypes multi-dimensional and letting users “interact” with UI elements and granting access to device hardware sensors like camera. There were [people](https://medium.com/framer-prototyping/making-framer-prototypes-talk-to-each-other-web-sockets-framer-85eedd2243aa) [that I](https://dribbble.com/shots/3699875-Life-Advices-app-Concept/attachments/9971472?mode=media) [knew](https://x.com/vikxlp/status/893453311210250240) making really cool stuff with this.\n\n![An Android date selector prototype I designed on Pixate and got implemented in 2015](./lookback-design-tools-4.png)\n\nNext, Figma and Abstract started up trying to solve the file organization and collaboration problem in their own way; Figma’s USP was that it was browser based and hence could be used by non-mac users so great for budding designers who couldn’t afford a Mac. I didn't use Figma until Jan 2022.\n\nAbstract targeted the existing Sketch user base and tried to introduce branching to the designer audience (albeit unsuccessfully?). [Framer X](https://blog.prototypr.io/framer-x-preview-9d067f35cf9a) built some hype but it didn’t catch on. I had beta access and building out a component system on Framer X(React) needed Dev support which most design teams didn’t have the luxury of. This (circa 2019) is when you started noticing design teams around the world having UX Engineers in their rosters. Design systems evolved out of style guides with the help of UX engineering and now we take design sytems to have both a design and code aspect to them along with voice, tone, illustrations, etc.\n\n![A responsive no-code app I built on Glide to help me expense bills for work travel](./lookback-design-tools-5.png)\n\nThen came the no-code/low-code revolution which simplified the ease of creation further and tools like Glideapps, Bubble and Landbot now make it easy for you to prototype and share ideas. And that brings us to 2024, where we are seeing the rise of AI assisted design and dev tools getting focus. These aren’t there yet but I wish with this we can sunset that beaten to death question of “Should designers code?”","src/content/writing/design-tools-decade/index.md",[497,498,499,500,501],"./lookback-design-tools-1.jpg","./lookback-design-tools-2.jpg","./lookback-design-tools-3.png","./lookback-design-tools-4.png","./lookback-design-tools-5.png","a11d46d7e892ab01",{"html":504,"metadata":505},"\u003Cp>Last night, I was thinking about how much the interface design and prototyping landscape has changed in the last decade. I started using Sketch and Marvelapp in 2014 when the predominant tools were Adobe Illustrator/Photoshop/Fireworks for UI, Balsamiq for low fidelity, Axure, Omnigraffle and Keynote for clickable prototypes. Some of these still exist today. While others like Antetype, Invision are no more.\u003C/p>\n\u003Cp>I was taught to design on \u003Ca href=\"https://graphicdesign.stackexchange.com/questions/17928/what-is-the-exact-role-relationship-of-photoshop-in-web-design\">Photoshop\u003C/a> at my first job. Even though, modern app stores had released three years earlier, websites was what we were designing back then. The Photoshop art boards we designed, would be ‘sliced’ and used in our HTML/CSS mockups. ‘\u003Ca href=\"https://x.com/teehanlax/status/560820287953195008\">Redlining\u003C/a>’ was common practice for dev handovers. For personal projects and at hackathons, new age CSS/JS libraries like \u003Ca href=\"https://getbootstrap.com/1.0.0/\">Twitter Bootstrap\u003C/a> started being used. The designs I made back then are horrible and still exist in un-recoverable file formats (Okay, I actually found a photo of \u003Ca href=\"https://photos.app.goo.gl/yx1heXKvGiAFAkNn7\">one design\u003C/a>). Back then, I was a developer with an engineering degree working in a MNC IT company so I can’t blame myself for it.\u003C/p>\n\u003Cfigure class=\"image-figure\">\u003Cimg __ASTRO_IMAGE_=\"{"src":"./lookback-design-tools-1.jpg","alt":"A wireframe of mine from March 2012 for an event discovery startup idea.","index":0}\">\u003Cfigcaption>A wireframe of mine from March 2012 for an event discovery startup idea.\u003C/figcaption>\u003C/figure>\n\u003Cp>When I was at Design school, using Adobe Illustrator for its vector capabilities became common place. We worked on information graphics and photoshop just didn’t cut it for our workflow. It was largely a skill problem since we had no teachers for our tools, whatever we did was with knowledge from the internet and our peers. Outside in the world, the industry was using tools like Axure, Omnigraffle and Keynote and Teehan+Lax had legendary status in their community for their annual release of their iOS kits.\u003C/p>\n\u003Cfigure class=\"image-figure\">\u003Cimg __ASTRO_IMAGE_=\"{"src":"./lookback-design-tools-2.jpg","alt":"Teehan+Lax pictured in their iconic profile photo","index":0}\">\u003Cfigcaption>Teehan+Lax pictured in their iconic profile photo\u003C/figcaption>\u003C/figure>\n\u003Cp>By the time we graduated, there had been changes in this ecosystem. Sketch started picking up market share, smart phone penetration was trending up and collaboration became an important buzzword. It was 2014.\u003C/p>\n\u003Cp>By the time, I started my internship, Material Design had launched and I upgraded from my ancient Sony Viao to a MacBook Air (on EMI). We adopted Sketch and Marvelapp at my workplace.\u003C/p>\n\u003Cfigure class=\"image-figure\">\u003Cimg __ASTRO_IMAGE_=\"{"src":"./lookback-design-tools-3.png","alt":"My first Marvelapp prototype - June 2014. Created for my Master's submission, still seems to work.","index":0}\">\u003Cfigcaption>My first Marvelapp prototype - June 2014. Created for my Master's submission, still seems to work.\u003C/figcaption>\u003C/figure>\n\u003Cp>Back then, Sketch files were saved in Google Drive Shared Drives for archival and access across the team. You still needed a license to access proprietary content so we still needed to redline screens and share exports in folders. This lead to tools like Zeplin, Invision and Marvelapp coming in to fill this gap. The next year, Facebook released \u003Ca href=\"https://engineering.fb.com/2015/02/24/ios/introducing-origami-live/\">Origami\u003C/a> built on top of Quartz Composer followed by \u003Ca href=\"https://medium.com/insightdesign/this-is-how-i-tried-framer-in-8-active-hours-trial-c4a8a0392267\">Framer 1.0\u003C/a> in the next year. That was the start of making prototypes multi-dimensional and letting users “interact” with UI elements and granting access to device hardware sensors like camera. There were \u003Ca href=\"https://medium.com/framer-prototyping/making-framer-prototypes-talk-to-each-other-web-sockets-framer-85eedd2243aa\">people\u003C/a> \u003Ca href=\"https://dribbble.com/shots/3699875-Life-Advices-app-Concept/attachments/9971472?mode=media\">that I\u003C/a> \u003Ca href=\"https://x.com/vikxlp/status/893453311210250240\">knew\u003C/a> making really cool stuff with this.\u003C/p>\n\u003Cfigure class=\"image-figure\">\u003Cimg __ASTRO_IMAGE_=\"{"src":"./lookback-design-tools-4.png","alt":"An Android date selector prototype I designed on Pixate and got implemented in 2015","index":0}\">\u003Cfigcaption>An Android date selector prototype I designed on Pixate and got implemented in 2015\u003C/figcaption>\u003C/figure>\n\u003Cp>Next, Figma and Abstract started up trying to solve the file organization and collaboration problem in their own way; Figma’s USP was that it was browser based and hence could be used by non-mac users so great for budding designers who couldn’t afford a Mac. I didn’t use Figma until Jan 2022.\u003C/p>\n\u003Cp>Abstract targeted the existing Sketch user base and tried to introduce branching to the designer audience (albeit unsuccessfully?). \u003Ca href=\"https://blog.prototypr.io/framer-x-preview-9d067f35cf9a\">Framer X\u003C/a> built some hype but it didn’t catch on. I had beta access and building out a component system on Framer X(React) needed Dev support which most design teams didn’t have the luxury of. This (circa 2019) is when you started noticing design teams around the world having UX Engineers in their rosters. Design systems evolved out of style guides with the help of UX engineering and now we take design sytems to have both a design and code aspect to them along with voice, tone, illustrations, etc.\u003C/p>\n\u003Cfigure class=\"image-figure\">\u003Cimg __ASTRO_IMAGE_=\"{"src":"./lookback-design-tools-5.png","alt":"A responsive no-code app I built on Glide to help me expense bills for work travel","index":0}\">\u003Cfigcaption>A responsive no-code app I built on Glide to help me expense bills for work travel\u003C/figcaption>\u003C/figure>\n\u003Cp>Then came the no-code/low-code revolution which simplified the ease of creation further and tools like Glideapps, Bubble and Landbot now make it easy for you to prototype and share ideas. And that brings us to 2024, where we are seeing the rise of AI assisted design and dev tools getting focus. These aren’t there yet but I wish with this we can sunset that beaten to death question of “Should designers code?”\u003C/p>",{"headings":506,"localImagePaths":507,"remoteImagePaths":508,"frontmatter":509,"imagePaths":511},[],[497,498,499,500,501],[],{"title":490,"description":491,"date":510,"image":497},"2024-01-15",[497,498,499,500,501],"hiring",{"id":512,"data":514,"body":519,"filePath":520,"assetImports":521,"digest":523,"rendered":524},{"title":515,"description":516,"date":517,"image":518,"status":19},"Thoughts on Hiring","Best practices for hiring designers based on my experiences hiring over the last 6 years",["Date","2021-08-19T00:00:00.000Z"],"__ASTRO_IMAGE_./design-keliling.jpg","> \"For every open job on your team, you need to spend one hour a day on recruiting-related activities. Cap that investment at 50% of your time.\"\n>\n> –– [Rands](https://randsinrepose.com/archives/how-to-recruit/)\n\nI strongly believe that hiring is a critical focus area for a design leader. I've been part of hiring panels since 2015. I've seen companies usually do not focus on hiring flows leading them to have a bad experience for interviewing candidates.\n\nI gave a short talk about hiring designers at a friend's startup in 2018 which could be drilled down into the following key points.\n\n1. **Write good job descriptions:**\n The industry is filled with nonsense JDs ~written~ copy-pasted by HRs. If you need to stand out, you need to write a good JD.\n Hire a design consultant to help you out with this if you are hiring the first designer for your startup.\n2. **Don't let a portfolio be a barrier for applying:**\n For entry level roles, I feel a portfolio acts like your resume but when you start hiring for senior designer roles you may want to broaden the application criteria.\n Most designers I know do not have an updated portfolio and this prevents them from applying to your startup if they are interested.\n3. **Customize application form to allow folks to upload a digital document:**\n The tool you use to run your hiring needs to be flexible to cater to your design hiring needs. \n At Gojek, we used Lever and for the longest time we did not have a way for designer applicants to upload a pdf portfolio.\n Binoy and I sat and figured out how to add it to the application form, however for internal referrals we were not able to enable it as Lever doesnt let you customize the form.\n4. **Keep the face-to-face rounds short:**\n In the interest of everyone's time, its best if you can earmark a particular day of the week for interviews and schedule all the rounds on that day for candidates.\n For this to work, your screening rounds need to be well designed so as to not overload your panelists.\n5. **Scaling the process:**\n If you have a lot of reqs to fill, you will need to get others to take part in the interview process.\n Playbooks and evaluation templates help scale the process while maintaining quality.\n \n\u003Cp class=\"attribution\"> Cover image: Taken at the end of the Bandung edition of \u003Ca href=\"https://www.linkedin.com/posts/trinugraha_gojekdesainkeliling-activity-6594891829370556416--yhf\">Gojek Desain Keliling\u003C/a>, Gojek's attempt to recruit designers in a sort of reality contest where winners would get golden tickets\n and a chance to be a part of the Gojek design team.\u003C/p>","src/content/writing/hiring/index.md",[522],"./design-keliling.jpg","16472590845e8714",{"html":525,"metadata":526},"\u003Cblockquote>\n\u003Cp>“For every open job on your team, you need to spend one hour a day on recruiting-related activities. Cap that investment at 50% of your time.”\u003C/p>\n\u003Cp>–– \u003Ca href=\"https://randsinrepose.com/archives/how-to-recruit/\">Rands\u003C/a>\u003C/p>\n\u003C/blockquote>\n\u003Cp>I strongly believe that hiring is a critical focus area for a design leader. I’ve been part of hiring panels since 2015. I’ve seen companies usually do not focus on hiring flows leading them to have a bad experience for interviewing candidates.\u003C/p>\n\u003Cp>I gave a short talk about hiring designers at a friend’s startup in 2018 which could be drilled down into the following key points.\u003C/p>\n\u003Col>\n\u003Cli>\u003Cstrong>Write good job descriptions:\u003C/strong>\nThe industry is filled with nonsense JDs \u003Cdel>written\u003C/del> copy-pasted by HRs. If you need to stand out, you need to write a good JD.\nHire a design consultant to help you out with this if you are hiring the first designer for your startup.\u003C/li>\n\u003Cli>\u003Cstrong>Don’t let a portfolio be a barrier for applying:\u003C/strong>\nFor entry level roles, I feel a portfolio acts like your resume but when you start hiring for senior designer roles you may want to broaden the application criteria.\nMost designers I know do not have an updated portfolio and this prevents them from applying to your startup if they are interested.\u003C/li>\n\u003Cli>\u003Cstrong>Customize application form to allow folks to upload a digital document:\u003C/strong>\nThe tool you use to run your hiring needs to be flexible to cater to your design hiring needs.\nAt Gojek, we used Lever and for the longest time we did not have a way for designer applicants to upload a pdf portfolio.\nBinoy and I sat and figured out how to add it to the application form, however for internal referrals we were not able to enable it as Lever doesnt let you customize the form.\u003C/li>\n\u003Cli>\u003Cstrong>Keep the face-to-face rounds short:\u003C/strong>\nIn the interest of everyone’s time, its best if you can earmark a particular day of the week for interviews and schedule all the rounds on that day for candidates.\nFor this to work, your screening rounds need to be well designed so as to not overload your panelists.\u003C/li>\n\u003Cli>\u003Cstrong>Scaling the process:\u003C/strong>\nIf you have a lot of reqs to fill, you will need to get others to take part in the interview process.\nPlaybooks and evaluation templates help scale the process while maintaining quality.\u003C/li>\n\u003C/ol>\n\u003Cp class=\"attribution\"> Cover image: Taken at the end of the Bandung edition of \u003Ca href=\"https://www.linkedin.com/posts/trinugraha_gojekdesainkeliling-activity-6594891829370556416--yhf\">Gojek Desain Keliling\u003C/a>, Gojek's attempt to recruit designers in a sort of reality contest where winners would get golden tickets\n and a chance to be a part of the Gojek design team.\u003C/p>",{"headings":527,"localImagePaths":528,"remoteImagePaths":529,"frontmatter":530,"imagePaths":532},[],[],[],{"title":515,"description":516,"date":531,"image":522},"2021-08-19",[],"hiring-2",{"id":533,"data":535,"body":540,"filePath":541,"assetImports":542,"digest":544,"rendered":545},{"title":536,"description":537,"date":538,"image":539,"status":19},"Thoughts on Hiring, part 2","Reflections on hiring based on my experience building the product design team at Jiva",["Date","2025-12-07T00:00:00.000Z"],"__ASTRO_IMAGE_./whiteboard.JPG","There are lot of opinions out there about hiring. [Part 1](https://kenneth.dsouza.im/writing/hiring/) was written in 2020-21, when I was on interview panels for product design and product management. Whereas Part 2 consists of my reflections\nafter being in the role of the hiring manager and co-designing Jiva's hiring process.\n\n### 1. Your hiring process is a reflection of your culture\n\nThe design hiring process isn't standardised. These days you'll see a variety of rounds; visual portfolios, take-home assignments, whiteboarding sessions, etc. The mix you choose isn't random; it's a *reflection* of your organization's culture. You're designing a candidate's very first experience of how your team thinks and works.\n\nDifferent rounds signal different things. Asking for visual designs in a portfolio implies that your product team drives the flows and you need someone with strong visual craft. Take-home assignments (and their subsequent presentation) reveal the candidate's communication skills, which can be especially useful if your team works in a traditional \"siloed\" setup. Collaborative whiteboarding sessions show you how it feels to partner with them day-to-day but usually your organization's designers work solo within their own teams.\n\nNone of these are inherently wrong. But if you are not mindful about your processes you end up unnecessarily making the candidate experience time consuming, anxiety-filled, and worse, you start evaluating candidates for the wrong set of attributes — a costly mistake that almost always leads to failure down the line. \n\u003C!-- (You can read about how we designed our product design hiring process at Jiva here.) -->\n\n\n### 2. Today’s design team needs to be multi-faceted\n\nWhen I first started taking interviews (in 2015), my evaluation criteria naturally leaned toward a certain kind of product designer — usually someone whose strengths mirrored what **I** personally valued. That worked when every designer owned a single product end-to-end. But as the organization grew, this approach started breaking down. Designers now had to work together, share problem spaces, and complement one another's strengths rather than operate in isolation and we hadn't hired for that.\n\nA better approach — and one I wish I had learnt earlier[^1] — is to step back and visualise your team's skillset as a whole. One simple way to do this is by mapping your organization's design competencies onto a rough [spider chart or competency map](https://medium.com/shapingdesign/the-ux-spectrum-cb29f048faf9)[^2] and plotting each designer against it. It doesn’t need to be perfect; the point is to create a shared view of where your team is strong, where it’s weak, and if you’re overly dependent on the skills of a single person. \n\n![UX Spectrum via Jason Mesut's Shaping Design series](https://miro.medium.com/v2/resize:fit:2000/format:webp/1*Vi4kDiI5uLhlXJdztg7lwg.png)\n\nThis kind of visualisation becomes even more valuable when you’re managing multiple teams or products. It gives you clarity on what gaps you’re trying to fill, instead of defaulting to hiring “more of the same.” For example, pairing a highly visual designer with a more analytical one can create a healthier balance, with each designer taking control of the tasks as per their skill sets. \n\nIn other words, what you need to realise is that you are not hiring an individual — you’re shaping the distribution of strengths and weaknesses across your entire design function. \n\n\n### 3. There is no place for ego in the team\n\nIt’s called a design team for a reason. The product the user experiences should feel seamless, not like a patchwork of different personalities, preferences, or stylistic signatures. One of the biggest gaps in a skills-only evaluation is that it completely misses the *collaboration layer* of design: how someone shows up, how they listen, and how they work with others under pressure. \n\nYour spider chart or competency map can show you strengths and weaknesses in craft, but it won't tell you whether a candidate can actually work well with the rest of your organization. That’s where cultural alignment matters. A designer who is stubborn, who refuses to take cross-functional feedback, or insists on “their way” will quickly become a bottleneck — no matter how talented they are. \n\nGetting people who play well together is one of the most underrated aspects of building a high-performing design org. A difficult personality erodes trust, slows down execution, and adds unnecessary emotional weight on everyone else — a mess that you, as the design manager, will spend a lot of time and energy sorting out. \n\nThis is why running a “vibe check” through your existing team — designers, PMs, engineers — can be invaluable. These aren’t popularity tests; they’re ways to sense how someone collaborates in real, messy, day-to-day situations and to check how excited stakeholders are about working with the candidate.\n\nThe goal isn’t to hire the best individual — it’s to hire the person who will make the team stronger.\n\n\n\u003Cp class=\"attribution\"> Cover image: Akshay, Hetang and Riya working on a whiteboard at Practo, 4 April 2017\u003C/p>\n\n[^1]: Derived learning from faculty from Ownpath Manager training in Q1 2020 where we interacted with Kristin Skinner, Alysha Naples, and Meredith Black.\n[^2]: Jason Mesut's Shaping Design series of posts is full of useful toolkits and design management frameworks.","src/content/writing/hiring-2/index.md",[543],"./whiteboard.JPG","b23c68bc14f2b699",{"html":546,"metadata":547},"\u003Cp>There are lot of opinions out there about hiring. \u003Ca href=\"https://kenneth.dsouza.im/writing/hiring/\">Part 1\u003C/a> was written in 2020-21, when I was on interview panels for product design and product management. Whereas Part 2 consists of my reflections\nafter being in the role of the hiring manager and co-designing Jiva’s hiring process.\u003C/p>\n\u003Ch3 id=\"1-your-hiring-process-is-a-reflection-of-your-culture\">1. Your hiring process is a reflection of your culture\u003C/h3>\n\u003Cp>The design hiring process isn’t standardised. These days you’ll see a variety of rounds; visual portfolios, take-home assignments, whiteboarding sessions, etc. The mix you choose isn’t random; it’s a \u003Cem>reflection\u003C/em> of your organization’s culture. You’re designing a candidate’s very first experience of how your team thinks and works.\u003C/p>\n\u003Cp>Different rounds signal different things. Asking for visual designs in a portfolio implies that your product team drives the flows and you need someone with strong visual craft. Take-home assignments (and their subsequent presentation) reveal the candidate’s communication skills, which can be especially useful if your team works in a traditional “siloed” setup. Collaborative whiteboarding sessions show you how it feels to partner with them day-to-day but usually your organization’s designers work solo within their own teams.\u003C/p>\n\u003Cp>None of these are inherently wrong. But if you are not mindful about your processes you end up unnecessarily making the candidate experience time consuming, anxiety-filled, and worse, you start evaluating candidates for the wrong set of attributes — a costly mistake that almost always leads to failure down the line.\u003C/p>\n\u003C!-- (You can read about how we designed our product design hiring process at Jiva here.) -->\n\u003Ch3 id=\"2-todays-design-team-needs-to-be-multi-faceted\">2. Today’s design team needs to be multi-faceted\u003C/h3>\n\u003Cp>When I first started taking interviews (in 2015), my evaluation criteria naturally leaned toward a certain kind of product designer — usually someone whose strengths mirrored what \u003Cstrong>I\u003C/strong> personally valued. That worked when every designer owned a single product end-to-end. But as the organization grew, this approach started breaking down. Designers now had to work together, share problem spaces, and complement one another’s strengths rather than operate in isolation and we hadn’t hired for that.\u003C/p>\n\u003Cp>A better approach — and one I wish I had learnt earlier\u003Csup>\u003Ca href=\"#user-content-fn-1\" id=\"user-content-fnref-1\" data-footnote-ref=\"\" aria-describedby=\"footnote-label\">1\u003C/a>\u003C/sup> — is to step back and visualise your team’s skillset as a whole. One simple way to do this is by mapping your organization’s design competencies onto a rough \u003Ca href=\"https://medium.com/shapingdesign/the-ux-spectrum-cb29f048faf9\">spider chart or competency map\u003C/a>\u003Csup>\u003Ca href=\"#user-content-fn-2\" id=\"user-content-fnref-2\" data-footnote-ref=\"\" aria-describedby=\"footnote-label\">2\u003C/a>\u003C/sup> and plotting each designer against it. It doesn’t need to be perfect; the point is to create a shared view of where your team is strong, where it’s weak, and if you’re overly dependent on the skills of a single person.\u003C/p>\n\u003Cfigure class=\"image-figure\">\u003Cimg src=\"https://miro.medium.com/v2/resize:fit:2000/format:webp/1*Vi4kDiI5uLhlXJdztg7lwg.png\" alt=\"UX Spectrum via Jason Mesut's Shaping Design series\">\u003Cfigcaption>UX Spectrum via Jason Mesut's Shaping Design series\u003C/figcaption>\u003C/figure>\n\u003Cp>This kind of visualisation becomes even more valuable when you’re managing multiple teams or products. It gives you clarity on what gaps you’re trying to fill, instead of defaulting to hiring “more of the same.” For example, pairing a highly visual designer with a more analytical one can create a healthier balance, with each designer taking control of the tasks as per their skill sets.\u003C/p>\n\u003Cp>In other words, what you need to realise is that you are not hiring an individual — you’re shaping the distribution of strengths and weaknesses across your entire design function.\u003C/p>\n\u003Ch3 id=\"3-there-is-no-place-for-ego-in-the-team\">3. There is no place for ego in the team\u003C/h3>\n\u003Cp>It’s called a design team for a reason. The product the user experiences should feel seamless, not like a patchwork of different personalities, preferences, or stylistic signatures. One of the biggest gaps in a skills-only evaluation is that it completely misses the \u003Cem>collaboration layer\u003C/em> of design: how someone shows up, how they listen, and how they work with others under pressure.\u003C/p>\n\u003Cp>Your spider chart or competency map can show you strengths and weaknesses in craft, but it won’t tell you whether a candidate can actually work well with the rest of your organization. That’s where cultural alignment matters. A designer who is stubborn, who refuses to take cross-functional feedback, or insists on “their way” will quickly become a bottleneck — no matter how talented they are.\u003C/p>\n\u003Cp>Getting people who play well together is one of the most underrated aspects of building a high-performing design org. A difficult personality erodes trust, slows down execution, and adds unnecessary emotional weight on everyone else — a mess that you, as the design manager, will spend a lot of time and energy sorting out.\u003C/p>\n\u003Cp>This is why running a “vibe check” through your existing team — designers, PMs, engineers — can be invaluable. These aren’t popularity tests; they’re ways to sense how someone collaborates in real, messy, day-to-day situations and to check how excited stakeholders are about working with the candidate.\u003C/p>\n\u003Cp>The goal isn’t to hire the best individual — it’s to hire the person who will make the team stronger.\u003C/p>\n\u003Cp class=\"attribution\"> Cover image: Akshay, Hetang and Riya working on a whiteboard at Practo, 4 April 2017\u003C/p>\n\u003Csection data-footnotes=\"\" class=\"footnotes\">\u003Ch2 class=\"sr-only\" id=\"footnote-label\">Footnotes\u003C/h2>\n\u003Col>\n\u003Cli id=\"user-content-fn-1\">\n\u003Cp>Derived learning from faculty from Ownpath Manager training in Q1 2020 where we interacted with Kristin Skinner, Alysha Naples, and Meredith Black. \u003Ca href=\"#user-content-fnref-1\" data-footnote-backref=\"\" aria-label=\"Back to reference 1\" class=\"data-footnote-backref\">↩\u003C/a>\u003C/p>\n\u003C/li>\n\u003Cli id=\"user-content-fn-2\">\n\u003Cp>Jason Mesut’s Shaping Design series of posts is full of useful toolkits and design management frameworks. \u003Ca href=\"#user-content-fnref-2\" data-footnote-backref=\"\" aria-label=\"Back to reference 2\" class=\"data-footnote-backref\">↩\u003C/a>\u003C/p>\n\u003C/li>\n\u003C/ol>\n\u003C/section>",{"headings":548,"localImagePaths":559,"remoteImagePaths":560,"frontmatter":561,"imagePaths":563},[549,552,555,558],{"depth":44,"slug":550,"text":551},"1-your-hiring-process-is-a-reflection-of-your-culture","1. Your hiring process is a reflection of your culture",{"depth":44,"slug":553,"text":554},"2-todays-design-team-needs-to-be-multi-faceted","2. Today’s design team needs to be multi-faceted",{"depth":44,"slug":556,"text":557},"3-there-is-no-place-for-ego-in-the-team","3. There is no place for ego in the team",{"depth":37,"slug":85,"text":86},[],[],{"title":536,"description":537,"date":562,"status":19,"image":543},"2025-12-07",[],"how-i-build-with-ai",{"id":564,"data":566,"body":571,"filePath":572,"assetImports":573,"digest":577,"rendered":578},{"title":567,"description":568,"date":569,"image":570,"status":19},"How I build with AI","A short overview of how I use AI when making my projects",["Date","2026-05-21T00:00:00.000Z"],"__ASTRO_IMAGE_./how-i-build.png","I've been making stuff almost every week (like this [threejs space-viz](https://eternal-nebula-33dy.here.now/) this week), not everything I make ends up being shared but there's a particular method to my madness.\n\n### Measure twice, cut once\nMost of my projects start their journey in a Claude Chat. Claude's research and artifact generation capabilities right in the chat accessible from anywhere via mobile makes it easy to riff on the idea while on-the-go. Plus given my product and design experience, I can easily manage to visualize designs and flows in my mind. \n\n![An example of how a UI description vs Output looks like](./grindsize.png)\n\nIf you are unclear about the technologies, you can get Claude to ask you questions to refine the idea. This conversation at the beginning of a project is like the understand phase of the design process. \n### Ready, Set up, Go\nSetup involves downloading the artifact (or plan.md, figma make file, etc) to my laptop and create a github repo to work in. Depending on the task and my situation, I spin up Claude on local or on cloud. \n\nAlthough I started using Claude via the cloud setup and moved to Claude Desktop, using Claude via terminal has been easier because it can do more for lazy old me without being buggy as Claude desktop. (note to anthropic: steal codex's reliability and not it's style) \n\nI don't use skills, etc at the start. I feel [they are over-rated](https://blog.jim-nielsen.com/2026/opacity-of-generative-tools/) and is like outsourcing your design decisions. I don't work with an org or a design system so making my own 'design.md' feels unnecessary. I rather spend this time finding references and making mood boards. I don't build complicated technical systems, so I don't worry about code quality either. Most of my projects are a single HTML file. YMMV.\n### Rinse and Repeat\nWhile I rarely use skills while pro, sub-agents is something I've started to adopt. For e.g, for [grindsize.in](grindsize.in), where scaling the project would expect me to do repeated tasks, I employ 2 [sub-agents](https://github.com/inosaint/grinder-calibrator/tree/main/.claude/agents). I don't write these sub-agents, but just like my approach with skills, I ask Claude to generate them for me. When defining skills, I do specify the kind of model I want to power the sub-agent based on the task complexity and for token conservation. \n\nThe process of creating sub-agents is similar to my process of creating skills. I make Claude create an outcome I plan. I test and review it. I make changes where required. Once I'm certain of the quality of the outcome, I check with Claude about making the process into an agent/skill. A point to note is that at times, certain process may work better as code rather than an agent. Listen to Claude.\n### Tests, Evals... 🚀\nTesting takes like 90% of my time on every project. Making everything responsive is hard and the browser space is fragmented and it has led me to some interesting browser specific bugs that have stumped the LLMs. ngl, it's feels great to solve them and I can do that because I understand a bit of web technology. \n\nAnother thing I wish I did more of is *evals*. Evals helps me when I don't understand the code that is being written. I get another agent to review one agent's work. I consider it to be like a design critique or code review. To manage complex projects and usage limits, I keep a memory.md, agents.md and claude.md files to help with this back and forth.\n\n![How variant helped me improve the visual style of Dominic, a AI based Figma Plugin](./variant.png)\n### LLM based tools I currently use:\n- **Claude:** Bulk to work done on Sonnet + API\n- **Codex (Free):** Mainly for evals and bug fixes\n- **ChatGPT:** Prompt definition, Image gen, API\n- **Gemini:** ImageGen, Deep Research and Prompt definition\n- **Variant.com:** Amazing for a functional minded designer like me, not sure how long they can survive though.\n\n--\n\n\n*If you are non-technical and want to learn how to to use AI to build, you can check out my free guide at [howtoaicode.com](howtoaicode.com)*","src/content/writing/how-i-build-with-ai/index.md",[574,575,576],"./grindsize.png","./variant.png","./how-i-build.png","d46483c08751419f",{"html":579,"metadata":580},"\u003Cp>I’ve been making stuff almost every week (like this \u003Ca href=\"https://eternal-nebula-33dy.here.now/\">threejs space-viz\u003C/a> this week), not everything I make ends up being shared but there’s a particular method to my madness.\u003C/p>\n\u003Ch3 id=\"measure-twice-cut-once\">Measure twice, cut once\u003C/h3>\n\u003Cp>Most of my projects start their journey in a Claude Chat. Claude’s research and artifact generation capabilities right in the chat accessible from anywhere via mobile makes it easy to riff on the idea while on-the-go. Plus given my product and design experience, I can easily manage to visualize designs and flows in my mind.\u003C/p>\n\u003Cfigure class=\"image-figure\">\u003Cimg __ASTRO_IMAGE_=\"{"src":"./grindsize.png","alt":"An example of how a UI description vs Output looks like","index":0}\">\u003Cfigcaption>An example of how a UI description vs Output looks like\u003C/figcaption>\u003C/figure>\n\u003Cp>If you are unclear about the technologies, you can get Claude to ask you questions to refine the idea. This conversation at the beginning of a project is like the understand phase of the design process.\u003C/p>\n\u003Ch3 id=\"ready-set-up-go\">Ready, Set up, Go\u003C/h3>\n\u003Cp>Setup involves downloading the artifact (or plan.md, figma make file, etc) to my laptop and create a github repo to work in. Depending on the task and my situation, I spin up Claude on local or on cloud.\u003C/p>\n\u003Cp>Although I started using Claude via the cloud setup and moved to Claude Desktop, using Claude via terminal has been easier because it can do more for lazy old me without being buggy as Claude desktop. (note to anthropic: steal codex’s reliability and not it’s style)\u003C/p>\n\u003Cp>I don’t use skills, etc at the start. I feel \u003Ca href=\"https://blog.jim-nielsen.com/2026/opacity-of-generative-tools/\">they are over-rated\u003C/a> and is like outsourcing your design decisions. I don’t work with an org or a design system so making my own ‘design.md’ feels unnecessary. I rather spend this time finding references and making mood boards. I don’t build complicated technical systems, so I don’t worry about code quality either. Most of my projects are a single HTML file. YMMV.\u003C/p>\n\u003Ch3 id=\"rinse-and-repeat\">Rinse and Repeat\u003C/h3>\n\u003Cp>While I rarely use skills while pro, sub-agents is something I’ve started to adopt. For e.g, for \u003Ca href=\"grindsize.in\">grindsize.in\u003C/a>, where scaling the project would expect me to do repeated tasks, I employ 2 \u003Ca href=\"https://github.com/inosaint/grinder-calibrator/tree/main/.claude/agents\">sub-agents\u003C/a>. I don’t write these sub-agents, but just like my approach with skills, I ask Claude to generate them for me. When defining skills, I do specify the kind of model I want to power the sub-agent based on the task complexity and for token conservation.\u003C/p>\n\u003Cp>The process of creating sub-agents is similar to my process of creating skills. I make Claude create an outcome I plan. I test and review it. I make changes where required. Once I’m certain of the quality of the outcome, I check with Claude about making the process into an agent/skill. A point to note is that at times, certain process may work better as code rather than an agent. Listen to Claude.\u003C/p>\n\u003Ch3 id=\"tests-evals--\">Tests, Evals… 🚀\u003C/h3>\n\u003Cp>Testing takes like 90% of my time on every project. Making everything responsive is hard and the browser space is fragmented and it has led me to some interesting browser specific bugs that have stumped the LLMs. ngl, it’s feels great to solve them and I can do that because I understand a bit of web technology.\u003C/p>\n\u003Cp>Another thing I wish I did more of is \u003Cem>evals\u003C/em>. Evals helps me when I don’t understand the code that is being written. I get another agent to review one agent’s work. I consider it to be like a design critique or code review. To manage complex projects and usage limits, I keep a memory.md, agents.md and claude.md files to help with this back and forth.\u003C/p>\n\u003Cfigure class=\"image-figure\">\u003Cimg __ASTRO_IMAGE_=\"{"src":"./variant.png","alt":"How variant helped me improve the visual style of Dominic, a AI based Figma Plugin","index":0}\">\u003Cfigcaption>How variant helped me improve the visual style of Dominic, a AI based Figma Plugin\u003C/figcaption>\u003C/figure>\n\u003Ch3 id=\"llm-based-tools-i-currently-use\">LLM based tools I currently use:\u003C/h3>\n\u003Cul>\n\u003Cli>\u003Cstrong>Claude:\u003C/strong> Bulk to work done on Sonnet + API\u003C/li>\n\u003Cli>\u003Cstrong>Codex (Free):\u003C/strong> Mainly for evals and bug fixes\u003C/li>\n\u003Cli>\u003Cstrong>ChatGPT:\u003C/strong> Prompt definition, Image gen, API\u003C/li>\n\u003Cli>\u003Cstrong>Gemini:\u003C/strong> ImageGen, Deep Research and Prompt definition\u003C/li>\n\u003Cli>\u003Cstrong>Variant.com:\u003C/strong> Amazing for a functional minded designer like me, not sure how long they can survive though.\u003C/li>\n\u003C/ul>\n\u003Cp>—\u003C/p>\n\u003Cp>\u003Cem>If you are non-technical and want to learn how to to use AI to build, you can check out my free guide at \u003Ca href=\"howtoaicode.com\">howtoaicode.com\u003C/a>\u003C/em>\u003C/p>",{"headings":581,"localImagePaths":597,"remoteImagePaths":598,"frontmatter":599,"imagePaths":601},[582,585,588,591,594],{"depth":44,"slug":583,"text":584},"measure-twice-cut-once","Measure twice, cut once",{"depth":44,"slug":586,"text":587},"ready-set-up-go","Ready, Set up, Go",{"depth":44,"slug":589,"text":590},"rinse-and-repeat","Rinse and Repeat",{"depth":44,"slug":592,"text":593},"tests-evals--","Tests, Evals… 🚀",{"depth":44,"slug":595,"text":596},"llm-based-tools-i-currently-use","LLM based tools I currently use:",[574,575],[],{"title":567,"description":568,"date":600,"status":19,"image":576},["Date","2026-05-21T00:00:00.000Z"],[574,575],"long-live-design-process",{"id":602,"data":604,"body":609,"filePath":610,"assetImports":611,"digest":615,"rendered":616},{"title":605,"description":606,"date":607,"image":608,"status":19},"The design process is dead, long live the design process","I’ve been building with AI for the past few months and I dont think the design process is dead.",["Date","2026-03-02T00:00:00.000Z"],"__ASTRO_IMAGE_./rip-design-process.png","Over the last couple of decades, people have tried to tame and commoditize the design process into a neat package especially in the software startup world.\n\nThis in-turn had led to designer portfolios filled with a [templatic story](https://essays.uxdesign.cc/case-study-factory/) of research, personas, wireframes and final output[^1]. A predictable sequence manufactured (often in retrospect) to appease the hiring manager gods.\n\nThe design process was never about following a linear sequence. It wasn't about the artifacts or the rituals. It was just easy to market it as such.\n\n![The Design Sprint tried to emphasise on the Learn and Repeat Loop, but failed. Image source: Wikipedia](Design_Sprints.png)\n\nThe real design process was about making, testing, failing and learning – all in the quest for a better human centric product. It's far easier to build products and features by targeting \"low hanging fruits\", looking at what the competitors are doing, or favouring your CEO's bias. Much easier than going out to talk to your users, dissect your product’s data and figure out what you really need to build. After all, the cost of bad product decisions is only visible in hindsight, while the cost of user research is visible upfront. \n\nBut when you are building products for users who aren’t like you, there is no replacement for the process. \n\n![Speaking to Farmers to understand their decision making when it comes to selling their harvests](jivalite-ground.png)\n\nAt Jiva.ag, we were building for rural Indonesia. Our users weren’t digital natives but often humans with limited technical literacy. We couldn’t really design products and systems for them sitting in our AC offices. We needed to spend time with them – mapping their world and understanding their ways. We tested with scrappy prototypes, iterating upon and validating ideas until we sat down to build. That’s how we understood how our customers used the internet, how they made decisions, and what mattered to them.\n\nYes, AI can help close the loop faster. But without a process, we would have designed for ourselves and not our users.\n\n\n[^1]: or beautiful dribbble UI or excessive animations that would frustrate the average user\n[^2]: \"Design fixation is a well-documented cognitive bias where a designer becomes stuck on a limited set of ideas, often influenced by prior knowledge, previous solutions, or dominant trends,\" explains design psychology expert Rachel A. Wood. [More here](https://www.livingetc.com/advice/what-is-design-fixation).\n[^3]: Cover image courtesy: [The Double Diamond from the Design Council UK](https://www.designcouncil.org.uk/our-resources/the-double-diamond/)\n[^4]: Design Sprint image: [Courtesy Wikipedia](https://en.wikipedia.org/wiki/Design_sprint).","src/content/writing/long-live-design-process/index.md",[612,613,614],"Design_Sprints.png","jivalite-ground.png","./rip-design-process.png","cbf44d98c7ff9968",{"html":617,"metadata":618},"\u003Cp>Over the last couple of decades, people have tried to tame and commoditize the design process into a neat package especially in the software startup world.\u003C/p>\n\u003Cp>This in-turn had led to designer portfolios filled with a \u003Ca href=\"https://essays.uxdesign.cc/case-study-factory/\">templatic story\u003C/a> of research, personas, wireframes and final output\u003Csup>\u003Ca href=\"#user-content-fn-1\" id=\"user-content-fnref-1\" data-footnote-ref=\"\" aria-describedby=\"footnote-label\">1\u003C/a>\u003C/sup>. A predictable sequence manufactured (often in retrospect) to appease the hiring manager gods.\u003C/p>\n\u003Cp>The design process was never about following a linear sequence. It wasn’t about the artifacts or the rituals. It was just easy to market it as such.\u003C/p>\n\u003Cfigure class=\"image-figure\">\u003Cimg __ASTRO_IMAGE_=\"{"src":"Design_Sprints.png","alt":"The Design Sprint tried to emphasise on the Learn and Repeat Loop, but failed. Image source: Wikipedia","index":0}\">\u003Cfigcaption>The Design Sprint tried to emphasise on the Learn and Repeat Loop, but failed. Image source: Wikipedia\u003C/figcaption>\u003C/figure>\n\u003Cp>The real design process was about making, testing, failing and learning – all in the quest for a better human centric product. It’s far easier to build products and features by targeting “low hanging fruits”, looking at what the competitors are doing, or favouring your CEO’s bias. Much easier than going out to talk to your users, dissect your product’s data and figure out what you really need to build. After all, the cost of bad product decisions is only visible in hindsight, while the cost of user research is visible upfront.\u003C/p>\n\u003Cp>But when you are building products for users who aren’t like you, there is no replacement for the process.\u003C/p>\n\u003Cfigure class=\"image-figure\">\u003Cimg __ASTRO_IMAGE_=\"{"src":"jivalite-ground.png","alt":"Speaking to Farmers to understand their decision making when it comes to selling their harvests","index":0}\">\u003Cfigcaption>Speaking to Farmers to understand their decision making when it comes to selling their harvests\u003C/figcaption>\u003C/figure>\n\u003Cp>At Jiva.ag, we were building for rural Indonesia. Our users weren’t digital natives but often humans with limited technical literacy. We couldn’t really design products and systems for them sitting in our AC offices. We needed to spend time with them – mapping their world and understanding their ways. We tested with scrappy prototypes, iterating upon and validating ideas until we sat down to build. That’s how we understood how our customers used the internet, how they made decisions, and what mattered to them.\u003C/p>\n\u003Cp>Yes, AI can help close the loop faster. But without a process, we would have designed for ourselves and not our users.\u003C/p>\n\u003Csection data-footnotes=\"\" class=\"footnotes\">\u003Ch2 class=\"sr-only\" id=\"footnote-label\">Footnotes\u003C/h2>\n\u003Col>\n\u003Cli id=\"user-content-fn-1\">\n\u003Cp>or beautiful dribbble UI or excessive animations that would frustrate the average user \u003Ca href=\"#user-content-fnref-1\" data-footnote-backref=\"\" aria-label=\"Back to reference 1\" class=\"data-footnote-backref\">↩\u003C/a>\u003C/p>\n\u003C/li>\n\u003C/ol>\n\u003C/section>",{"headings":619,"localImagePaths":621,"remoteImagePaths":622,"frontmatter":623,"imagePaths":625},[620],{"depth":37,"slug":85,"text":86},[612,613],[],{"title":605,"description":606,"date":624,"status":19,"image":614},["Date","2026-03-02T00:00:00.000Z"],[612,613],"process",{"id":626,"data":628,"body":633,"filePath":634,"assetImports":635,"digest":637,"rendered":638},{"title":629,"description":630,"date":631,"image":632,"status":19},"Beyond building processes at GoMerchant Design Team","Team process and documentation",["Date","2021-08-19T00:00:00.000Z"],"__ASTRO_IMAGE_./process-1.png","A considerable amount of time in 'Year 1' of being a manager has been about setting up artifacts and processes. I was lucky to be part of an organization that had a documentation culture in its DNA. This was partly because we had Program Managers embedded within each team. This meant that Jira, Confluence and Asana were setup and maintained religiously, with weekly feature spec reviews [FSR] and ProdTech meetings to keep these upto date.\n\n#### Setting up Documentation spaces\n\nI find design documentation to be a critical part of the design process. I recommend every designer takes the time to document the project because apart from being a design artifact, that serves as a single point of truth, it also helps them when they have to write their performance reviews, promotion proposals and build their portfolio.\n\nI do not like Google Docs for documentation. Documentation spaces need to be a searchable wiki and ironically Google Docs is poor at providing this. At Practo, we already had Atlassian's Confluence setup when I joined, and at Gojek, Maji setup our Confluence spaces in 2019 and then the two of us started structuring and documenting our knowledge about the product and its processes. I created a design documentation template based on the product feature spec template and advocated for it.\n\nAs for project management, the org moved to using Asana. Adding them here felt forced and an unnecessary addition to our workload. However as our product roadmap was moved into Asana, I devised a process to make design tasks a visible part of the product development process by adding them as subtasks and duplicating them to our design boards for effective tracking. Post every prioritization meeting, I added tasks into the todo list and tagged designers so that they were aware of what's coming up.\n\nHowever, we faced a problem with adoption of these processes. We lacked a program manager dedicated to design and not all designers in the team were able to keep their boards updated. We were able to setup a biweekly cadence with the program management VP, Gifika, to discuss our problems and understand how we can get better at solving them. And what we learned is two things.\n\n1. Add more meetings in the calendar\n2. Be a bad cop\n\n#### More meetings in the calendar\n\nWhen your calendar is already full of meetings, you feel like staying away from setting up any more that will take away whatever little 'time for focus work' that is left in it. But given our problem, this seemed to be the most effective way to get things working.\nOur team was a 3 level hierarchy so each lead now had to setup two additional cadences into their calendar. One was a common stream leads cadence where each stream lead would come prepared to the biweekly meeting with a progress update (which would be posted biweekly to the Asana board) Maji worked on a template for this.\n\nThe other meeting was with their stream where each of their reports could come with a similarly formatted update. This meeting helped stream leads prepare them for the stream leads meeting.\nYou can also make these meetings async if everyone is diligent. The updates were a small part of the biweekly leads meeting.\n\n#### Be a Bad Cop\n\nNot all designers like following process. They may see it as additional work with low ROI or they may just not have enough time. You should take the time to communicate the problems that the process is going to solve and ask them for feedback on the process. Make it feel like they co-own the process. But if this fails, then you should be okay with being \"bad cop\". This would mean that you would need to set Slack reminders, add calendar invites and send DMs if everything fails. This is the way.","src/content/writing/process/index.md",[636],"./process-1.png","91f652859cba28a2",{"html":639,"metadata":640},"\u003Cp>A considerable amount of time in ‘Year 1’ of being a manager has been about setting up artifacts and processes. I was lucky to be part of an organization that had a documentation culture in its DNA. This was partly because we had Program Managers embedded within each team. This meant that Jira, Confluence and Asana were setup and maintained religiously, with weekly feature spec reviews [FSR] and ProdTech meetings to keep these upto date.\u003C/p>\n\u003Ch4 id=\"setting-up-documentation-spaces\">Setting up Documentation spaces\u003C/h4>\n\u003Cp>I find design documentation to be a critical part of the design process. I recommend every designer takes the time to document the project because apart from being a design artifact, that serves as a single point of truth, it also helps them when they have to write their performance reviews, promotion proposals and build their portfolio.\u003C/p>\n\u003Cp>I do not like Google Docs for documentation. Documentation spaces need to be a searchable wiki and ironically Google Docs is poor at providing this. At Practo, we already had Atlassian’s Confluence setup when I joined, and at Gojek, Maji setup our Confluence spaces in 2019 and then the two of us started structuring and documenting our knowledge about the product and its processes. I created a design documentation template based on the product feature spec template and advocated for it.\u003C/p>\n\u003Cp>As for project management, the org moved to using Asana. Adding them here felt forced and an unnecessary addition to our workload. However as our product roadmap was moved into Asana, I devised a process to make design tasks a visible part of the product development process by adding them as subtasks and duplicating them to our design boards for effective tracking. Post every prioritization meeting, I added tasks into the todo list and tagged designers so that they were aware of what’s coming up.\u003C/p>\n\u003Cp>However, we faced a problem with adoption of these processes. We lacked a program manager dedicated to design and not all designers in the team were able to keep their boards updated. We were able to setup a biweekly cadence with the program management VP, Gifika, to discuss our problems and understand how we can get better at solving them. And what we learned is two things.\u003C/p>\n\u003Col>\n\u003Cli>Add more meetings in the calendar\u003C/li>\n\u003Cli>Be a bad cop\u003C/li>\n\u003C/ol>\n\u003Ch4 id=\"more-meetings-in-the-calendar\">More meetings in the calendar\u003C/h4>\n\u003Cp>When your calendar is already full of meetings, you feel like staying away from setting up any more that will take away whatever little ‘time for focus work’ that is left in it. But given our problem, this seemed to be the most effective way to get things working.\nOur team was a 3 level hierarchy so each lead now had to setup two additional cadences into their calendar. One was a common stream leads cadence where each stream lead would come prepared to the biweekly meeting with a progress update (which would be posted biweekly to the Asana board) Maji worked on a template for this.\u003C/p>\n\u003Cp>The other meeting was with their stream where each of their reports could come with a similarly formatted update. This meeting helped stream leads prepare them for the stream leads meeting.\nYou can also make these meetings async if everyone is diligent. The updates were a small part of the biweekly leads meeting.\u003C/p>\n\u003Ch4 id=\"be-a-bad-cop\">Be a Bad Cop\u003C/h4>\n\u003Cp>Not all designers like following process. They may see it as additional work with low ROI or they may just not have enough time. You should take the time to communicate the problems that the process is going to solve and ask them for feedback on the process. Make it feel like they co-own the process. But if this fails, then you should be okay with being “bad cop”. This would mean that you would need to set Slack reminders, add calendar invites and send DMs if everything fails. This is the way.\u003C/p>",{"headings":641,"localImagePaths":651,"remoteImagePaths":652,"frontmatter":653,"imagePaths":654},[642,645,648],{"depth":57,"slug":643,"text":644},"setting-up-documentation-spaces","Setting up Documentation spaces",{"depth":57,"slug":646,"text":647},"more-meetings-in-the-calendar","More meetings in the calendar",{"depth":57,"slug":649,"text":650},"be-a-bad-cop","Be a Bad Cop",[],[],{"title":629,"description":630,"date":531,"image":636},[],"product-designer",{"id":655,"data":657,"body":662,"filePath":663,"assetImports":664,"digest":668,"rendered":669},{"title":658,"description":659,"date":660,"image":661,"status":19},"What is a product designer?","After a decade of designing products, I decided to make an attempt describing the role and qualities of a product designer",["Date","2025-01-01T00:00:00.000Z"],"__ASTRO_IMAGE_./squiggle-labels-outline.jpg","A decade ago, the 'product designer' title was being used to refer to designers (and still is) working on physical products. The adoption of using it for software designers got a shot in the arm when [Facebook adopted it](https://qr.ae/pGQdVi) for their designers. Until then UI/UX was the term of choice for folks in the industry and used to indicate a specific job that the designer performed in the team. This was indicative of the shift from the delivery teams working with client requirements (enterprise first) to product teams (rapidly iterating consumer tech) which had to learn and uncover what was the best product they could build. Due to the scarcity of product designers in the space, companies started acquiring design agencies around the world[^1].\n\nThe 'product designer' now had to start looking at what they are designing as a product and not be restricted by your traditional mindset of UI and UX responsibilities. This would mean that they would need to learn about business, uncover user insights, use data analytic tools, have technical understanding, etc to design their product. These aren't skills that come naturally to designers and therein lay the problem. Not every designer wanted to be a “product designer” but it was an aspirational job for designers given the pay packages were miles ahead of what designers were paid in other industries. More and more companies started adopting the term of ‘product designer’ to follow industry trends and attract talent.\n\nBut even then there were few orgs which took design seriously.\n\n![Source: 2014 interview in Dezeen](./product-designer-1.png)[^2]\n\nEven today, most orgs don’t really provide a space for designers to thrive in the product space and even today, there are probably a handful of product designers and product orgs in the world, the rest is mostly good PR.\n\n**And what are the aspects of a product designer that sets them apart from other designers?**\n\n### Quality\n\nThe primary aspect the product designer optimises for is quality of delivery. Quality being subjective makes it hard for the different disciplines to align over what this means. For me, it means that the product designer needs to understand the constraints of business and development to be able to deliver the best outcome possible in the defined timeline. You may want to build that perfect animated transition, but let’s be real, that’s not really a user need most of the time. The product’s usage and success should be the thing driving you towards excelling as a designer.\n\n![](./product-designer-2.jpg)\n\n### Curiosity\n\nJust like Alice, a product designer has to be inquisitive about their users and their behaviour and the systems they inhabit. The ‘product designer’ need to be comfortable looking at dashboards, analyzing events as well as drafting a research plan and talking to users. The best way to level up as a product designer is to learn from what you are building and putting out into the world. And this learning tends to compound as the years go by and helps you take decisions when faced with new design challenges.\n\n### Craft\n\nThe product designer is actually [T-shaped](https://spotify.design/article/finding-your-t-shape-as-a-generalist-designer) despite a lot of folks thinking that they are generalists. So although the industry largely refers to the visual polish as 'craft', I don't feel its restricted to just that. You could be a 'product designer' excelling at copy writing, or a 'product designer' inclined towards the code side. A good team is made of many such designers who can learn from each other. If every designer you hire (or in your team) has a similar skill set to you then there would be limited direction for you to grow in. Some teams out there have chosen to double down on this kind of team building but to me that's building a design specialist team.[^3]\n\n### Agency\n\nThis is a quality which is rare to find. I feel this is because most designers tend to be introverts and love to be comfortable in their “space”. It’s easy to spend time in the world making pixel perfection your entire personality, it’s not easy to go out on a limb and argue for a decision to be made. Unfortunately, agency is what helps you level up the ranks. Agency is what gets you a seat at the table. Another hurdle towards product designers developing agency is that they need to be part of good teams run by design leaders who support and sponsor you and those are really scarce in supply.\n\n### So where do we go from here?\n\n* I see that we need to address this at a system level, today the ‘product design’ comes with a better salary and so for designers to get better pay it’s better to call themselves Product Designers. So things can’t change until the hiring parties don’t get better at their jobs.\n\n* No one designer is the same as the other. Organisations should be cognizant that there are no such thing as generalists and design their career rubrics in a way to suit the different kinds of designers on their team. This helps each designer to grow in their own way within the org.\n\n* Job descriptions could be honest up front of the kind of designer that they are looking for rather than getting ChatGPT to write it. There is no point lying about this, infact it just takes you lot longer to find someone.\n\n\n[^1]: **John Maeda's Design in Tech report 2015, Slide 4** https://www.slideshare.net/slideshow/design-in-tech-report-2015-45858974/45858974\n\n[^2]: **Silicon Valley \"didn't think a designer could build a company\" says Airbnb co-founder Brian Chesky** https://www.dezeen.com/2014/01/28/silicon-valley-didnt-think-a-designer-could-build-a-company-interview-airbnb-co-founder-brian-chesky/\n\n[^3]: **Pablo Stanley, Collection of Random Comics** https://thedesignteam.io/collection-of-random-comics-d66f32ee9c52\n\n\n\u003Cp class=\"attribution\"> This post was my response to Sidu's \u003Ca href=\"https://sidu.in/essays/hiring-product-managers.html\">Hiring Product Managers\u003C/a> and John Allspaw's \u003Ca href=\"https://www.kitchensoap.com/2012/10/25/on-being-a-senior-engineer/\">On being a Senior Engineer\u003C/a>.\u003C/p>\n\u003Cp class=\"attribution\"> Attribution: Cover image courtesy \u003Cstrong>'The Process of Design Squiggle' by Damien Newman, thedesignsquiggle.com\u003C/strong> \u003C/p>","src/content/writing/product-designer/index.md",[665,666,667],"./product-designer-1.png","./product-designer-2.jpg","./squiggle-labels-outline.jpg","595da99918ce871b",{"html":670,"metadata":671},"\u003Cp>A decade ago, the ‘product designer’ title was being used to refer to designers (and still is) working on physical products. The adoption of using it for software designers got a shot in the arm when \u003Ca href=\"https://qr.ae/pGQdVi\">Facebook adopted it\u003C/a> for their designers. Until then UI/UX was the term of choice for folks in the industry and used to indicate a specific job that the designer performed in the team. This was indicative of the shift from the delivery teams working with client requirements (enterprise first) to product teams (rapidly iterating consumer tech) which had to learn and uncover what was the best product they could build. Due to the scarcity of product designers in the space, companies started acquiring design agencies around the world\u003Csup>\u003Ca href=\"#user-content-fn-1\" id=\"user-content-fnref-1\" data-footnote-ref=\"\" aria-describedby=\"footnote-label\">1\u003C/a>\u003C/sup>.\u003C/p>\n\u003Cp>The ‘product designer’ now had to start looking at what they are designing as a product and not be restricted by your traditional mindset of UI and UX responsibilities. This would mean that they would need to learn about business, uncover user insights, use data analytic tools, have technical understanding, etc to design their product. These aren’t skills that come naturally to designers and therein lay the problem. Not every designer wanted to be a “product designer” but it was an aspirational job for designers given the pay packages were miles ahead of what designers were paid in other industries. More and more companies started adopting the term of ‘product designer’ to follow industry trends and attract talent.\u003C/p>\n\u003Cp>But even then there were few orgs which took design seriously.\u003C/p>\n\u003Cfigure class=\"image-figure\">\u003Cimg __ASTRO_IMAGE_=\"{"src":"./product-designer-1.png","alt":"Source: 2014 interview in Dezeen","index":0}\">\u003Cfigcaption>Source: 2014 interview in Dezeen\u003C/figcaption>\u003C/figure>\n\u003Cp>Even today, most orgs don’t really provide a space for designers to thrive in the product space and even today, there are probably a handful of product designers and product orgs in the world, the rest is mostly good PR.\u003C/p>\n\u003Cp>\u003Cstrong>And what are the aspects of a product designer that sets them apart from other designers?\u003C/strong>\u003C/p>\n\u003Ch3 id=\"quality\">Quality\u003C/h3>\n\u003Cp>The primary aspect the product designer optimises for is quality of delivery. Quality being subjective makes it hard for the different disciplines to align over what this means. For me, it means that the product designer needs to understand the constraints of business and development to be able to deliver the best outcome possible in the defined timeline. You may want to build that perfect animated transition, but let’s be real, that’s not really a user need most of the time. The product’s usage and success should be the thing driving you towards excelling as a designer.\u003C/p>\n\u003Cfigure class=\"image-figure\">\u003Cimg __ASTRO_IMAGE_=\"{"src":"./product-designer-2.jpg","alt":"","index":0}\">\u003C/figure>\n\u003Ch3 id=\"curiosity\">Curiosity\u003C/h3>\n\u003Cp>Just like Alice, a product designer has to be inquisitive about their users and their behaviour and the systems they inhabit. The ‘product designer’ need to be comfortable looking at dashboards, analyzing events as well as drafting a research plan and talking to users. The best way to level up as a product designer is to learn from what you are building and putting out into the world. And this learning tends to compound as the years go by and helps you take decisions when faced with new design challenges.\u003C/p>\n\u003Ch3 id=\"craft\">Craft\u003C/h3>\n\u003Cp>The product designer is actually \u003Ca href=\"https://spotify.design/article/finding-your-t-shape-as-a-generalist-designer\">T-shaped\u003C/a> despite a lot of folks thinking that they are generalists. So although the industry largely refers to the visual polish as ‘craft’, I don’t feel its restricted to just that. You could be a ‘product designer’ excelling at copy writing, or a ‘product designer’ inclined towards the code side. A good team is made of many such designers who can learn from each other. If every designer you hire (or in your team) has a similar skill set to you then there would be limited direction for you to grow in. Some teams out there have chosen to double down on this kind of team building but to me that’s building a design specialist team.\u003Csup>\u003Ca href=\"#user-content-fn-3\" id=\"user-content-fnref-3\" data-footnote-ref=\"\" aria-describedby=\"footnote-label\">3\u003C/a>\u003C/sup>\u003C/p>\n\u003Ch3 id=\"agency\">Agency\u003C/h3>\n\u003Cp>This is a quality which is rare to find. I feel this is because most designers tend to be introverts and love to be comfortable in their “space”. It’s easy to spend time in the world making pixel perfection your entire personality, it’s not easy to go out on a limb and argue for a decision to be made. Unfortunately, agency is what helps you level up the ranks. Agency is what gets you a seat at the table. Another hurdle towards product designers developing agency is that they need to be part of good teams run by design leaders who support and sponsor you and those are really scarce in supply.\u003C/p>\n\u003Ch3 id=\"so-where-do-we-go-from-here\">So where do we go from here?\u003C/h3>\n\u003Cul>\n\u003Cli>\n\u003Cp>I see that we need to address this at a system level, today the ‘product design’ comes with a better salary and so for designers to get better pay it’s better to call themselves Product Designers. So things can’t change until the hiring parties don’t get better at their jobs.\u003C/p>\n\u003C/li>\n\u003Cli>\n\u003Cp>No one designer is the same as the other. Organisations should be cognizant that there are no such thing as generalists and design their career rubrics in a way to suit the different kinds of designers on their team. This helps each designer to grow in their own way within the org.\u003C/p>\n\u003C/li>\n\u003Cli>\n\u003Cp>Job descriptions could be honest up front of the kind of designer that they are looking for rather than getting ChatGPT to write it. There is no point lying about this, infact it just takes you lot longer to find someone.\u003C/p>\n\u003C/li>\n\u003C/ul>\n\u003Cp class=\"attribution\"> This post was my response to Sidu's \u003Ca href=\"https://sidu.in/essays/hiring-product-managers.html\">Hiring Product Managers\u003C/a> and John Allspaw's \u003Ca href=\"https://www.kitchensoap.com/2012/10/25/on-being-a-senior-engineer/\">On being a Senior Engineer\u003C/a>.\u003C/p>\n\u003Cp class=\"attribution\"> Attribution: Cover image courtesy \u003Cstrong>'The Process of Design Squiggle' by Damien Newman, thedesignsquiggle.com\u003C/strong> \u003C/p>\n\u003Csection data-footnotes=\"\" class=\"footnotes\">\u003Ch2 class=\"sr-only\" id=\"footnote-label\">Footnotes\u003C/h2>\n\u003Col>\n\u003Cli id=\"user-content-fn-1\">\n\u003Cp>\u003Cstrong>John Maeda’s Design in Tech report 2015, Slide 4\u003C/strong> \u003Ca href=\"https://www.slideshare.net/slideshow/design-in-tech-report-2015-45858974/45858974\">https://www.slideshare.net/slideshow/design-in-tech-report-2015-45858974/45858974\u003C/a> \u003Ca href=\"#user-content-fnref-1\" data-footnote-backref=\"\" aria-label=\"Back to reference 1\" class=\"data-footnote-backref\">↩\u003C/a>\u003C/p>\n\u003C/li>\n\u003Cli id=\"user-content-fn-2\">\n\u003Cp>\u003Cstrong>Silicon Valley “didn’t think a designer could build a company” says Airbnb co-founder Brian Chesky\u003C/strong> \u003Ca href=\"https://www.dezeen.com/2014/01/28/silicon-valley-didnt-think-a-designer-could-build-a-company-interview-airbnb-co-founder-brian-chesky/\">https://www.dezeen.com/2014/01/28/silicon-valley-didnt-think-a-designer-could-build-a-company-interview-airbnb-co-founder-brian-chesky/\u003C/a> \u003Ca href=\"#user-content-fnref-2\" data-footnote-backref=\"\" aria-label=\"Back to reference 2\" class=\"data-footnote-backref\">↩\u003C/a>\u003C/p>\n\u003C/li>\n\u003Cli id=\"user-content-fn-3\">\n\u003Cp>\u003Cstrong>Pablo Stanley, Collection of Random Comics\u003C/strong> \u003Ca href=\"https://thedesignteam.io/collection-of-random-comics-d66f32ee9c52\">https://thedesignteam.io/collection-of-random-comics-d66f32ee9c52\u003C/a> \u003Ca href=\"#user-content-fnref-3\" data-footnote-backref=\"\" aria-label=\"Back to reference 3\" class=\"data-footnote-backref\">↩\u003C/a>\u003C/p>\n\u003C/li>\n\u003C/ol>\n\u003C/section>",{"headings":672,"localImagePaths":689,"remoteImagePaths":690,"frontmatter":691,"imagePaths":693},[673,676,679,682,685,688],{"depth":44,"slug":674,"text":675},"quality","Quality",{"depth":44,"slug":677,"text":678},"curiosity","Curiosity",{"depth":44,"slug":680,"text":681},"craft","Craft",{"depth":44,"slug":683,"text":684},"agency","Agency",{"depth":44,"slug":686,"text":687},"so-where-do-we-go-from-here","So where do we go from here?",{"depth":37,"slug":85,"text":86},[665,666],[],{"title":658,"description":659,"date":692,"image":667},"2025-01-01",[665,666],"rituals",{"id":694,"data":696,"body":701,"filePath":702,"assetImports":703,"digest":705,"rendered":706},{"title":697,"description":698,"date":699,"image":700,"status":19},"Team rituals and culture of the GoMerchant Design Team","Three meetings that helped us work remote and stay sane during the COVID pandemic",["Date","2021-08-19T00:00:00.000Z"],"__ASTRO_IMAGE_./zoom.png","As the GoMerchant team grew, processes and rituals became very important.\n\n### 1. Design Critiques\nDesign Critiques were the first one we instituted. This was a weekly design and research only session where designers could present their work to other designers.\nThese would be weekly and designers were encouraged to show work in progress. To setup this session as a safe space, leaders were expected to be vulnerable and lead by showing their own work in progress.\n\n### 2. Design Review\nWith a need to showcase our work and drive alignment with non-design stakeholders, we setup a Design Review.\nThe format of the design review was formal compared to our informal design critique. \nWe invited non-design stakeholders to the review so that the feedback we collect could flow back into the design process. This was done weekly if required but usually as per our product development cycle it was bi-weekly.\n\n### 3. Design Standup (for lack of a better term)\nI used to be the only designer on my team based in India, but until the lockdown I did not think about instituting any daily standups.\nI used to frequently travel to Indonesia and everyone else was based in the same office. I felt that was enough.\nBut when the pandemic hit and the designers started being isolated in their houses, Maji and I decided to setup a daily cooler talk. We called it _Design Standup_ but we didn't want it to be a 'standup'.\nWe encouraged folks to talk about their personal life, what they were going through and what they were doing.\nWe played games, drew murals together on digital whiteboards and went down internet rabbit holes. Attendance was never compulsory, you could join in if you felt like it. We always posted the link and created a thread of what we discussed on our channel so that if you missed out, you could still follow what was discussed.\nThis ritual couldn't have been achieved without the team members especially Maji, Lauditta and Aryo driving the conversations.\n\nI wonder if this is replicable or was I lucky to have this wonderful team…","src/content/writing/rituals/index.md",[704],"./zoom.png","1249e6497e2be7b7",{"html":707,"metadata":708},"\u003Cp>As the GoMerchant team grew, processes and rituals became very important.\u003C/p>\n\u003Ch3 id=\"1-design-critiques\">1. Design Critiques\u003C/h3>\n\u003Cp>Design Critiques were the first one we instituted. This was a weekly design and research only session where designers could present their work to other designers.\nThese would be weekly and designers were encouraged to show work in progress. To setup this session as a safe space, leaders were expected to be vulnerable and lead by showing their own work in progress.\u003C/p>\n\u003Ch3 id=\"2-design-review\">2. Design Review\u003C/h3>\n\u003Cp>With a need to showcase our work and drive alignment with non-design stakeholders, we setup a Design Review.\nThe format of the design review was formal compared to our informal design critique.\nWe invited non-design stakeholders to the review so that the feedback we collect could flow back into the design process. This was done weekly if required but usually as per our product development cycle it was bi-weekly.\u003C/p>\n\u003Ch3 id=\"3-design-standup-for-lack-of-a-better-term\">3. Design Standup (for lack of a better term)\u003C/h3>\n\u003Cp>I used to be the only designer on my team based in India, but until the lockdown I did not think about instituting any daily standups.\nI used to frequently travel to Indonesia and everyone else was based in the same office. I felt that was enough.\nBut when the pandemic hit and the designers started being isolated in their houses, Maji and I decided to setup a daily cooler talk. We called it \u003Cem>Design Standup\u003C/em> but we didn’t want it to be a ‘standup’.\nWe encouraged folks to talk about their personal life, what they were going through and what they were doing.\nWe played games, drew murals together on digital whiteboards and went down internet rabbit holes. Attendance was never compulsory, you could join in if you felt like it. We always posted the link and created a thread of what we discussed on our channel so that if you missed out, you could still follow what was discussed.\nThis ritual couldn’t have been achieved without the team members especially Maji, Lauditta and Aryo driving the conversations.\u003C/p>\n\u003Cp>I wonder if this is replicable or was I lucky to have this wonderful team…\u003C/p>",{"headings":709,"localImagePaths":719,"remoteImagePaths":720,"frontmatter":721,"imagePaths":722},[710,713,716],{"depth":44,"slug":711,"text":712},"1-design-critiques","1. Design Critiques",{"depth":44,"slug":714,"text":715},"2-design-review","2. Design Review",{"depth":44,"slug":717,"text":718},"3-design-standup-for-lack-of-a-better-term","3. Design Standup (for lack of a better term)",[],[],{"title":697,"description":698,"date":531,"image":704},[],"solo-designer",{"id":723,"data":725,"body":730,"filePath":731,"assetImports":732,"digest":734,"rendered":735},{"title":726,"description":727,"date":728,"image":729,"status":19},"Evaluating that Solo Designer job","What to look for when joining a startup as the solo designer",["Date","2024-02-12T00:00:00.000Z"],"__ASTRO_IMAGE_./solo-designer-jobs-1.png","You often see people stating that they are joining as a solo designer in a Startup and want advice. Them being the solo designer shouldn’t directly impact their effectiveness.\n\nHere’s what I feel matters the most towards their success:\n\n### 1. What is your role?\n\nKnowing why they opened the designer role is important before you take that job. I recommend that you ask the hiring manager this question during your interview rounds and also ask to speak to the critical members in the team you will be joining. I take it that most Founders open a position because they got some feedback from customers or because their investor told them to. They may not be ready to invest in what can make a designer effective in their role.\n\n### 2. Fitting into the team:\n\nThe team would need to adapt to having an in-house designer working with them. The team members would need to understand what the role of the designer is and how they could work with them. They would need to take time to adapt their workflows or create new inclusive processes. All this is hard to do and the designer(especially a junior one) wouldn’t do very well without a sponsor.\n\n### 3. You need a sponsor.\n\nOne of my key learnings has been to choose to work with someone who will be your advocate in the organization. It's the single most important thing to look for during the interview process. The best teams I've observed had CEOs being the design sponsor and their products tend to win at least in terms of product quality (a product's success is more than it's quality, but that's another post) Don't believe me? Well in *Rams*, Dieter Rams states \"If you don't have someone who stands behind you, then you can forget it.\" And cites it as a reason for leaving Braun.\n\nOf course, not every Startup out there succeeds and there's no guarantee that the team you join will survive but its always good to make sure that you enjoy the team you spend there and learn how to become a better designer.\n\nIf you are looking for advice on what you can do as a solo designer to succeed, [this post I wrote after my first year as a designer](https://medium.com/user-experience-design-1/what-every-young-designer-should-know-abb2af79f43e) may be useful.","src/content/writing/solo-designer/index.md",[733],"./solo-designer-jobs-1.png","134f374691447467",{"html":736,"metadata":737},"\u003Cp>You often see people stating that they are joining as a solo designer in a Startup and want advice. Them being the solo designer shouldn’t directly impact their effectiveness.\u003C/p>\n\u003Cp>Here’s what I feel matters the most towards their success:\u003C/p>\n\u003Ch3 id=\"1-what-is-your-role\">1. What is your role?\u003C/h3>\n\u003Cp>Knowing why they opened the designer role is important before you take that job. I recommend that you ask the hiring manager this question during your interview rounds and also ask to speak to the critical members in the team you will be joining. I take it that most Founders open a position because they got some feedback from customers or because their investor told them to. They may not be ready to invest in what can make a designer effective in their role.\u003C/p>\n\u003Ch3 id=\"2-fitting-into-the-team\">2. Fitting into the team:\u003C/h3>\n\u003Cp>The team would need to adapt to having an in-house designer working with them. The team members would need to understand what the role of the designer is and how they could work with them. They would need to take time to adapt their workflows or create new inclusive processes. All this is hard to do and the designer(especially a junior one) wouldn’t do very well without a sponsor.\u003C/p>\n\u003Ch3 id=\"3-you-need-a-sponsor\">3. You need a sponsor.\u003C/h3>\n\u003Cp>One of my key learnings has been to choose to work with someone who will be your advocate in the organization. It’s the single most important thing to look for during the interview process. The best teams I’ve observed had CEOs being the design sponsor and their products tend to win at least in terms of product quality (a product’s success is more than it’s quality, but that’s another post) Don’t believe me? Well in \u003Cem>Rams\u003C/em>, Dieter Rams states “If you don’t have someone who stands behind you, then you can forget it.” And cites it as a reason for leaving Braun.\u003C/p>\n\u003Cp>Of course, not every Startup out there succeeds and there’s no guarantee that the team you join will survive but its always good to make sure that you enjoy the team you spend there and learn how to become a better designer.\u003C/p>\n\u003Cp>If you are looking for advice on what you can do as a solo designer to succeed, \u003Ca href=\"https://medium.com/user-experience-design-1/what-every-young-designer-should-know-abb2af79f43e\">this post I wrote after my first year as a designer\u003C/a> may be useful.\u003C/p>",{"headings":738,"localImagePaths":748,"remoteImagePaths":749,"frontmatter":750,"imagePaths":752},[739,742,745],{"depth":44,"slug":740,"text":741},"1-what-is-your-role","1. What is your role?",{"depth":44,"slug":743,"text":744},"2-fitting-into-the-team","2. Fitting into the team:",{"depth":44,"slug":746,"text":747},"3-you-need-a-sponsor","3. You need a sponsor.",[],[],{"title":726,"description":727,"date":751,"image":733},"2024-02-12",[],"toko-poster",{"id":753,"data":755,"body":760,"filePath":761,"assetImports":762,"digest":764,"rendered":765},{"title":756,"description":757,"date":758,"image":759,"status":99},"Midjourneying through Indonesia","this is a description",["Date","2026-03-02T00:00:00.000Z"],"__ASTRO_IMAGE_","hello","src/content/writing/toko-poster/index.md",[763],"","917943514e073f56",{"html":766,"metadata":767},"\u003Cp>hello\u003C/p>",{"headings":768,"localImagePaths":769,"remoteImagePaths":770,"frontmatter":771,"imagePaths":773},[],[],[],{"title":756,"description":757,"date":772,"status":99,"image":763},["Date","2026-03-02T00:00:00.000Z"],[],"vibe-coding",{"id":774,"data":776,"body":781,"filePath":782,"assetImports":783,"digest":791,"rendered":792},{"title":777,"description":778,"date":779,"image":780,"status":19},"Through the vibe-coding looking glass","or How I stopped procrastinating and started to love vibe-coding",["Date","2025-12-22T00:00:00.000Z"],"__ASTRO_IMAGE_./git25.png","\u003Cdiv class=\"note\">Disclaimer: I had a shortlived career as a front end dev (IE7 era) at TCS when I began my career post-engineering in 2010, so I am familiar with the basics of web development. Hence vibe-coding on web may be slightly easier for me to grok then someone non-technical who is trying it out.\u003C/div>\n\nIn October, when I started off my break, I wanted to explore vibe coding but the choices are overwhelming. Up till then, my exposure to LLMs had been to use ChatGPT to edit blog posts and using Midjourney for creating assets for Meta Ads and VC pitch decks. Attending Razorpay’s Design x AI in November helped me understand the realities of vibe coding and prompting but I needed an extra push.\n\nThat push came in the form of a relative asking me to review their 'Vietnam Travel Itinerary'. They had shared their 'Itinerary as a huge wall of text pasted on Whatsapp. I could figure out a few obvious issues with it but I decided to see if AI can help me review and visualize the issues instead. I felt this would help me communicate the issues easier with my relative.\n\nPlanning holidays and building itineraries is a hobby of mine, so I had tried ChatGPT earlier to help with trip planning but I had found it lacking. It was great at generating rough to-dos for your trip like places to visit, etc which I believe it has adequate training data on and to be fair, it’s great for a normie. However, it fails miserably in many places like recommending good stays and other kinds of specialized interests and I've also observed that it tends to think about planning in terms of a western or american perspective. \n\nSo I started asking ChatGPT to visualize the itinerary on maps and when it created an html artifact, I asked it to iterated on the design and visuals. But there was a lot of back and forth to get something done and often subsequent generations rolled back changes I had made. Below are couple of variations of my iterations, ([left](/vibe-coding/iterations/vietnam_12_day_itinerary_web.html)) from when I started to ([right](/vibe-coding/iterations/Vietnam_12Day_Itinerary.html)) when I decided to get it to make it swiss-inspired.\n\n\u003Cdiv class=\"impact-images\" style=\"display: grid; grid-template-columns: 1fr 1fr; gap: 1rem;\">\n\n![](./chatgpt-v1.png)\n\n![](./chatgpt-final.png)\n\n\u003C/div>\n\nI hit chatGPT's session limit and decided to move it to Claude. That's when it got easier. Claude's execution of my requests were better. You could see an invisible multiplier in place such that a 1x simple prompt gave a [10x output](/vibe-coding/iterations/vietnam_itinerary.html). \n\n![My input was the chatGPT html](./claude-v1.png)\n\nThat piqued my curiousity, I decided to see how far I could go.\n\nI first asked Claude what it would take to \"productivize this\" and it gave me a very detailed product roadmap of everything possible including the kitchen sink. It was overwhelming, but I made me learn that asking Claude for a plan is a good way to source ideas but better to work through the designs in the traditional way of implementation (prototype > iterate, repeat)\n\n![Version 1 of Claude](v1-prototype.png)\n\nIt took me about 40 iterations[^1] to get to a state I was comfortable sharing with friends to get feedback. Claude walked me through the steps of setting up Claude API key and hosting the app on Netlify, something I've never done before. You can check out the project at [Traviti](https://traviti.netlify.app/).\n\n![My last iteration](67.png)\n\n#### Fun fact: \n1. When I moved the html to Claude, it removed the 'Made by ChatGPT' label in the markup. Jealousy?\n2. Claude struggled a lot to add it's own logo into the markup and I had to write the markup in the end.\n\nThis project gave me sort of confidence to build further. The itinerary generator was not what I would have wanted to build, but [Budgie](https://kenneth.dsouza.im/budgie/) was. The time to build Budgie was faster. I now had Claude Pro subscription and quickly hit the weekly limit and had to stop so the v1 of Budgie took a week longer than expected to ship. Update: I shipped an [updated version of Budgie](https://budgie.travel) over the Christmas holidays.\n\n\n![Final version of Budgie](budgie.png)\nThis was before Claude's release of Skills and I tried out using Projects for this. There was no Figma involved, just prompting and reading through CSS classes. There were some parts that I had to step into debug but largely this was coded by Claude.\n\nTowards the end of this project, I moved to Claude Code on web and the experience dramatically improved again. Having Claude as a partner to pair with and write to the same repo was amazing QoL improvement. \n\nAfter Budgie, I felt it was time to stop procrastinating and start working on my portfolio (this site). It had been previously built on Eleventy via Glitch (RIP) but I wanted to test how easy would it be to re-write this. So for this project, I asked Claude Code to review and then rebuild the site in Astro and I also provided designs I made in Figma. Claude was easily able to render it and since then, I've taken to making Figma mockups to move the designs along. \n\nMidway through this, I decided to try Claude code on desktop and found myself lost a couple of times, so I decided to move back to Claude code on web. (I do want to try Claude code on Desktop for a future project where I build from scratch.)\n\nSince then, I've tried my hands at [visualizing my book reading on P5js](https://kenneth.dsouza.im/books-2025/index.html) and tried to clean up [an old D3js assignment](https://kenneth.dsouza.im/visualizing-trains/) from a college module. \n\nHonestly, LLMs have been able to help me overcome the barriers I used to face with hobby side projects and I hope more people get empowered this way.\n\n### Helpful tips if you want to get started\n\n- Starting new chat is the new CTRL+S. I struggled a lot on regular chat conversation. Claude Code however generates a nice summary of the chat when you hit context limit.\n\n- Be ready to make a LOT of iteratons. Designing on Figma and providing images has been generally efficient to get the outcome you want. \n\n- Start with small projects; for me that means static web projects. Identify what it means for you. \n \n- I expect design hiring to have a vibe coding round in the near future. Being able to translate your designs to a real functioning prototype has never been easier and moreover it gives an insight into how the designer solves problems.\n\n- Setup a free Github account and connect Claude to it. This will help with your versioning and the ability to roll back any unexpected changes. I personally prefer Github desktop over terminal and if you are new, I suggest you try that.\n\n\n[^1]: At times, some of Claude's prompts generated multiple iterations so iteration 40 was more like 10 prompts into the conversation.","src/content/writing/vibe-coding/index.md",[784,785,786,787,788,789,790],"./chatgpt-v1.png","./chatgpt-final.png","./claude-v1.png","v1-prototype.png","67.png","budgie.png","./git25.png","f2bc29ccddd31a0f",{"html":793,"metadata":794},"\u003Cdiv class=\"note\">Disclaimer: I had a shortlived career as a front end dev (IE7 era) at TCS when I began my career post-engineering in 2010, so I am familiar with the basics of web development. Hence vibe-coding on web may be slightly easier for me to grok then someone non-technical who is trying it out.\u003C/div>\n\u003Cp>In October, when I started off my break, I wanted to explore vibe coding but the choices are overwhelming. Up till then, my exposure to LLMs had been to use ChatGPT to edit blog posts and using Midjourney for creating assets for Meta Ads and VC pitch decks. Attending Razorpay’s Design x AI in November helped me understand the realities of vibe coding and prompting but I needed an extra push.\u003C/p>\n\u003Cp>That push came in the form of a relative asking me to review their ‘Vietnam Travel Itinerary’. They had shared their ‘Itinerary as a huge wall of text pasted on Whatsapp. I could figure out a few obvious issues with it but I decided to see if AI can help me review and visualize the issues instead. I felt this would help me communicate the issues easier with my relative.\u003C/p>\n\u003Cp>Planning holidays and building itineraries is a hobby of mine, so I had tried ChatGPT earlier to help with trip planning but I had found it lacking. It was great at generating rough to-dos for your trip like places to visit, etc which I believe it has adequate training data on and to be fair, it’s great for a normie. However, it fails miserably in many places like recommending good stays and other kinds of specialized interests and I’ve also observed that it tends to think about planning in terms of a western or american perspective.\u003C/p>\n\u003Cp>So I started asking ChatGPT to visualize the itinerary on maps and when it created an html artifact, I asked it to iterated on the design and visuals. But there was a lot of back and forth to get something done and often subsequent generations rolled back changes I had made. Below are couple of variations of my iterations, (\u003Ca href=\"/vibe-coding/iterations/vietnam_12_day_itinerary_web.html\">left\u003C/a>) from when I started to (\u003Ca href=\"/vibe-coding/iterations/Vietnam_12Day_Itinerary.html\">right\u003C/a>) when I decided to get it to make it swiss-inspired.\u003C/p>\n\u003Cdiv class=\"impact-images\" style=\"display: grid; grid-template-columns: 1fr 1fr; gap: 1rem;\">\n\u003Cfigure class=\"image-figure\">\u003Cimg __ASTRO_IMAGE_=\"{"src":"./chatgpt-v1.png","alt":"","index":0}\">\u003C/figure>\n\u003Cfigure class=\"image-figure\">\u003Cimg __ASTRO_IMAGE_=\"{"src":"./chatgpt-final.png","alt":"","index":0}\">\u003C/figure>\n\u003C/div>\n\u003Cp>I hit chatGPT’s session limit and decided to move it to Claude. That’s when it got easier. Claude’s execution of my requests were better. You could see an invisible multiplier in place such that a 1x simple prompt gave a \u003Ca href=\"/vibe-coding/iterations/vietnam_itinerary.html\">10x output\u003C/a>.\u003C/p>\n\u003Cfigure class=\"image-figure\">\u003Cimg __ASTRO_IMAGE_=\"{"src":"./claude-v1.png","alt":"My input was the chatGPT html","index":0}\">\u003Cfigcaption>My input was the chatGPT html\u003C/figcaption>\u003C/figure>\n\u003Cp>That piqued my curiousity, I decided to see how far I could go.\u003C/p>\n\u003Cp>I first asked Claude what it would take to “productivize this” and it gave me a very detailed product roadmap of everything possible including the kitchen sink. It was overwhelming, but I made me learn that asking Claude for a plan is a good way to source ideas but better to work through the designs in the traditional way of implementation (prototype > iterate, repeat)\u003C/p>\n\u003Cfigure class=\"image-figure\">\u003Cimg __ASTRO_IMAGE_=\"{"src":"v1-prototype.png","alt":"Version 1 of Claude","index":0}\">\u003Cfigcaption>Version 1 of Claude\u003C/figcaption>\u003C/figure>\n\u003Cp>It took me about 40 iterations\u003Csup>\u003Ca href=\"#user-content-fn-1\" id=\"user-content-fnref-1\" data-footnote-ref=\"\" aria-describedby=\"footnote-label\">1\u003C/a>\u003C/sup> to get to a state I was comfortable sharing with friends to get feedback. Claude walked me through the steps of setting up Claude API key and hosting the app on Netlify, something I’ve never done before. You can check out the project at \u003Ca href=\"https://traviti.netlify.app/\">Traviti\u003C/a>.\u003C/p>\n\u003Cfigure class=\"image-figure\">\u003Cimg __ASTRO_IMAGE_=\"{"src":"67.png","alt":"My last iteration","index":0}\">\u003Cfigcaption>My last iteration\u003C/figcaption>\u003C/figure>\n\u003Ch4 id=\"fun-fact\">Fun fact:\u003C/h4>\n\u003Col>\n\u003Cli>When I moved the html to Claude, it removed the ‘Made by ChatGPT’ label in the markup. Jealousy?\u003C/li>\n\u003Cli>Claude struggled a lot to add it’s own logo into the markup and I had to write the markup in the end.\u003C/li>\n\u003C/ol>\n\u003Cp>This project gave me sort of confidence to build further. The itinerary generator was not what I would have wanted to build, but \u003Ca href=\"https://kenneth.dsouza.im/budgie/\">Budgie\u003C/a> was. The time to build Budgie was faster. I now had Claude Pro subscription and quickly hit the weekly limit and had to stop so the v1 of Budgie took a week longer than expected to ship. Update: I shipped an \u003Ca href=\"https://budgie.travel\">updated version of Budgie\u003C/a> over the Christmas holidays.\u003C/p>\n\u003Cfigure class=\"image-figure\">\u003Cimg __ASTRO_IMAGE_=\"{"src":"budgie.png","alt":"Final version of Budgie","index":0}\">\u003Cfigcaption>Final version of Budgie\u003C/figcaption>\u003C/figure>\n\u003Cp>Towards the end of this project, I moved to Claude Code on web and the experience dramatically improved again. Having Claude as a partner to pair with and write to the same repo was amazing QoL improvement.\u003C/p>\n\u003Cp>After Budgie, I felt it was time to stop procrastinating and start working on my portfolio (this site). It had been previously built on Eleventy via Glitch (RIP) but I wanted to test how easy would it be to re-write this. So for this project, I asked Claude Code to review and then rebuild the site in Astro and I also provided designs I made in Figma. Claude was easily able to render it and since then, I’ve taken to making Figma mockups to move the designs along.\u003C/p>\n\u003Cp>Midway through this, I decided to try Claude code on desktop and found myself lost a couple of times, so I decided to move back to Claude code on web. (I do want to try Claude code on Desktop for a future project where I build from scratch.)\u003C/p>\n\u003Cp>Since then, I’ve tried my hands at \u003Ca href=\"https://kenneth.dsouza.im/books-2025/index.html\">visualizing my book reading on P5js\u003C/a> and tried to clean up \u003Ca href=\"https://kenneth.dsouza.im/visualizing-trains/\">an old D3js assignment\u003C/a> from a college module.\u003C/p>\n\u003Cp>Honestly, LLMs have been able to help me overcome the barriers I used to face with hobby side projects and I hope more people get empowered this way.\u003C/p>\n\u003Ch3 id=\"helpful-tips-if-you-want-to-get-started\">Helpful tips if you want to get started\u003C/h3>\n\u003Cul>\n\u003Cli>\n\u003Cp>Starting new chat is the new CTRL+S. I struggled a lot on regular chat conversation. Claude Code however generates a nice summary of the chat when you hit context limit.\u003C/p>\n\u003C/li>\n\u003Cli>\n\u003Cp>Be ready to make a LOT of iteratons. Designing on Figma and providing images has been generally efficient to get the outcome you want.\u003C/p>\n\u003C/li>\n\u003Cli>\n\u003Cp>Start with small projects; for me that means static web projects. Identify what it means for you.\u003C/p>\n\u003C/li>\n\u003Cli>\n\u003Cp>I expect design hiring to have a vibe coding round in the near future. Being able to translate your designs to a real functioning prototype has never been easier and moreover it gives an insight into how the designer solves problems.\u003C/p>\n\u003C/li>\n\u003Cli>\n\u003Cp>Setup a free Github account and connect Claude to it. This will help with your versioning and the ability to roll back any unexpected changes. I personally prefer Github desktop over terminal and if you are new, I suggest you try that.\u003C/p>\n\u003C/li>\n\u003C/ul>\n\u003Csection data-footnotes=\"\" class=\"footnotes\">\u003Ch2 class=\"sr-only\" id=\"footnote-label\">Footnotes\u003C/h2>\n\u003Col>\n\u003Cli id=\"user-content-fn-1\">\n\u003Cp>At times, some of Claude’s prompts generated multiple iterations so iteration 40 was more like 10 prompts into the conversation. \u003Ca href=\"#user-content-fnref-1\" data-footnote-backref=\"\" aria-label=\"Back to reference 1\" class=\"data-footnote-backref\">↩\u003C/a>\u003C/p>\n\u003C/li>\n\u003C/ol>\n\u003C/section>",{"headings":795,"localImagePaths":803,"remoteImagePaths":804,"frontmatter":805,"imagePaths":808},[796,799,802],{"depth":57,"slug":797,"text":798},"fun-fact","Fun fact:",{"depth":44,"slug":800,"text":801},"helpful-tips-if-you-want-to-get-started","Helpful tips if you want to get started",{"depth":37,"slug":85,"text":86},[784,785,786,787,788,789],[],{"title":777,"description":778,"date":806,"status":19,"image":807},["Date","2025-12-22T00:00:00.000Z"],"git25.png",[784,785,786,787,788,789]] \ No newline at end of file diff --git a/astro-site/.astro/settings.json b/astro-site/.astro/settings.json index 1d94e74c..df4ec578 100644 --- a/astro-site/.astro/settings.json +++ b/astro-site/.astro/settings.json @@ -1,5 +1,5 @@ { "_variables": { - "lastUpdateCheck": 1776233890669 + "lastUpdateCheck": 1779356136307 } } \ No newline at end of file diff --git a/astro-site/.obsidian/workspace.json b/astro-site/.obsidian/workspace.json index 7d0c23f8..cf27045e 100644 --- a/astro-site/.obsidian/workspace.json +++ b/astro-site/.obsidian/workspace.json @@ -27,7 +27,7 @@ "state": { "type": "markdown", "state": { - "file": "src/content/writing/long-live-design-process/index.md", + "file": "src/content/writing/how-i-build-with-ai/index.md", "mode": "source", "source": false }, @@ -213,36 +213,39 @@ }, "active": "fa64cf4b0f3b9451", "lastOpenFiles": [ + "src/content/writing/how-i-build-with-ai/exhume.png", + "src/content/writing/how-i-build-with-ai/exhume.PNG", + "src/content/writing/how-i-build-with-ai/IMG_8206.PNG", + "src/content/writing/how-i-build-with-ai/variant.png", + "src/content/writing/how-i-build-with-ai/Screenshot 2026-05-22 at 2.30.53 PM.png", + "grindsize.md", + "src/content/writing/how-i-build-with-ai/index.md", + "src/content/writing/how-i-build-with-ai/grindsize.png", + "src/content/writing/how-i-build-with-ai/Screenshot 2026-05-22 at 2.28.02 PM.png", + "().md", + "src/content/writing/how-i-build-with-ai/how-i-build.png.sb-a0773456-CHVgVc", + "src/content/writing/long-live-design-process/index.md", + "src/content/writing/how-i-build-with-ai/how-i-build.png", + "src/content/work/jiva-lite/index.md", + "src/content/writing/how-i-build-with-ai", "src/content/work/sahabat-jiva-redesign/index.md", "src/content/work/gojek/index.md", - "src/content/work/jiva-lite/index.md", - "src/content/writing/long-live-design-process/index.md", "src/content/writing/long-live-design-process/jivalite-ground.png", "src/content/writing/long-live-design-process/rip-design-process.png", "src/content/writing/long-live-design-process/Frame@2x.png", - "src/content/writing/long-live-design-process/remove tombstone text@2x.png", - "src/content/writing/long-live-design-process/rip-design-process.webp", "src/content/writing/toko-poster/index.md", "src/content/writing/hiring/index.md", - "src/content/writing/long-live-design-process/claude-paper.png", "src/content/writing/long-live-design-process/Screenshot 2026-02-25 at 1.22.15 PM.png.sb-9c485e8d-i45gGB", - "src/content/writing/long-live-design-process/Screenshot 2026-02-25 at 1.22.15 PM.png", "src/content/writing/design-tools-decade/index.md", - "src/content/writing/long-live-design-process/Design_Sprints.png", - "src/content/writing/long-live-design-process/1024px-Design_Sprints.png", - "src/content/writing/long-live-design-process/Double_Diamond.png", "src/content/writing/long-live-design-process", "src/content/writing/toko-poster", "README.md", - "().md", "public/kenneth's presentation (1).pdf", "public/images/spots-new-design", "public/images/kenneths-presentation", "public/Spots_-_New_Design.pdf", "src/content/work/practo-pro/index.md", "public/Kenneths Resume 16022026.pdf", - "Kenneths Resume 16022026.pdf", - "Untitled", "Readme 1.md", "src/content/work/gobiz-inbox/index.md", "src/content/work/claim-profile/index.md", @@ -256,8 +259,6 @@ "node_modules/anymatch/node_modules/picomatch/README.md", "node_modules/anymatch/node_modules/picomatch/CHANGELOG.md", "node_modules/anymatch/README.md", - "node_modules/@shikijs/engine-javascript/README.md", - "node_modules/@shikijs/engine-oniguruma/README.md", "Untitled.canvas" ] } \ No newline at end of file diff --git a/astro-site/grindsize.md b/astro-site/grindsize.md new file mode 100644 index 00000000..e69de29b diff --git a/astro-site/src/content/work/jiva-lite/index.md b/astro-site/src/content/work/jiva-lite/index.md index 371c8cf0..ee7f70c7 100644 --- a/astro-site/src/content/work/jiva-lite/index.md +++ b/astro-site/src/content/work/jiva-lite/index.md @@ -78,6 +78,7 @@ We got 1 field marketer, Erwin, on loan from the growth team for the efforts on We built a website so that we could provide a social proof that Jiva Lite was infact an offering from Jiva and not a scam. The website had prices which we manually updated and directed users to the Whatsapp number. + #### Doing things that don't scale: We didn't build an in-flow way to add a farmer's bank account details. We resorted instead to use a manual system of getting the information from the farmer and getting CX team to add them to the system. This enabled us to ship faster and prevented user error from entering the wrong information. Where possible we pre-filled dummy data (e.g., user address) in the backend because we didnt want to build without valdiating our idea at this stage. @@ -164,7 +165,7 @@ In the one year of operation, we scaled Jiva Lite from 0 to 600 registered users -Behaviourally though, we were about to bring meaningful improvements into the lives of the Farmers in a few provinces of South Sulawesi. Most farmers who transacted with us made about 2.5-3 million IDR(~$180 USD) more than they would otherwise. +Behaviourally though, we were able to bring meaningful improvements into the lives of the Farmers in a few provinces of South Sulawesi. Most farmers who transacted with us made about 2.5-3 million IDR(~$180 USD) more than they would otherwise. Even after Jiva Lite shut down, a few of the farmers continued to deal directly with the collection centres and improve their collective earnings. ## Team diff --git a/astro-site/src/content/writing/how-i-build-with-ai/exhume.png b/astro-site/src/content/writing/how-i-build-with-ai/exhume.png new file mode 100644 index 00000000..f34f1ab3 Binary files /dev/null and b/astro-site/src/content/writing/how-i-build-with-ai/exhume.png differ diff --git a/astro-site/src/content/writing/how-i-build-with-ai/grindsize.png b/astro-site/src/content/writing/how-i-build-with-ai/grindsize.png new file mode 100644 index 00000000..f985a7bd Binary files /dev/null and b/astro-site/src/content/writing/how-i-build-with-ai/grindsize.png differ diff --git a/astro-site/src/content/writing/how-i-build-with-ai/how-i-build.png b/astro-site/src/content/writing/how-i-build-with-ai/how-i-build.png new file mode 100644 index 00000000..52b66289 Binary files /dev/null and b/astro-site/src/content/writing/how-i-build-with-ai/how-i-build.png differ diff --git a/astro-site/src/content/writing/how-i-build-with-ai/index.md b/astro-site/src/content/writing/how-i-build-with-ai/index.md new file mode 100644 index 00000000..74fe65f4 --- /dev/null +++ b/astro-site/src/content/writing/how-i-build-with-ai/index.md @@ -0,0 +1,42 @@ +--- +title: How I build with AI +description: A short overview of how I use AI when making my projects +date: 2026-05-21 +status: published +image: ./how-i-build.png +--- +I've been making stuff almost every week (like this [threejs space-viz](https://eternal-nebula-33dy.here.now/) this week), not everything I make ends up being shared but there's a particular method to my madness. + +### Measure twice, cut once +Most of my projects start their journey in a Claude Chat. Claude's research and artifact generation capabilities right in the chat accessible from anywhere via mobile makes it easy to riff on the idea while on-the-go. Plus given my product and design experience, I can easily manage to visualize designs and flows in my mind. + +![An example of how a UI description vs Output looks like](./grindsize.png) + +If you are unclear about the technologies, you can get Claude to ask you questions to refine the idea. This conversation at the beginning of a project is like the understand phase of the design process. +### Ready, Set up, Go +Setup involves downloading the artifact (or plan.md, figma make file, etc) to my laptop and create a github repo to work in. Depending on the task and my situation, I spin up Claude on local or on cloud. + +Although I started using Claude via the cloud setup and moved to Claude Desktop, using Claude via terminal has been easier because it can do more for lazy old me without being buggy as Claude desktop. (note to anthropic: steal codex's reliability and not it's style) + +I don't use skills, etc at the start. I feel [they are over-rated](https://blog.jim-nielsen.com/2026/opacity-of-generative-tools/) and is like outsourcing your design decisions. I don't work with an org or a design system so making my own 'design.md' feels unnecessary. I rather spend this time finding references and making mood boards. I don't build complicated technical systems, so I don't worry about code quality either. Most of my projects are a single HTML file. YMMV. +### Rinse and Repeat +While I rarely use skills while pro, sub-agents is something I've started to adopt. For e.g, for [grindsize.in](grindsize.in), where scaling the project would expect me to do repeated tasks, I employ 2 [sub-agents](https://github.com/inosaint/grinder-calibrator/tree/main/.claude/agents). I don't write these sub-agents, but just like my approach with skills, I ask Claude to generate them for me. When defining skills, I do specify the kind of model I want to power the sub-agent based on the task complexity and for token conservation. + +The process of creating sub-agents is similar to my process of creating skills. I make Claude create an outcome I plan. I test and review it. I make changes where required. Once I'm certain of the quality of the outcome, I check with Claude about making the process into an agent/skill. A point to note is that at times, certain process may work better as code rather than an agent. Listen to Claude. +### Tests, Evals... 🚀 +Testing takes like 90% of my time on every project. Making everything responsive is hard and the browser space is fragmented and it has led me to some interesting browser specific bugs that have stumped the LLMs. ngl, it's feels great to solve them and I can do that because I understand a bit of web technology. + +Another thing I wish I did more of is *evals*. Evals helps me when I don't understand the code that is being written. I get another agent to review one agent's work. I consider it to be like a design critique or code review. To manage complex projects and usage limits, I keep a memory.md, agents.md and claude.md files to help with this back and forth. + +![How variant helped me improve the visual style of Dominic, a AI based Figma Plugin](./variant.png) +### LLM based tools I currently use: +- **Claude:** Bulk to work done on Sonnet + API +- **Codex (Free):** Mainly for evals and bug fixes +- **ChatGPT:** Prompt definition, Image gen, API +- **Gemini:** ImageGen, Deep Research and Prompt definition +- **Variant.com:** Amazing for a functional minded designer like me, not sure how long they can survive though. + +-- + + +*If you are non-technical and want to learn how to to use AI to build, you can check out my free guide at [howtoaicode.com](howtoaicode.com)* \ No newline at end of file diff --git a/astro-site/src/content/writing/how-i-build-with-ai/variant.png b/astro-site/src/content/writing/how-i-build-with-ai/variant.png new file mode 100644 index 00000000..ce0e9d93 Binary files /dev/null and b/astro-site/src/content/writing/how-i-build-with-ai/variant.png differ