Prototyping like it is 2022

1. Michael Yagudaev Prototyping Like It’s 2022

2. About Michael • Indie Hacker @ conceptual.so (emojination.io), Skylab and picturethat.io • Full-stack Developer • Previous Life: UserTesting, Ollie Order, Consultant, PM, Founder, UX Designer, Corporate Employee • Web dev since 2001, professionally 2010 • O ffl ine: snowboarding 🏂, cycling 🚴 • 2022 Obsession: #BuildInPublic, marketing, YC Startup School

3. Outline • Generating Ideas • Exploring solutions • Dividing the work • Iterating and getting feedback

4. Where do we find ideas 💡? Product Market Fit

5. Audience First • 1. Find a group of people you want to help • 2. Find where they hangout • 3. Talk to them to fi nd an interesting problem • 4. Solve the problem • e.g. Talking to gamers about streaming and solving  the problem of live streaming on multiple platforms

6. Problem First • 1. Brainstorm problems you encountered • 2. Pick an interesting recurring problem • 3. Solve the problem • e.g. Basecamp solved their own problem   of managing projects and clients

7. Solution First • 1. Pick a new solution space: Web 3.0, AR/VR, AI,  new device/feature/API, etc • 2. Brainstorm problems you can solve • 3. Pick a problem that interests you • 4. Find the audience (ideally you are part of it) • 5. Build a solution • e.g. Markus Frind created POF to experiment with  ASP.NET and pad his resume.

8. Why are you doing this? • Learning? • Make money? • Get a promotion? • Satisfy existing users? • Satisfy new users? • Intellectual curiosity? • Fun? • Good grade? • Get a job? • Simulated work experience?

9. Exploring the Solutions Space • Take a look at similar products • Search GitHub for libraries and API that can help • Take a look at demo projects on github or templates to get you started

10. Example: PictureThat • Explorered demos on Awesome ARKit • One of them was ARBrush

11. PictureThat • Paper Sketches

12. PictureThat • Showed sketches to my mentor • Challenged me to build it • Built it in one afternoon • July 14, 2017 - Tweet • Launched mid-Sep, 2017 on AppStore

13. Build something people want • 50% marketing/traction • 50% product

14. Clickable Mock up? • Figma / Framer • + Useful for quickly getting everyone on the same page • + Easier to do longer-term planning around • - Learning curve to design tool • - Users can’t use it to solve their problem, thus super fi cial feedback • - Easy to fi t too many features that can take years of development

15. Do you want to buy this?

16. Example: Emojination • Problem fi rst • Creating interesting job ads and   announcements • Inspired by headers.me • Weekend project React + Next.js + LocalStorage on Vercel

17. Why Prototype? • Faster Feedback loop • Get it to the hands of real users right away • Shouldn’t take more than a few days or weeks.

18. Early Stage Startup - Ollie • B2B Wholesale Platform for Alcohol • V1: Spree Commerce - Jan, 2019, created a marketplace to make it easier for buyers. No one wanted that. • V2: From scratch - March, 2019, 3 sr. devs (one played designer role) • React, Graphql, Typescript, Apollo, Rails, Postgres, Elastic-Search, Our own Design System • MVP: June, 2019, 3 sr. devs + 2 contractors • Sales Litre becomes part of Ollie - October, 2019 • PHP, Angular, RESTful API • V3: June, 2020 Rewrite • Rails, Stimulus Re fl ex/Hotwire, Postgres, TailwindCSS • 10 engineers, Jan 2021 • Sold July, 2021 NextGlass

19. Late Stage Startup - UserTesting • On-Demand usability testing enabling faster feedback cycles • V1: 2007 VB • V2: ~2010 Rewrite in Rails, Restful API, Angular.js • V3: Graphql, Angular, Typescript, Apollo, Rails, MySQL, Elastic-Search, Our own Design System • Ongoing splitting into Microservices • 200+ engineers, fi led IPO 2021

20. Skylab • Started Oct 2018 • Python, Rails, React, React Native, AWS • V1: 2018 Python ML • V2: 2019 Rails + Python • V3: 2020 React + Rails + Python • Engineering: 8 Engineers, 2 Teams — ML and Product

21. What do you need? • Fearless execution • Relentless common sense

22. Dividing the work • 1-person-army • Frontend vs backend • Full-stack by area • Pair Full-stack on an area • Clear the kanban board weekly • if someone fi nishes their tasks, help other teammates with theirs

23. Leadership • Product owner and project manager roles • Spend no more than 50% of the time on coding/design tasks

24. Iterate, Iterate, then Iterate again • Your product will be 💩 day 1 • Accept it and iterate relentlessly. • Ask people what it is 💩 for them • One day it will be 🐛 => 🦋 • Video about design iterations: Youtube Video

25. Easier to revise • Pick a good starting point • Simple • Addresses many of the requirements • Saves you time • Helps you focus on your unique value prop

26. Weekly Cadence • Talk to users • Write code • Each week write an update and deploy code

27. Start with the UI • Always start with the UI • Users sees and interacts with it • API is a UI for developers, if that’s your target user focus on that • Use a UI Kit or UI Starter Kit

28. UI Kits • Find a UI kit both you and your users like • https://chakra-ui.com/ • https://nativebase.io/ • https://divjoy.com/ • https://ant.design/ • https://mui.com/ • https://getbootstrap.com/

29. Try Pro/Templates UIs • Plenty of great Free templates • Consider buying pro, by pooling resources • e.g. $20/person • learn how authors write their code • Hustle: email the author, tell them your poor students. • Discount of free

30. Don’t overthink it • Find what works for you • Keep it simple • Code duplication is a feature, not a bug • Once you fi gure out the product based on feedback • You can eliminate some duplication

31. Talking to Users • Start talking to them day 0 • Figure out what they currently use and how they use it • Let them try your product • Capture their thoughts and feedback • Do this every week and their feedback to guide you

32. Conceptual.so • “AI” generated marketing images • 4-week YC startup school build sprint • Goal was to go beyond emojis (emojination.io) • Talked to 21 people, 15 signups • Focused on text => image after talking to people • Still need more traditional graphics capabilities like Canva and Figma offer

33. Analyzing User Interviews: Super Human https://review. fi rstround.com/how-superhuman-built-an-engine-to- fi nd-product-market- fi t What they love What is missing

34. Possible Web Architectures Map

36. 1. No/Low Code

37. 1. No-Code/Low-Code Architecture • Tools we can con fi gure to solve our problems • Categories: • 1. General Purpose hosted: Airtable, Bubble, GlideApps, Google Forms, NetSuite • 2. General Purpose self-hosted: Wordpress, ActiveAdmin, Strapi • 3. Website builders: SquareSpace, Web fl ow • 4. Specialized hosted: ForestAdmin, Twilio Studio, Algolia • 5. Specialized self-hosted: SugarCRM, Metabase, Odoo, SalesForce • 6. Integration: Automate.io, Zapier, ifttt, segment.io • 7. Web scraping: webscraper.io, ScrapeHero, ScrapeStorm

38. 1. No-Code/Low-Code Architecture • Pros • Fast to start • No/little code to write • Less expensive then writing code • Continuously improves (receiving updates) • Uses best practices

39. 1. No-Code/Low-Code Architecture • Cons • Learning curve • Never prefect fi t for your use case • Data silos in di ff erent tools • Vendor lock • No separate environments, staging/sandbox • No automated tests • testing tools like Ghost-inspector, solve that

41. 2. Static-Site

42. 2. Static-Site • Simple HTML + CSS & JS site, no server-side logic • Static site generators help on bigger sites: jekyll, hugo, middleman, … • JAMStack is newer addition • Javascript, Apis and Markup • Gatsby.js, Netlify, Next.js*, etc • Web apis exist for: login, shopping cart, cms, etc.      * more capable

43. 2. Static-Site • Pros • Simple • Uses web standards • Easy to build • Maximum fl exibility on look & feel • Low cost hosting • Lightweight bundles delivered to end-user

44. 2. Static-Site • Cons • No direct access to dynamic data • Data silos between 3rd-party apis • Client-side only code, security challenges for APIs • Requires integrating many 3rd-party services • SEO needs to be considered (in contrast to e.g. Wordpress)

46. 3. Frameworkless

47. 3. Frameworkless • Idea: minimize use of 3rd party deps • Use language features and targeted libraries • e.g. using raw node http server, express, sinatra, fl ask, next.js* • can take approach on both client & server side

48. 3. Frameworkless • Pros • Shallow learning curve • Minimal & fast system • Less things to go wrong • Cons • Integration burden is upon you • More custom code required • Limited community support (depending on language)

50. 4. MVC Web Architecture

51. 4. MVC Web-Architecture • Model-View-Controller one fi rst design patterns • Divides presentation and business logic concerns • HTML over the wire, i.e. server renders html (view layer) • Popular frameworks: Rails, Django, Sails.js, Play Framework, ASP.net Core, Phonix, Laravel, … • Refreshing data requires page reloads • Send updates via HTML Forms

52. 4. MVC Web-Architecture • Pros • Simple mental model • Mature tech with good community support • Rapid development cycle • Fast initial load time • Simpler for SEO • Caching support: http caching, fragment caching, etc • Well integrated components*

53. 4. MVC Web-Architecture • Cons • Certain UX pattern not possible without custom JS • Page redirects can make for awkward UX • Larger subsequent network requests • Network latency will make app feel sluggish (especially on mobile)

55. 5. Reactive Server Architecture

56. 5. Reactive Server Architecture • Builds upon MVC Architecture • Adds a fi ner grained reactive-loop • HTML response is di ff ed and changes applied • Uses web socket connection to minimize latency • Libraries: Stimulus Re fl ex, Hotwire/Turbodrive, Live View, Blazor Server, Socketpuppet, LiveWire

57. 5. Reactive Server Architecture • Pros • No need for dedicated API layer • Business logic stays on server • Simple mental model, building upon existing one • Cons • Network latency • UI state kept on server • New and still early • (rails) poor isolation of component state

59. 6. Client/Server Architecture (SPA)

60. UserTesting Direction • V3: Scaling engineering & product • Graphql, Angular, Apollo, Microservice/Microfrontends, Ruby/Rails, Go, other languages • 200+ engineers and growing • Slowly going away from Monolith

61. 6. Client/Server Architecture (SPA) • Client: in-charge of UI rendering • Server: in-charge of data fetching + business rules • Build explicit interface for communication • REST • Graphql • RPC • SOAP • Transport medium: HTTP or Websockets

62. 6. Client/Server Architecture (SPA) • Pros • Decouples UI from Data • Max fl exibility on client • Simple to understand • Cons • Requires dedicated API • Requires syncing state • Duplication of logic — potential mis-match

63. Ollie in June, 2020

64. Ollie Direction • V3: Simpli fi cation - June, 2020 • Tailwind, Stimulus Re fl ex, Rails, Database search, Our own design system • January, 2021 - fully replaced SPA with Reactive-Server Architecture

65. Ollie in June, 2020

66. UserTesting in March, 2021

67. Skylab in Oct, 2021

69. 7. Microservices Architecture

70. 7. Microservices Architecture • Breakdown backend monolith • Each piece is an isolated process, either on the same or separate node • Communication is done via Sockets, HTTP or event bus • Protocols can be REST, gRPC, ProtocolBu ff , graphql • Origin from Service Oriented Architecture (2000-2010) • Serverless architecture is part of it

71. 7. Microservices Architecture • Pros • Independent deployability & scalability • Simpler & independent code bases • Can use many di ff erent languages • Easier to assign teams with clear boundaries • Cons • Hard to test entire system • Hard to change boundaries • Tracing errors across system becomes more di ffi cult • Compounding latency when services call each other • DevOps complexity

73. 8. Micro Frontends

74. 8. Micro Frontends • Breakdown frontend monolith • Container application manages mounting/unmounting of UIs • Pulled down at runtime

75. 8. Micro Frontends • Pros • Independent deployability UI + backend • Incremental upgrades • Simple independent code bases • Autonomous cross-functional teams • Cons • Increase download size • Inconsistency in UI between teams • Devops complexity • Environmental di ff erences between prod and dev

77. 9. Exotic Architectures

78. 9. Exotic Architectures • Newer tech useful in speci fi c situations • List • CQRS/Event Sourcing • GraphDBs - e.g. Neo4J • Block-chain / Web3.0

79. Conclusion Keep calm and iterate

80. One more thing… • Participate in the community as you are learning • Post your wins/struggle, get inspired by friends • Twitter #100DaysOfCode or #LearnInPublic • Huge help when looking for a job • Twitter is for Devs, Linkedin for hiring managers

81. References • https://martinfowler.com/articles/microservices.html • https://martinfowler.com/articles/micro-frontends.html • Clean Code - Robert Martin • Clean Architecture - Robert Martin • https://www.wired.com/2015/09/whatsapp-serves-900-million-users-50- engineers/ • https://review. fi rstround.com/how-instagram-co-founder-mike-krieger-took- its-engineering-org-from-0-to-300-people

82. Questions? Twitter/Linkedin: @yagudaev Website: yagudaev.com

Prototyping like it is 2022

Du liest eine Vorschau.

Hier ansehen

Prototyping like it is 2022

Weitere Verwandte Inhalte

Diashows für Sie (20)

Ähnlich wie Prototyping like it is 2022 (20)

Aktuellste (20)