Introducing InVision Studio(

over 5 years ago from Stephen Olmstead, Design Partnerships @ InVision App

  • Tom ReinertTom Reinert, over 5 years ago

    For a second, I was hoping that they solve the one HUGE problem that all of these tools have:

    They are based on artboards. We use these tools to create hundreds of artboards (=images) for apps and digital products that have as little as 3 different views.

    We create still images for what is a living product. It's like drawing a storyboard for a movie. While this is a necessary step, we also need to tackle the next step which is making the f… movie. We can connect the single images with fancy animations, but they are still (still…) images. Then we let someone else make the movie and wonder why it didn't come out as we planned.

    What we need is a tool that creates living components. Just let me create components and let them have multiple states based on click-, hover- and scoll-events. Then, let me build a view consisting of those components.

    Kind of like Framer, but way simpler. Designers should code, but won't.

    While I applaud the effort that went into this product (and it is for sure very well designed) I think it's just a prettier, maybe more practical version of the tools that already exist.

    Are we all supposed to switch from Sketch now, just to run into the same problems we already have?

    124 points
    • Leah PrinceLeah Prince, over 5 years ago

      I absolutely agree with this. Spot on.

      11 points
    • Darrell HanleyDarrell Hanley, over 5 years ago

      I think that in order for the industry to make a seismic shift to other tools, like the great migration from Photoshop to Sketch, we need a design tool that fundamentally rethinks how we design, and until that happens, everything will be an alsoran of Sketch.

      That, or there needs to be a fundamental design problem that Sketch doesn't solve that's really important in order to force migration, like how Retina devices forced people off of Photoshop and into vector based programs.

      10 points
    • Powers Gray, over 5 years ago

      I always kind of chuckle when I see UI gifs and heavily animated prototypes. I'm sitting here thinking - good luck finding a dev who can do that, and good luck making that turnkey enough that it'll be approved in a real-world business setting. There's a reason nearly all of your apps don't look like any of these prototypes you see nowadays.

      Lottie is a great tool and I'm starting to see it peppered in here and there, but mostly in loaders and onboarding views. I did notice this tool has a panel for exporting swift code, which is cool and I'm interested to check that out.

      I think what really needs to happen is Apple needs to buy Invision and then integrate this tool right into Xcode - then we'd have something to talk about.

      11 points
      • Ryan Hicks, over 5 years ago

        Apple buying invision would be awful.

        22 points
      • T LT L, over 5 years ago

        Because it is hard. When you build prototypes you don't need to deal with layout, touch interruption, loading data asynchronously, errors and so on. You design in the ideal world.

        And to be honest today toolkits are not really designed for UI that you would like to achieve. Mostly due performance issues because you animate static images, but once you start animating stuff that needs to be recalculated and redrawn each frame it starts to be pretty complicated (and possibly slow).

        0 points
    • Jonathan De Heus, over 5 years ago

      I think that Framer is actually going to go in the direction that you want. What I think is going to happen over the next year or so with Framer is that they're going to still keep the code portion in place, but add more UI elements in the design tab of the tool that will let users implement interactions. If users want to modify the interactions beyond what's offered in the design tab, they can switch over to the code tab.

      7 points
      • Tom ReinertTom Reinert, over 5 years ago

        Yes, I hope so, too.

        0 points
      • Giedrius JaloveckasGiedrius Jaloveckas, over 5 years ago

        Problem is that Framer doesn’t produce production-ready code, which means you spend even more time manipulating pictures of your product, instead of manipulating the product itself. That’s the real problem.

        7 points
    • Mattan IngramMattan Ingram, over 5 years ago

      Seriously, how many Sketch clones do we have now?

      Symbols != Components. Symbol overrides != States.

      Why is the idea of having a hover state or scrollable sections so outlandish?

      11 points
      • Luca Candela, over 5 years ago

        Check this out, I hope they internalized some of the ideas of this tool. I love Antetype but looks like Ergosign might have lost interest in developing it. Still, worth checking out:

        0 points
    • Nikola DurkanNikola Durkan, over 5 years ago

      Completely agree. Overrides are a poor man's states. Also, there are a few different components that have predictable logic, such as input fields, so why not build a simple way to toggle between state based on that logic? I think it's crazy that most of the prototyping tools still don't accept text input .

      4 points
    • Zack Brown, over 5 years ago

      Hey Tom —

      What we need is a tool that creates living components.

      YES. I 100% agree with your vision of the "next generation" of design tool, and that while impressive and certainly improving designers' lives iteratively, the Figma-InVision arms race doesn't address our most fundamental pain: that "design" pixels and "app" pixels aren't connected. "Export code" isn't good enough, and "developer hand-off" is the PROBLEM, not a feature.

      Have you seen Haiku? I'm on the team, and have dedicated the last several years of my life to solving exactly this problem.

      Here's an example of a simple interactive component one of my teammates made visually with Haiku, with only a sprinkling of code

      If you're interested in an invite, I'd be happy to send you one if you sign up for our beta and shoot me an email at

      8 points
    • Jonathan ShariatJonathan Shariat, over 5 years ago

      Playing with Webflow is like this. I wish it pluggin into backend more and was worked on as a design tool at this lvl. (plus mobile)

      0 points
    • Adam T.Adam T., over 5 years ago

      Check out Fractal

      Found this to be a step towards that - a living pattern library you can set to interpret component-based CSS with a little Gulp config. You can then expose the components via an API.

      0 points
    • Or Arbel, over 5 years ago

      This is us :)

      While with Launchpad you can create a short film, it is a first step towards empowering designers to create a complete fully featured film.

      0 points
    • Matt MilosavljevicMatt Milosavljevic, over 5 years ago

      I think you’re looking for Flinto.

      What we need is a tool that creates living components. Just let me create components and let them have multiple states based on click-, hover- and scoll-events. Then, let me build a view consisting of those components.

      Flinto does exactly this.

      0 points
      • Tom ReinertTom Reinert, over 5 years ago

        yes, I'm a huge fan of flinto. but i think it's optimized for micro interactions. kind of hard to build a whole system. also, no logic - compontents cannot interact with each other.

        again, flinto is awesome. but it's still an artboard/image based tool.

        2 points
    • Dominik LevitskyDominik Levitsky, over 5 years ago

      I don't know. What's the solution here, you think? Creating a tool that lets you output fully functional frontend logic without the need to code? If, in theory, that would be possible, it would still be only frontend, without backend. And create a tool that lets you do both? Probably not possible. And even if possible, every design/client/solution probably needs a different technological base (e.g. one use C#, the others use Node.js) so connecting that to the design in a single tool would be probably impossible too.

      So this leads us back to the possibility of a tool, that would let us to create fully responsive (real) frontend part of the app/website. But again, it would not be functional: no data would be transferred from the databases, no real login, no nothing. So if you think about it, you would still just have components and theirs states with animations. And this is pretty close to what we have now.

      Isn't it?

      0 points
      • Tom ReinertTom Reinert, over 5 years ago

        I wouldn't say we need fully functional frontend logic. Basic interaction would suffice, like we have in most prototyping tools today. But not based on connecting screens, but on single interactive components.

        It's hard to describe it with words alone, maybe I'll need to mock it up ;)

        0 points
        • Dominik LevitskyDominik Levitsky, over 5 years ago

          I think I got what you mean. But it would probably still need some "states" of the app/website, that would represent different screens, and this will be like artboards in some way, anyway.

          0 points
    • Kevin C, over 5 years ago

      Subform is a tool that's a WIP that address your needs.

      Not release yet, but their philosophy addresses your issues:

      3 points
      • Tom ReinertTom Reinert, over 5 years ago

        I actually did get a beta invite the other day. But I didn't see prototyping in there, so that was a turn off.

        1 point
    • Scott HutchesonScott Hutcheson, over 5 years ago

      1000% agree

      0 points
    • Cody IddingsCody Iddings, over 5 years ago


      Seriously. Get into it. Does what you want.

      2 points
    • Michael Nino EvensenMichael Nino Evensen, over 5 years ago

      I totally and completely echo this sentiment, but I think we're back at square one if we need to create custom tools that mimic what it means to just sit down and build the components yourself just because designers won't code. It's completely absurd. HTML, CSS, React, Swift, XCode are all really really well thought out ways of building things, why the fuck should one company or any company for that matter over-invest in creating this made-up fairly-tale simple tool / language which basically mimics the actual way of building and translating design into implementation when the step to actually building it is so incredibly small? Framer is just Coffeescript which is syntactical sugar on top of JavaScript. I hope for the love of god no one attempts to do this because it further helps design to stay away from actual implementation, and I would even go so far to say that it helps dumb-down our roles as designers.

      1 point
      • Tom ReinertTom Reinert, over 5 years ago

        Very good point. I feel the same way, but on the other hand I think that designers need a way to quickly mockup ideas without having to code. You might say that this is what our current tools do, but then again they behave in a way that has very little to do with how the final product works.

        When I think about this topic, I always end up googling "learn react". but then I just can't pass the boundaries.

        I'm not sure that we can completely close the gap between code and design, because designers are designers and coders are coders, both with very different mindsets.

        What I am imagining is a tool (or process), that narrows the gap as far as possible.

        2 points
      • David ThornDavid Thorn, over 5 years ago

        I code fine, and I have zero desire to setup an entire project environment with html and css and lord forbid javascript just to prototype very simple interactions.

        0 points
    • Berend Holtland, over 5 years ago

      I agree. I think the future exists out of components. With symbols we're slowly getting there. Think about it. You design something with symbols. And with the click of a button you can export React Components. In reality this is alot more difficult of course. But it sounds good.

      0 points
    • João FaracoJoão Faraco, over 5 years ago

      Designers should code, but won't

      This is very true. I have been experimenting with, where I can focus on programming instead of writing code – there is a big difference. With Bubble, you can actually create a living project that uses real data, repeating components, component styles and pretty advanced logic without writing any code. It's quite impressive and has been fundamental for us to build high fidelity prototypes that communicate our intent to testers and developers.

      1 point
      • Luca Benazzi, almost 4 years ago

        In fact I believe that despite all the limitations, Bubble (or its evolution) IS the tool we are talking about. It's not advertised as a prototyping tool and it's still not user friendly and flexible enough, but it does allow to program without writing code, and includes conditional logic and database management, something that only Axure can do. But Axure is a prototyping tool, it mimics that only, is mostly limited to front-end, and the code is not production ready. Bubble code is.

        0 points
    • Koen Bok, over 5 years ago

      Kind of like Framer, but way simpler. Designers should code, but won't.

      This is a fun one for me. Because it's kind of true.

      More designers than ever are learning programming and are able to solve most of the problems you describe through it. Code is just such a powerful tool.

      But a lot more are waiting for some new innovation so they don't have to learn an intimidating new skill and still will be able to do everything you describe. I hope that invention will come – and we will certainly try to build it – but I'm not sure if it will (in time).

      So we'll continue to try and innovate here, while we not so secretly try to teach every designer how to code too. That's going quite well, and very fulfilling to see work.

      1 point
    • Andree Huk, 5 years ago


      0 points