User Experience (UX) design for Indie devs

803 views
741 views

Published on

Published in: Design, Technology
0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
803
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
7
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide
  • There is a lot of advice out there. Some of it common sense but I don't agree with all of it.\n
  • I'm also not rich.\nDon't have experience writing games.\n\n
  • 20 years proffesional dev experience\nFelt the need to adapt design advice to my situation.\nPart workshop part conversation.\n
  • Nothing against games.\nDon't have a hit driven personality.\nWant to build apps that enhance people's lives.\n
  • Assuming you are not marketer, or sales person, or artist, and probably not a designer\n\n
  • We hear this all the time. You are a developer not a designer.\nCan you even draw?\n\n
  • We need to change this.\nGreat drawing and art skills not a prerequisite.\nDesign is more about problem solving than art.\nReal world Problem solving is trade offs and optimizations\n\n
  • When we "solve" we are "optimizing" certain factors ...\nSoftware - correctness and efficiency\nBusiness - profitability, cash flow, etc.\nGraphic designer - aesthetics\nUX designer - user's experience\n
  • User's experience is his perception of your product.\nNo one cares or knows as much as you do.\nYou can not outsource UX\nYou need to own it.\nYou must own the user experience.\n
  • As Indies, .... We need to start thinking of ourselves as designers.\nDon't need to compete with professionals just get better.\n
  • Practice - Experience, training\nPerspective / Distance - They are not invested in the product\nTime - They are getting paid for it\nNotice: Talent not on the list\n\n\n\n
  • You may not be great but you can get better\nYou have 'do it' skills\nBy getting better you will attract better people around you\n
  • Based on Jared Spool - vision, feedback, culture for corporations\nManage Fear - be willing to be wrong, to change and learn\nDevelop Vision - know what you want for yourself, business and product\nCultivate Feedback - listen to but don't do everything you are told\n\n
  • afraid of failure, of success, ...\nafraid you'll build something no one will use or pay you for\nafraid you are not good enough\nafraid person X will find out you suck\n
  • People will laugh\nWe'll be ostracized from the village\nThe lions will eat us\n
  • Lions Raw (roar) - http://www.flickr.com/photos/matthew_norris/4591355259/\n
  • I'm afraid you will laugh at me ... luckily not too many lions Austin\nMost people\n... won't notice. Too busy with their own issues.\n... will forget\n... will give you credit for trying\nThere will be a few haters. No matter what.\nDo you want to be right or effective?\n
  • survivor - x did y and z happened - what about everyone else that did y?\n\n
  • Famous old story.\n
  • We think we're the ones that can see everything clearly.\n
  • But we have our own biases and blind spots.\n
  • Now that we are open to learning we address vision and feedback.\n
  • Classic advice you always hear.\nUsually said in a condescending way (I told you so) when you mess up.\n
  • Of course you have to think but it is not enough and it is not everything.\nBased on waterfall\nAssumes everything can be figured out by thinking\n\n
  • Design (Software engineering) advice assumes you have known knowns\nMake a plan follow the plan\nAwesome if you are on a cost plus contract\nWaterfall is risky for an indie - build a product no-one wants.\n\n
  • Read - Eric Ries\nIterative development\nLearn from the smallest possible changes\nGet to a desirable product as quickly as possible\nYou are not Apple\nFocus on speed not cost\n\n\n
  • No plan survives first contact with the enemy/customer.\nRight or wrong learn from your actions\nDo the minimum possible to test your assumptions\nThink code test analyze, think code test analyze\n\n
  • \n
  • \n
  • Feature or product ideas\n\nJudged on quantity not quality\n\nRank your features. You can’t do everything all at once. Force prioritization. \n
  • Feature or product ideas\n\nJudged on quantity not quality\n\nRank your features. You can’t do everything all at once. Force prioritization. \n
  • Feature or product ideas\n\nJudged on quantity not quality\n\nRank your features. You can’t do everything all at once. Force prioritization. \n
  • Feature or product ideas\n\nJudged on quantity not quality\n\nRank your features. You can’t do everything all at once. Force prioritization. \n
  • What does this app really do?\nWhere / how will people use it?\n\n
  • You've read the HIG right?\n
  • Use case\nHelps with marketing\nBase it on product statement without mentioning features or purpose or product till the end.\n\n
  • May not be artists but are all visual thinkers.\n\nDrew as children? Did we forget? Don't draw? You mean you don't draw well. Are you afraid?\n\n
  • Can be \n- completely abstract\n- show real objects and their relationships\n- realistic scene from previous story\n
  • Answer their questions politely.\n\nDon't explain or argue. LISTEN.\n\nIf they get it completely wrong it is a sign you need to rethink you statement, story, drawing.\n
  • Don't explain or argue. LISTEN.\n\n
  • personas / usecases\n\nHow do they think?\nWho is going to use it and why?\nAct it out\n\n
  • Adwords tools\nWe don't have access to iTunes search terms.\nNot to mention the app approval part\n
  • Get together to discuss and examine each others designs and ideas.\nLike CocoaHeads, NSCoder, Meetup but focused on UX testing and validating assumptions.\n\n
  • How are they going to win using your app?\n\nPick the absolutely most critical features only\n\nChoose your metaphors (user model)\n
  • \n
  • Error messages that help instead of hurt\n
  • Choose what works for you.\nWe are told "IB is not a design tool"\n
  • What is the purpose of wireframe or mockup?\nTo help you think and to help you communicate.\nYou don't have a client or a team.\nSketches are abstract enough to help thinking.\nPrototypes are concrete enough to gauge experience.\nWireframes and mocks can help but IMO are not worth it.\n\n\n
  • Rough out the UX first then come back to making it attractive.\n
  • User testing as integral part of dev process\nNot looking for statistical significance\nShort \nInformal\nNot beta testing\n\n
  • frequency, criticality, readiness, \n
  • craigslist,\ncoffee shops\nuser groups, clubs, church\nforget the NDA\n
  • don't apologize\ndon't explain.\nwatch and listen.\ngive time but offer encouragement\n
  • They want to please you. They are biased.\nAsking is better than nothing but watching is best.\n\n
  • \n
  • \n
  • \n
  • You now have a compelling app, clear vision, decent UX.\nGood designers have something they can sink their teeth into and know you are for real.\n\n\n
  • \n
  • \n
  • Quick first impressions test.\n
  • \n
  • \n
  • But don't forget to ... Ship.\n
  • The only thing that matters is traction.\n\nShip half a product not a half assed product - 37Signals\n\nExpect some to love it and some to hate it.\n\n\n
  • I've already won. So have you.\n\n
  • And many many more ... These will get you started.\n
  • \n
  • ×