டெவலப்பர்களிடம் வடிவமைப்பாளர்கள் கொண்ட முதல் 6 விரக்திகள்

உள்ளடக்கம்

• 01. நான் ஒரு காரணத்திற்காக அதை வடிவமைத்தேன்
• 02. எம்விபி!?!? இது எல்லாம் எம்விபி!
• 03. இது எவ்வளவு நேரம் எடுக்கும்?!?!?
• 04. "என்னால் அதைச் செய்ய முடியாது!"
• 05. பயன்பாட்டு சோதனை விருப்பமல்ல
• 06. மீண்டும் வடிவமைப்பது எப்படி என்று அவர்கள் என்னிடம் சொல்கிறார்கள்!
• வேறு எதாவது?

டெவலப்பர்கள் வடிவமைப்பாளர்களிடம் விரக்தியடையலாம் என்பதை நாங்கள் அறிவோம், குறிப்பாக வடிவமைப்பாளர் உருவாக்க முடியாத ஒன்றை வடிவமைக்கும்போது. ஆனால் வடிவமைப்பாளர்கள் டெவலப்பர்களிடம் விரக்தியடைய நிறைய இருக்கிறது.

வடிவமைப்பு பெரும்பாலும் ஒரு ‘மென்மையான திறன்’ என்று பார்க்கப்படுகிறது, இது அழகியல் பற்றிய ஒரு கருத்தைப் பற்றியது, கடினமான விதிகள் அல்ல, குறியீட்டின் கடுமையான தர்க்கம். ஆயினும் வடிவமைப்பாளர்கள் பல ஆண்டுகளாக ஒரு கைவினைப்பொருளை முழுமையாக்குகிறார்கள், அறிவிக்கப்படாத யோசனைகளைத் தூண்டுவதில்லை. இருப்பினும், ‘வடிவமைப்பு பைத்தியக்காரத்தனத்தின் பின்னால் உள்ள முறையை’ விளக்கி வெளிப்படுத்துவது எப்போதுமே எளிதானது அல்ல, அரிதாகவே விரைவானது, இது ஏராளமான திட்ட விரக்திகளுக்கு வழிவகுக்கிறது. அதிர்ஷ்டவசமாக, பதற்றத்தைத் தணிக்க பொதுவாக ஒரு வழி இருக்கிறது.

01. நான் ஒரு காரணத்திற்காக அதை வடிவமைத்தேன்

பிரச்சினை: வடிவமைப்பாளர் உத்தமமாக வடிவமைக்கப்பட்ட காட்சித் தொகுப்புகள் மற்றும் விவரக்குறிப்பு ஆவணங்களை உருவாக்க வாரங்கள் செலவழிக்கிறார், அவற்றை டெவலப்பரால் புறக்கணிக்க வேண்டும். விவரக்குறிப்புகளைப் புறக்கணிப்பதைத் தாண்டி, சில டெவலப்பர்கள் உலாவி இயல்புநிலைகளை காட்சித் தொகுப்புகளில் காட்டாமல், ஆவணங்களில் வெளிப்படையாகக் குறிப்பிடப்படாவிட்டால் மாற்றமின்றி நிற்க அனுமதிக்கின்றனர்.

டெவலப்பர் காம்ப்ஸை உற்று நோக்கி அவற்றை ‘பிக்சல்-கச்சிதமாக’ பொருத்த முயற்சிப்பார் என்று வடிவமைப்பாளர் கருதுகிறார். இருப்பினும், இது பொதுவாக வடிவமைப்பாளர்களின் சிறந்த முயற்சிகள் இருந்தபோதிலும், தடைபட்டதாக அல்லது மோசமாக ஒழுங்கமைக்கப்பட்டதாக உணரும் இடைமுகங்களுக்கு வழிவகுக்கிறது.

தீர்வு: வடிவமைப்பாளர்கள் எதையும் எடுத்துக் கொள்ளக்கூடாது, ஆவணங்கள் ஒருபோதும் போதாது என்பதை அறிந்து கொள்ளுங்கள். ஒரு நல்ல வடிவமைப்பு வழிகாட்டி இந்த சிக்கலை அகற்றுவதற்கான முதல் படியாகும், ஆனால் வடிவமைப்பாளர்களும் டெவலப்பர்களுடன் பக்கபலமாக பணியாற்ற வேண்டும், டெவலப்பர் எதை வசதியாக உணரும்போது வடிவமைப்பு ஏற்றுக்கொள்ளல் மதிப்பாய்வில் இது நோக்கம் என்பதை உறுதிப்படுத்த அவர்களின் வேலையை தொடர்ந்து மதிப்பாய்வு செய்ய வேண்டும். அவர்கள் செய்திருக்கிறார்கள்.

02. எம்விபி!?!? இது எல்லாம் எம்விபி!

பிரச்சினை: டெவலப்பருக்கு இறுதி தயாரிப்பை உருவாக்க ஒரு வரையறுக்கப்பட்ட நேரம் உள்ளது, ஒவ்வொரு ஸ்பிரிண்டிற்கும் கூட குறைவாகவே இருக்கும், எனவே அவை தயாரிப்பு விவரக்குறிப்புகளை பூர்த்தி செய்யும் ‘குறைந்தபட்ச சாத்தியமான தயாரிப்பு’ அடிப்படையில் அம்சங்கள் மற்றும் செயல்பாடுகளுக்கு முன்னுரிமை அளிக்கும். இருப்பினும், பெரும்பாலான வடிவமைப்பாளர்கள் தயாரிப்பை ஒருங்கிணைந்த முழுமையாய் பார்க்கிறார்கள், தொடர்ச்சியான இண்டர்லாக் கூறுகள் அல்ல. ஆனால் எம்.வி.பி பெரும்பாலும் வளர்ச்சிக் கட்டம் வரை வரையறுக்கப்படவில்லை, எனவே டெவலப்பர்கள் பயனர் மற்றும் தயாரிப்புத் தேவைகளை விட அவர்களின் அட்டவணைத் தேவைகளின் அடிப்படையில் முடிவுகளை எடுப்பதைப் போல உணர முடியும்.

தீர்வு: உற்பத்தியின் ஆரம்ப கட்டங்களில் எம்விபி வரையறுக்கப்பட வேண்டும், மேலும் வெவ்வேறு வளர்ச்சி கட்டங்கள் / ஸ்ப்ரிண்ட்களுக்கு எளிதில் செய்யக்கூடியது மட்டுமல்லாமல், குறைந்தபட்ச சாத்தியமான உற்பத்தியாக இருக்க வேண்டும். ஒரே நேரத்தில் முடிக்கப்படுவதை விட, வடிவமைப்பாளர்கள் கட்டங்களில் கட்டமைக்கப்பட்ட ஒரு தயாரிப்பை உருவாக்க வேலை செய்யலாம். டெவலப்பர்கள் அதற்கேற்ப திட்டமிடுவதையும் இது எளிதாக்க வேண்டும்.

03. இது எவ்வளவு நேரம் எடுக்கும்?!?!?

பிரச்சினை: வடிவமைப்பாளர் பயனர்களின் தேவைகளைப் பூர்த்தி செய்வதற்காக பல மாதங்கள் திட்டமிடல், ஆராய்ச்சி மற்றும் வடிவமைப்புகளை உருவாக்கியுள்ளார், முரண்பட்ட திட்ட அட்டவணைகள், ஊழியர்களின் பற்றாக்குறை மற்றும் பயங்கரமான நோக்கம் ஆகியவற்றின் காரணமாக எதிர்பார்த்ததை விட அதிக நேரம் எடுக்கும் என்று மட்டுமே கூறப்படுகிறது.

தீர்வு: எந்தவொரு UI அபிவிருத்தி திட்டத்தின் உண்மைகளில் ஒன்று, வளர்ச்சி கடைசியாக வருகிறது, பொதுவாக முந்தைய படிகளால் காலப்போக்கில் பிழியப்படுகிறது (வளர்ச்சிக்கு அதிக நேரம் கொடுக்க திட்டமிட்டதை விட வேகமாக செல்ல, கண்டுபிடிப்பது, வரையறுப்பது அல்லது வடிவமைப்பு கட்டங்களை நான் ஒருபோதும் அறிந்திருக்கவில்லை) .

இதைச் சுற்றியுள்ள ஒரு வழி, வடிவமைப்பிற்கு இணையாக வளர்ச்சியை அனுமதிக்க லீன் யுஎக்ஸ் உடன் இணைந்து சுறுசுறுப்பானது, வடிவமைப்பு முற்றிலும் பூட்டப்படுவதற்கு முன்பு டெவலப்பர்களைத் தொடங்க அனுமதிக்கிறது. இந்த அணுகுமுறை அபாயங்கள் இல்லாமல் இல்லை (வடிவமைப்பை மறுபரிசீலனை செய்ய வேண்டியிருக்கலாம்) ஆனால் பொதுவாக வேகமான வெளியீடு மற்றும் மகிழ்ச்சியான திட்ட மேலாளர்களுக்கு வழிவகுக்கிறது. உண்மையில், நாம் அனைவரும் விரும்புவது அதுதானா?

04. "என்னால் அதைச் செய்ய முடியாது!"

பிரச்சினை: வடிவமைப்பாளர் மிகவும் அருமையான அனுபவத்தை உருவாக்கியுள்ளார், ஆனால் டெவலப்பர் அதைப் பார்த்து, "அது ஒருபோதும் இயங்காது" என்று அறிவிக்கிறது. டெவலப்பர்கள் ஏதாவது செய்ய முடியாமல் போக ஒரு காரணம், ஏனெனில் அதைச் செய்ய முடியாது, ஆனால் பெரும்பாலும் இது வேறு இரண்டு காரணங்களில் ஒன்றாகும்: 1) இது அதிக நேரம் எடுக்கும், திட்டத்தை விட அதிக நேரம் எடுக்கும், அல்லது 2) டெவலப்பர் இப்போது செய்யவில்லை அது எப்படி என்று தெரியவில்லை.

தீர்வு: இதைச் செய்ய முடியாவிட்டால், அதைச் செய்ய முடியாது, வடிவமைப்பாளர் தீர்வை மறுபரிசீலனை செய்ய வேண்டும். இது அதிக நேரம் எடுக்கும் என்றால், அணி மீண்டும் அளவிடலாமா அல்லது தேவையான நேரத்தை எடுத்துக் கொள்ளலாமா என்பதை தீர்மானிக்க வேண்டும். ஆனால், அதை எவ்வாறு செயல்படுத்துவது என்பது டெவலப்பருக்குத் தெரியாவிட்டால், விரும்பிய நுட்பம் செயல்படும் இடங்களின் எடுத்துக்காட்டுகளை வடிவமைப்பாளர் அவர்களுக்குக் காட்ட வேண்டும். எனது டெவலப்பர்களுக்கு ‘இருக்கும் கலையை’ காட்ட வேண்டியிருக்கும் போது, ​​கோட் பென்.ஓ எனது சிறந்த இடமாக இருப்பதை நான் காண்கிறேன்.

05. பயன்பாட்டு சோதனை விருப்பமல்ல

பிரச்சினை: பல டெவலப்பர்களுக்கு ‘பயன்பாட்டினை’ என்பது தேவைகளால் வரையறுக்கப்பட்டபடி செயல்படுகிறது என்பதாகும். வடிவமைப்பாளர்கள் எதையும் சோதிக்க விரும்பினால், டெவலப்பர் UI ஐ கண்ணாடியைக் கட்டுவதற்கு நீண்ட நேரம் செலவிடுவதற்கு முன்பு அவர்கள் அதைச் செய்ய வேண்டும். இருப்பினும், காகிதம் மற்றும் கிளிக் செய்யக்கூடிய முன்மாதிரிகளால் இவ்வளவு பயன்பாட்டினை சோதனை செய்ய முடியும். பெரும்பாலும், வளர்ச்சியின் போது மிகவும் பயனுள்ள பயன்பாட்டினை சோதனை செய்யப்படுகிறது.

தீர்வு: எந்தவொரு சுறுசுறுப்பான திட்டத்திலும் பயன்பாட்டினைச் சோதிக்கும் கூர்முனைகளைத் திட்டமிடுங்கள்.

06. மீண்டும் வடிவமைப்பது எப்படி என்று அவர்கள் என்னிடம் சொல்கிறார்கள்!

பிரச்சினை: ஒரு டெவலப்பர் ஜாகோப் நீல்சனின் பயன்பாட்டினைப் பற்றிய ஒரு கட்டுரையைப் படிக்கிறார், திடீரென்று அவை ஒரு பயன்பாட்டினை மற்றும் வடிவமைப்பு நிபுணர். வடிவமைப்பாளர்கள் தங்கள் திறன்களையும், அறிவையும், திறனையும் வளர்த்துக் கொள்கிறார்கள். ஒரு சிக்கல் என்னவென்றால், சில திட்டங்களில் வடிவமைப்பு (தகவல் அல்லது இல்லை) பற்றி எல்லோருக்கும் ஒரு ‘கருத்து’ இருப்பதால் - குறிப்பாக ஒரு யுஎக்ஸ் குழு இருக்கக்கூடும் - அவர்களின் குரல் பெரும்பாலும் மூழ்கிவிடும்.

தீர்வு: இது தீர்க்க எளிதான பிரச்சினை அல்ல, ஏனெனில் இது உண்மையான தர்க்கம் மற்றும் காரணத்தைக் காட்டிலும் ஒருவருக்கொருவர் மற்றும் குழு இயக்கவியலுடன் தொடர்புடையது. இந்த சூழ்நிலைகளைச் சமாளிக்க நான் கண்டறிந்த சிறந்த வழி, தற்காப்பு பெறாமல் வெறுமனே கேட்பதுதான். அவர்கள் சொல்வதைக் கூறட்டும், அவர்கள் சொல்வதைக் கருத்தில் கொள்ளட்டும்.

அவர்கள் சொல்ல வேண்டியது தகுதி உள்ளதா? அவர்களுக்குத் தெரியப்படுத்துங்கள், பின்னர் நீங்கள் ஏன் நீங்கள் சென்ற பாதையில் செல்லத் தேர்ந்தெடுத்தீர்கள் என்பதை விளக்குங்கள், வேறு இடங்களில் பரிந்துரைக்கப்பட்டுள்ளபடி இருக்கும் ‘சிறந்த நடைமுறைகளை’ நீங்கள் ஏற்கவில்லை என்பதைக் கூட ஒப்புக்கொள்கிறீர்கள். பெரும்பாலும் டெவலப்பர்கள் வடிவமைப்பாளர் வெறுமனே சொல்வதைக் கேட்பதைப் போல உணர விரும்புகிறார்கள்.

வேறு எதாவது?

வடிவமைப்பாளர்கள் டெவலப்பர்களுடன் இருப்பதை நான் பொதுவாகக் காணும் ஆறு ஏமாற்றங்களை நான் கோடிட்டுக் காட்டியுள்ளேன், மேலும் டெவலப்பர்கள் வடிவமைப்பாளர்களிடம் இருக்கும் ஆறு விரக்திகளை முன்னர் விவரித்தேன். இதைப் பற்றி நீங்கள் என்ன எடுத்துக்கொள்கிறீர்கள், பட்டியலில் சேர்க்க முடியுமா? உங்கள் அனுபவத்திலிருந்து நாங்கள் அனைவரும் பயனடைய கீழேயுள்ள கருத்துகளில் தீர்வுகளை பரிந்துரைக்கவும்.

சொற்கள்: ஜேசன் கிரான்போர்ட் டீக்

ஜேசன் கிரான்போர்ட் டீக் கேபிடல் ஒன்னில் ஒரு மூத்த கிரியேட்டிவ் இயக்குநராக உள்ளார், மேலும் டெவலப்பர்களுக்கான அனுபவ வடிவமைப்பு, வடிவமைப்புகளுக்கான மேம்பாடு மற்றும் தற்காலிக வடிவமைப்பு சிந்தனை குறித்த பட்டறைகளை கற்பிக்கிறார்.

இது போன்ற? இவற்றைப் படியுங்கள் ...

• உங்கள் போர்ட்ஃபோலியோவில் 5 விஷயங்கள் இருக்க வேண்டும்
• வலைப்பதிவை எவ்வாறு தொடங்குவது
• சிறந்த இலவச எழுத்துருக்களைப் பதிவிறக்கவும்