32
37 Comments

How to prototype and user test ideas in hours. Not weeks.

The last months I've done more than 50 1-1 UX sessions and asked many fellow IndieHackers what's their design process.

Here is what most of them replied:

"I design straight in code cause it's faster for me. I know the basics of Sketch/Figma/Framer but I don't find them helpful. I don't see how they will help me, and save me time, since I can build the UI pretty fast in code."

Here is what I replied:

"You are right. They are useless. But just because you are using them in the wrong way."

Let's make this clear.

The only reason we go through a design process before we start building a product, is to research, prototype and test potential solutions as fast as possible. If we don't test any solutions during the design process, then it's useless.

Design is not about playing with pixels. It's about testing solutions. And the only reason to use a design tool and not design in code, is to prototype faster and get to the user feedback moment quicker.

Don't take me wrong. We are makers. We develop our own products. We don't care about designing pixel-perfect screens. I mean really, who cares? We want the real thing. We want to put our idea into pixels and play with it. We want to see how it feels.

That's where rapid prototyping and user testing comes into place. Forget wireframes, mockups, and pixel-perfect designs. Say hi to quick and dirty prototypes. Here is how they look like:

https://s3.amazonaws.com/gumroad/files/7286127925977/e7e68f88bfff4a3e8cb7651d4abf2d6e/original/Screenshot%202020-10-30%20at%2020.58.12.png

Let's take the following example

Matt is a fellow indie developer I help. He is based in Canada and is currently building an app that helps people with their annual tax income submissions.

This was Matt's process before we meet:

https://s3.amazonaws.com/gumroad/files/7286127925977/205a2621be784038bf7235b69028a80b/original/Untitled_Artwork%203.png

He built everything in code and took him around 2 weeks to be able to test with users and get some feedback to iterate on.

Here is how his prototype looked like. It was built with TailwindCSS and was fully functional.

https://s3.amazonaws.com/gumroad/files/7286127925977/354b7e0f8dfe403b9f8a30c657639cc1/original/Screenshot%202020-10-19%20at%2016.40.14.png

Here is Matt's process after we met:

https://s3.amazonaws.com/gumroad/files/7286127925977/36578c3a15f84fc8aee1d5ab11ec0aa8/original/Untitled_Artwork%202.png

He made a quick and dirty prototype using Framer (I showed him in 10mins how to use the tool) and tested it out with 2 users.

Here is also a video where you can watch one of the user testing sessions we hosted together.

https://www.youtube.com/watch?v=cUKNTA9zFiU

https://jimzarkadas.com/_next/image?url=https%3A%2F%2Fapi.super.so%2Fasset%2Fjimzarkadas.com%2Fe6ad4db6-98b8-484c-b50e-949a330fb920.png&w=1920&q=100

He got lots of feedback and iterated on the user flow he was building. It was a mind-blowing moment for him to see that he can get so much value and insights in such a short amount of time.

Here is how his prototype looked like. It was built on Framer and was fully functional with no real data or APIs.

https://s3.amazonaws.com/gumroad/files/7286127925977/95022c74f2b34add81bd3fddb7df1ed8/original/Screenshot%202020-10-30%20at%2020.42.04.png

As you can see his UI is not sexy and doesn't look mature. However this is why it's so cool. Because at this stage Matt wants to design a user flow that is easy to follow. He doesn't care about the colours or if the API is real. He cares about the content of his UI, the information architecture, the layout and the way his product works.

Of course visual details matter a lot but NOT at this stage. Once he gets the flow and the concept right, he can focus on the UI details and start building the real product. One thing to note is that the UI part is mostly covered by using TailwindCSS so it's something he doesn't have to worry at all.

Here is another interesting insight he shared:

"What's so cool with this approach is that I don't have to marry myself to a technology in order to get something off the ground (overcommitted before properly planning/iterating). I don't spend time taking technical decision or researching tools. I just focus on prototyping quickly a user solution and test it out with potential users."

Quick recap

More user testing = Better UX. It's that simple. That's why it's important to adopt a simple and lean process like this one.

Design is here to help you not to hold you back. Design is not about replicating your app's interface in a design tool. Design is about prototyping and testing in smart ways. Design is about talking with your users and building a better product. Design is love and care for your users. You just need to find the right tools and process.

A final note to add, is that this process is the one I followed at my last job with my team in TicketSwap and we shipped successful major product iteration to 5+ million unique users! It's the process I also use to build my own SaaS product. So feel free to try it out, it's safe and works 🙂

What are your thoughts?

Feel free to comment your thoughts/questions/ideas and join the discussion. I would love hear what you think and help you design faster and smarter!


Get 1% better at UX every week

Subscribe to get notified when I publish new UX articles

  1. 2

    Oh damn, I love this approach so much. I'm going to apply it very soon with my early adopters. I have a list of early adopters but not being able to get feedback from them because I building the first version.

    Thanks a lot for sharing this.

    For these who are asking how to recruit people: I simply made a landing page describing what problem I'm solving and value I'm creating (https://notiontweet.app), then share it on Twitter, I got 6 people interested with a tweet after a day. I think you just need to solve a real problem and create real value first, then find where people having that problem are present. I use hashtags on Twitter and it works. See this newsletter issue if you wants to learn more: https://buttondown.email/phuctm97/archive/3-key-learnings-from-first-week-building-a/

    1. 1

      Thanks as lot man!

      I totally agree also with what you said - "I think you just need to solve a real problem and create real value first, then find where people having that problem are present."

      Also I will keep an eye on you product! I am creating a lot of content on Twitter and I have developed a content system and calendar in Notion but it's a pain in the ass that I have to open a new tab always and use services like https://typefully.app/ to write the actual tweets that fit the 240chars limit etc.

      If you need any help feel free to DM/email me, happy to help you with anything related to UX!

      1. 1

        Thank you a lot, @jimzarkadas! Will do that for sure.

        I will try to post more about the product here on Indie Hackers for you and others to easily follow. Meanwhile, my Twitter (https://twitter.com/phuctm97) is the fastest way to see more updates and insights if you're interested.

    2. 1

      Man, that's a very fine newsletter issue you got there. Love it! Also really like your landing page (especially on mobile). Looks like a nice project.

      Thanks a lot for sharing your approach!

      Now I'm thinking about making a landing page like yours, too …

      1. 2

        Thank you @nikwen!

        Looking forward to seeing your landing page!

  2. 2

    This is true but for some people the initial interia of having to make user flows in a foreign app (figma, framer, xd etc...) would make it harder to start.

    While this is an ideal way to do things, I think people should stop trying to find the perfect way to do things and just start really badly. If that means creating a prototype in rails for 2 weeks then whatever, better than no progress. But doing things your own way also means having the option of doing things properly.

    1. 2

      Yeap I totally agree with what you said. The first goal is to start somehow. Then it's about optimising your process and validating assumptions with incremental steps to save time in the long-term. It's all about the goal, the tools always change and can be different from person to person.

  3. 1

    This is really good advice! Thank you! Even though I started my career as a designer (back when photoshop was king) in the last years I found myself prototyping by taking a whole week or more to code it, i stead of actually designing it and validating it with a stake holder.

    Thanks for the reminder and for introducing me to Framer!!

    Question: What are you thoughts on Figma va Framer?

    1. 2

      Thank you for the kind words and really happy it helped!

      My thoughts on this is the following: "I depends on the job you are trying to get done"

      Personally I use framer cause I can do many advanced things in there in case I need to and I like their vision more compared to Figma. But I wouldn't say it's better compared to Figma.

      Both are really great tools and it totally depends on what you need and you're trying to achieve. For example Figma performs better with large teams and has more collaboration features and on the other hand Framer performs best when you want to build super advanced prototypes.

      Do you have smth specific in mind in terms of what you want to design?

      1. 1

        Hey @jimzarkadas, thank you for the detailed explanation. This makes sense – I'm pretty experienced with Figma (coming from Photoshop) but I think I will give Framer a chance the next time we're building a new feature. Definitely looking to prototype it rather than build everything in code first :)

        The next thing I'm thinking about, which I want to market before build, is our first tournament event, which will be for a charity cause. And I'd like to see if there is traction before building it!

  4. 1

    Excellent points! More people should do this 👏🏻

    1. 1

      Thank you and totally agree! Especially now with all the amazing tools like Framer, Figma and protopie it's easier than ever to prototype ideas :)

  5. 1

    This is how I've done it both within the big corporate and startup setup. It eliminates waste. As you mentioned in the comments as well, obviously nothing replaces putting something "tangible" in front of a customer and let them use it.

    Here's a question that just popped up and I'd be interested in your opinion... would you prototype a buy flow like Amazon to test with users, or just consider it as "validated", because Amazon has split-tested it to Mars and back?

    Cheers, Pat

    1. 1

      Hey Pat! Thanks for joining the discussion as well :-)

      Great question. My personal approach on this would be to analyze the buy flow of Amazon and observe how it works and what are the best-practices in there, UX-wise. This would be a great input for me to design my own flow instead of just using it as it is.

      The end outcome could be of course be similar but when it comes to UX each product is different and also the Amazon buy flow "works" for the audience size they have, the marketplace type they have, the design strategy they have and also the brand awareness and trust they have.

      That said, I would design my own flow and user test it by following the approach I mentioned in the article. This way I would get to know more my end user and what kind of second thoughts they have when purchasing my product.

      For example in TicketSwap when we redesigned the buy flow we got insights related to the brand-trust, payment types (specific for Netherlands, France etc), and the ticket reservation process in the cart. These were all 100% unique to the TicketSwap product and I could only get these insights by doing user testing :-)

  6. 1

    Hi Jim

    There is a lot of truth and advise in it. I suppose with the next product I will take this approach.

    With the last one I discovered along the coding and testing perspectives I would not have gained from prototyping. It was a proof of concept and whilst using it, I gained more insight on what else is fine to be implemented and into what it could evolve. After all, I fathomed the hidden parts of my idea within the process.

    Thanks for the insights!

    Christian

    1. 1

      Hey Christian, thanks a lot for sharing this and happy to help! If you need any help when using this process feel free to reach out as well :-)

  7. 1

    Wow, super lean indeed! Love this approach!

  8. 1

    Makes total sense but I gotta tell you as a dev by heart I always want to write code haha.

    But this is the more sane approach and more often than not I get myself to do it 😁

    1. 1

      Haha totally get it! I feel the same as well. It's more fun and comfortable to focus on designing the details and building the product instead of giving it to somebody to roast it. User test it always hurts at first until you get used to getting feedback and then you ll actually enjoy it!

      Give it a try and if you need any help feel free to reach out, happy to help!

      1. 1

        "Ain't nothing to it but to do it" 😁

        I might be moving to Utrecht soon so I see ye there, met anderhalve meter afstand 😎

  9. 1

    So I didn't get how do you get feedback that give you full validation for one day🤔

    1. 2

      Good question - this is not a process that can provide full validation on a business idea. Actually the only way to truly validate a product idea is to build it and see if people buy it or not.

      This process is great to validate assumptions about how your product should work and how a user flow should look like.

      Let's say you are building amazon.com and you have to implement the buy flow. Instead of building it straight away in code and spending weeks with no testing and validation, you can start by creating a "dirty" (aka low fidelity) prototype in Framer/Figma and validate there if it's easy to use. If people feel safe, if they get confused, if the interactive elements are easy to find and so on.

      By giving a fake prototype to people you can observe what second thoughts they have, how they try to use your product and also how the think (their mental model). These insights will help you make much better design decision and create in the end a product that is much easier to use.

      Hope these examples helped!

  10. 1

    Great approach! I never start coding first because my ideas are all jumbled and I don't know which UI/product decisions to make.

    Thanks for writing this!

    1. 1

      Really happy you found it useful, thanks for sharing that!

  11. 1

    Curious how do you recruit people to do the test in the video, I think her feedback is pretty detailed and she seems like an experienced UX tester

    1. 2

      Haha good observation, she is my girlfriend actually and she is working as a digital marketeer - that's why she is able to go into details and give some advice as well. Normally you will have people explaining how they feel and if they get blocked or confused which is more than enough for the testing/validation :-)

    2. 1

      This comment was deleted 2 years ago.

      1. 1

        I will publish a new post soon on the topic of "where and how to find people to user test with". It's a super interesting and challenging topic so I'll write down everything I've learned so far :-)

        As you said it's a requirement actually to have a prototype designed for them to use otherwise the only thing you can do with them is a 1-1 interview using the Momtest framework (here is the link in case you haven't heard of it http://momtestbook.com/)

        This process is great to test design ideas and validate user flows to make sure the UX of your product will be good enough. Validating a business idea can only be done by building the product and seeing if people will pay or not. Or by building a landing page to test the demand at least.

        1. 1

          This comment was deleted 2 years ago.

          1. 1

            It's a big challenge for sure!

            It's a very easy advice to give to people "test your prototype with others" but really hard to put into practice. The biggest challenge for me was to overcome the psychological part of showing something that "is not finalised" to somebody.

            The way I overcame this was to try more and more frequently in order to understand how it works and do one small step at a time. After every session I was excited with the insights I got and this was the motivation that would drive me to do the next user testing session and so on.

            But the key was, baby steps and focus on getting 1% better every time. This way I reached the level where user testing started feeling as something "casual" to me that I am not very afraid of doing anymore :-)

            1. 1

              This comment was deleted 2 years ago.

              1. 1

                Really cool, happy that it helps! It's by far my favourite book when it comes to user research :-D

  12. 1

    Really like your approach. 👍

    For my last app I created a rough prototype in a design tool in 2 hours and sent it out to users. The feedback I received completely changed how I built the app. And this was just me trying something without really knowing how to do it. Loving your advice on prototyping and user-testing so far.

  13. 1

    This comment was deleted 2 years ago.

  14. 1

    This comment was deleted 3 years ago.

  15. 0

    This comment was deleted a year ago.

    1. 1

      Could you elaborate a bit more why you feel it's an approach that requires a team? I use this approach as an IndieHacker myself and I am able to prototype and validate user flows pretty fast (faster than coding). Also IndieHackers that I helped with 1-1 coaching use it as well and are pretty happy with it.

      I don't mean that it's the perfect approach and I that don't agree with you, I just want to understand why you feel it slows you down instead of speeding you up and learn from your insights :)

      1. 1

        This comment was deleted a year ago.

        1. 1

          Ah ok now I see what you mean - also for the downvoting I totally agree with you this is not a agree/not agree conversation we are just discussing the pros and cons of an approach.

          For the user flows the idea is that if you do it in Framer or Figma with a low-fidelity prototype, you can do make it in literally 3-4 hours and get some initial feedback. If you end up spending weeks then indeed it will hold you back and doesn't create any significant value.

          Finally I totally agree that the best kind of feedback is the one of the real product. Nothing can compare to that :-)

Trending on Indie Hackers
How I grew a side project to 100k Unique Visitors in 7 days with 0 audience 48 comments Competing with Product Hunt: a month later 33 comments Why do you hate marketing? 28 comments $15k revenues in <4 months as a solopreneur 14 comments My Top 20 Free Tools That I Use Everyday as an Indie Hacker 13 comments Use Your Product 13 comments