89

Design tools are missing the point

over 5 years ago from , Lead UI/UX Designer

I've been following progress and discussions around new design tools for a while now (especially Adobe XD). I'm excited to see so much interest in creating better design tools. But they're all missing the mark for me.

Just to give you a little background to where I'm coming from, I do UI & UX design for games. Previously I was working on web and mobile apps. I also spent quite some time with VR UI.

To cut to the chase, here are a few gripes I have with the current direction of design tools.

UI is inherently stateful, artboards suck at that

If you're building a more complex application with intricate interactions, the artboard approach is very inconvenient. I don't want to duplicate an entire design to simply show a hover state, for example.

This is where Layer comps in Photoshop excel. I can show however many states I need without having to duplicate layers. It's clunky and could be improved a lot, but I find this to be the best way to design UI components. Just being able to switch to a state without having to move around the document can in a way simulate interactions (more on that later).

Screen to screen prototyping only works for simple mobile apps and web pages

UI design (and these days web design as well with single-page web apps) is more about interactions rather than page-to-page transitions.

This is why I don't believe the Adobe XD approach is the way forward. It's simply too limited, and this won't be solved by adding more interaction types and more animation presets.

Typically the stuff that you actually want to prototype are the more complex interactions. And this requires something more powerful than simply drawing lines between entire pages.

In addition, this type of prototyping is almost entirely mobile focused. There's still plenty of web and desktop design to be done, and hover effects are an important aspect of that.

Animations should be better integrated to the design process

This is something that no design tool has managed to properly capture yet (although InVision Studio shows promise). Being able to easily add animations and see the result while you're designing is I think an extremely important aspect of UI design and it should be integrated into the process better, just like changing the color of a layer.

Simply having fade-in and fade-out presets on whole screens is not enough. We need more control over animations. A full on timeline editor might be overkill, but something that still gives me the power to animate individual parts of the screen from one state to another, like in the below example, makes a whole lot of sense in my mind (imagine the states on the side being something akin to Layer comps)

A simplified timeline implementation that lets you exactly define how elements transitions from one state to another might not be too bad (not saying that's the best solution).

Also seeing the result without having to do an 'export' or press the Preview button would go a long way to make animating UI much better.

Separating all raster work from a UI tool isn't perfect, at least for me

Here's perhaps the main reason why I still use Photoshop. In the designs I usually end up working on, I have to do a lot of mixed raster and vector work. I don't want to have to change program to desaturate a thumbnail or darken some part of an image, or using perspective distortion on a layer. This is why I see much promise in Affinity Designer's approach. It lets you switch to a raster persona that has those tools that you can quickly switch to, and still have all your layers without completely changing context.

Plugin support

It's a must. As a tools developer you will never be able to cover every users' use case. And you shouldn't have to. Let them do it themselves. Having a nice API is always a plus too.

The perfect design tool

There is likely never going to be a perfect design tool. I also understand the point of view that it doesn't make sense to cram every possible tool into one software package. But some middle ground can be found I think.

I end up making a lot of mockups of how a given design looks in different states. So to me it makes a lot of sense to have a design tool that is based more on states than whole full pages. I think artboards still play an important role, but that shouldn't be the full story.

Using states it's then also much easier to implement more powerful animation and prototyping tools, like the example above.

TLDR: I think we need states in UI design tools. Layer comps were a good thing, just need to make them work nicer and use them for for animation and prototyping.

Also sorry for the clickbaity title. :)

61 comments

  • The Night WatchThe Night Watch, over 5 years ago

    So in other words, the perfect design tool is... Code ?

    32 points
    • Philip A, over 5 years ago

      I agree. The flogged horse of designers coding aside, if you are a web designer who doesn't care to learn how to animate using CSS, or care about the size of that .png you gave the developers, you're missing the whole point.

      My UI design tools are html/css using emacs/git. I use Sketch and Photoshop just to create graphical assets where necessary (svgs, pngs and so on). All UI and interaction design is done in HTML and CSS. The software team I work on wouldn't want it any other way. The improvements in efficiency and final product quality are too great to revert back to creating UI's in software tools like Sketch or Photoshop.

      Getting a single piece of software to replace the above workflow would end up in a huge jumbled mess. It's why we have a large assortment of design tools which fulfil various needs (UI designs, prototyping, animations and so on). No single tool can do it all. HTML/CSS (with a sprinkling of JS) can.

      8 points
      • Bobby AndersonBobby Anderson, over 5 years ago

        The software team I work on wouldn't want it any other way

        I wonder why

        4 points
        • Philip A, over 5 years ago

          I'm generally curious why you wonder why. For them a spec that has an HTML prototype is so much more valuable than a static .png. I'm able communicate state, interactivity, animations, responsive design (and more) with a single URL. Unless I missed your sarcasm lol.

          1 point
    • Marc EdwardsMarc Edwards, over 5 years ago

      In many cases, I’d say code is the worst design tool choice. Code is incredibly flexible, but it’s slow and expensive to work with. It’s not visual. It requires skills that many designers do not possess.

      The point of a design tool is to work things out before committing to code. If you’re in a situation where writing code is quicker and easier, then sure, do that. That’s definitely not an approach that works all the time though, especially with native apps and lower level languages.

      39 points
      • John Sherwin, over 5 years ago

        I agree with this but would also say code helps overcome a lot of the creative 'ceilings' you hit in Sketch, Photoshop, InVision, Principle etc. What I hate about these tools, or any design tool for that matter is that we're at the mercy of some company and their roadmap. No amount of manual control over animations or transitions will ever be enough if designers remain dependant on a tools UI. I've lost count of the amount of times I came up with an idea I couldn't design because the tools I was using simple didn't have the features I needed. Eventually I gave in and learned to code and I've never looked back. Framer is my tool of choice because I can express my ideas freely and quickly in code without worrying about writing performant, production quality code. Plus, my main deliverables now are not rows of static mockups, they're realistic prototypes, which I've found go a lot further in helping to sell ideas to devs and stakeholders. I think code is the best tool designers aren't using. Just my 2c. =)

        2 points
        • Riho KrollRiho Kroll, over 5 years ago

          Interesting perspective! I'd be curious to know what kind of ceiling were you hitting with the design tools you mentioned? Why were they not suitable?

          0 points
          • John Sherwin, over 5 years ago

            Basically anything more complex than simple animations or linear flows these tools fall flat on their face IMO. If you needed fine grained control over a drag and drop interaction with conditional logic and a couple of states theres no way to achieve it, definitely not in a robust enough way to hand a prototype to someone in user testing for example. Also, not being able to design with device API's, forms, user input, camera access etc. means you're constrained to drawing pictures of an experience, when with a little bit of code we can just actually design the thing, exactly as we intend it to be built. What happens when you throw AI, VR, AR etc. into the mix?

            1 point
            • Karl Sander, over 5 years ago

              It's one of those "you need 10 tools for each specific aspect" things, but I like Quartz Composer + Origami (or Origami Studio now) for those kinds of interactions.

              It also sort of has the benefit (and downside) over code that photoshop etc have: You can potentially do things easily that are very hard for developers to implement. That's annoying for them, but It can also lead to doing things that haven't been done before.

              And it's just programming by another name, so It's not something to use because coding is complicated but because it gives you a more creative/fast environment to try things out.

              I wouldn't really want to build a prototype that is even complete enough to hand to a user though.

              0 points
              • Marc EdwardsMarc Edwards, over 5 years ago

                It also sort of has the benefit (and downside) over code that photoshop etc have: You can potentially do things easily that are very hard for developers to implement.

                AKA the After Effects effect. :P

                As you’ve said, it can lead to cool results. You just have to be careful and discuss things as you progress.

                I wouldn't really want to build a prototype that is even complete enough to hand to a user though.

                Nope. And for that purpose, some of the simpler, but higher level prototyping tools are great! If anything, this is yet another argument for having lots of prototyping tools at our disposal.

                1 point
        • Marc EdwardsMarc Edwards, over 5 years ago

          I agree with this but would also say code helps overcome a lot of the creative 'ceilings' you hit in Sketch, Photoshop, InVision, Principle etc.

          They definitely have limits, and code is limitless. Using a visual tool should save you time. And, if it’s not, I agree to not use it.

          I think it’s important to make a distinction between working things out and implementation. I find using a visual design tool saves us a lot of effort, because we can make a lot of decisions in an environment where things are quick to change. Code’s flexibility comes at a cost.

          I have a slightly different style of working — I am happy for my prototypes to be a little looser, but once the developer has set up the code, I’ll go in and tweak it. It means we’re not locked into the prototype. It’s just a stepping stone. I’m not saying that’s better, just different. There’s many ways to make this stuff work.

          I've lost count of the amount of times I came up with an idea I couldn't design because the tools I was using simple didn't have the features I needed. Eventually I gave in and learned to code and I've never looked back.

          That’s great! Framer really shines with interactions that are not possible in other prototyping tools.

          1 point
          • Greg Warner, over 5 years ago

            I have a slightly different style of working — I am happy for my prototypes to be a little looser, but once the developer has set up the code, I’ll go in and tweak it. It means we’re not locked into the prototype. It’s just a stepping stone.

            I love and share this approach—I think it's important to quickly work through levels of fidelity, sometimes from a quick paper sketch to artboards focused on visual design and asset generation to a click-through prototype or a slightly higher fidelity prototype, where I'm trying to figure out one interaction. Then from there, jump into code after production begins to assist in refining.

            1 point
            • Marc EdwardsMarc Edwards, over 5 years ago

              I think it's important to quickly work through levels of fidelity

              YEESSSSSSSS!!!!!! 1,000,000 × this.

              Sometimes you don’t need the initial steps. It’s a spectrum from quick and low fidelity to slow and high fidelity. None are wrong, and if you need them, the initial steps can save a lot of time and allow for exploration that would be uncomfortable and unlikely to happen as code.

              0 points
    • Sir KailaSir Kaila, over 5 years ago

      this is it riho <3

      1 point
      • Riho KrollRiho Kroll, over 5 years ago

        Hey Sean! :D I go with what Marc said above. It can work and I actually do use code for prototyping, but only because it's the only thing out there now that provides powerful enough prototyping and animation tools. If those were part of a design tool in a decent way, I wouldn't touch code until implementation.

        0 points
    • Ivan MirIvan Mir, over 5 years ago

      Sounds more like the Flash CS to me – a mix of designs and basic scripts.

      2 points
      • Olivier FOlivier F, over 5 years ago

        I seem to recall back in the late 90s early 00s designers could open Flash and create very rich and interactive visuals with animations. It seems that work well.

        The big problem now is that frontend "code" means setting up a toolchain and setting up myriad dependancies. It means learning this framework, no wait that framework too.

        With Flash it was all baked into the program so that designers (or anybody) could make use of it without additional burdens. (at least that's my understanding of it, I didn't use it).

        2 points
    • Bent StamnesBent Stamnes, over 5 years ago

      More or less, yes. There are so many things that can only be described in code. The trick is to make that code accessible and manageable for people not well-versed in it.

      0 points
  • Marc EdwardsMarc Edwards, over 5 years ago

    I agree with most of your points, except I am not sure I want it all in one tool.

    There is probably a bigger, more fundamental discussion that needs to be had — how far do you want to take things in a design tool? Do you want to almost be able to build the final product? If so, would you then want to be able to output code? I think we’ve been there before with FrontPage, Dreamweaver and others. It’s not good, except for some specialised cases. Please note I’m not saying you’re suggesting that, I am saying that is a possible logical conclusion, and a place we’ve been before.

    I personally prefer my main design tool to not be linked to a specific execution or platform — want to use it to design for the web, iOS, Android, games, macOS etc. With that in mind, I do not want a tool that is tightly coupled with CSS grid or Auto Layout or Core Animation etc. I want it to be a nice superset of the most critical visual features. In cases where I do need to help generate specific output, I’ll use a specialised tool, like PaintCode if I want Core Graphics code.

    UI is inherently stateful, artboards suck at that

    Yep. Artboards are good at seeing a range of potential designs, but bad at representing state. Artboards are broken in lots of other ways, but I agree that the general concept can be good for some uses (seeing lots of alternate designs side by side).

    I agree that layer comps are better, but as you’ve said, the idea isn’t perfect. It was created to help manage versions of retouched images, and it’s good at that, but not great at managing states. You can use them in various ways that helps, but they’re very clearly not made for this purpose.

    Simply having fade-in and fade-out presets on whole screens is not enough. We need more control over animations.

    I see the value in many types of prototyping, and I don’t think I’d want to be restricted to just one. There’s currently a wide spectrum, and I think they’re all good, at different times? Principle and Framer are great a single interactions, Flinto is better for a wider scope, XD and InVision are better for an overall view of the product (yes, some of those tools cover other uses, too).

    I’m not sure I want integrated animation and prototyping. I’d rather have good ways for keeping prototypes in sync. And even then, prototypes will be replaced by production code. Could prototypes be kept up-to-date with the production code? Maybe. Should that even be a goal? Maybe?

    Separating all raster work from a UI tool isn't perfect, at least for me.

    Yep, I agree. I guess this again gets to an important question: What would you like integrated into your main tool? What would you like as separate tools? Asking for too much in the main tool means you’ll end up with a monstrosity that doesn’t do anything well. Having a workflow that’s too fragmented means issues when moving between tools.

    I’d honestly settle for something that got the basics right. Many tools struggle with rendering without glitches, are slow to use (workflow), are slow (performance), aren’t colour managed well, have incredibly basic masking abilities, have broken shape boolean ops, and exporting is an afterthought, rather than part of the foundation of the tool.

    It may not be what everyone wants, but I would like a tool that is robust, fast to use, has excellent visual design abilities, has good state support, and doesn’t tackle animation or prototyping, but does allow good integration with the wide range of prototyping tools that exist.

    I want something that integrates better with developers, too.

    14 points
    • louie solomonlouie solomon, over 5 years ago

      Regarding artboards, I'm not sure it has to be one or the other, i.e. artboards vs 'states'.

      Artboards are great for quickly iterating through ideas, comparing and combining concepts and being able to see those ideas side by side. For that reason, I can't imagine going back to a tool that requires me to view and work on one screen at a time.

      Artboards are not great, as you mentioned, for showing states. But I see component and screen states existing within artboards, working more like elaborate symbols that can enable, disable, or change layers within.

      Another thing which I'm excited to see in Subform, and hopefully in other design tools, is classes, which allow multiple styles to be applied and stacked on layers.

      3 points
      • Marc EdwardsMarc Edwards, over 5 years ago

        I think artboards are fundamentally broken in terms of how we interact with them. I realise they’re the best we have right now, but if we’re dreaming up future tools, I would want something different that avoids all or most of the issues.

        But I see component and screen states existing within artboards, working more like elaborate symbols that can enable, disable, or change layers within.

        Absolutely!

        What would you want?

        1. Showing variations in X and Y space (artboards)?
        2. Showing variations in stacked space (layer comps)?
        3. Both?

        I see a lot of value in things being stacked, where you spend less time panning and zooming, and where deltas are more obvious (subtle changes are far easier to pick up via temporal shifts where the new thing is shown where the old one was, rather than space shifts with different versions next to each other).

        I think we likely need both, but in their current form, artboards are pretty bad, and ultimately fragile to work with. They require so much time managing their deficiencies.

        4 points
        • Matt C, over 5 years ago

          You're describing technology that mostly already exists - it's just the presentation that is currently lacking. You can already have components/symbols that demonstrate various states, but when it comes time to present it's still an arduous prototype generation or a fundamentally flawed PDF walkthrough.

          I think design tools are getting damn close to allowing us to create a click-through prototype, but instead of just linking artboard to artboard we'll be linking symbol to symbol selecting overrides ad-hoc. It's really not that far off, and it doesn't take some sort of radical fundamental re-imagining of design tools as they exist today. imo

          4 points
          • Riho KrollRiho Kroll, over 5 years ago

            That's a bit closer to what I had in mind. I'm not suggesting we need another tool to be built from scratch. Most of the design tools have the basis already there, just need to add states and make them work in a nice way.

            1 point
    • Riho KrollRiho Kroll, over 5 years ago

      Hey Marc, thanks for sharing your thoughts. :)

      I think you hit on a good question there about how far do we want our design tools to go. I actually do think that the eventuality is implementation and design merging into one thing (I say thing because I don't really know if this is really one single application). This might sound ridiculous now, but I think this will make more and more sense over time. It probably won't be built out of the tools we have now. This will become especially important in AR and MR interfaces, where the visual appearance and functionality is not really possible to work with separately (I had to do that with VR and it was an extremely painful process to say the least).

      What we're doing now is essentially double or triple work. A designer makes the mock-ups and then those are recreated in a prototyping tool and/or animation tools and then recreated once more when implementing (or some combination of those). At each of those stages you want a consistent result and breaking those up into separate steps inevitably creates inconsistencies and the need to keep things up to date.

      This workflow is broken, and I don't think this meets our needs now and especially not in the future.

      This doesn't have to mean we have to have CSS layouting and javascript logic in our design tools. Those might do the rendering in the end. We can build much better dynamic layouting tools, if you forget CSS exists, or only 'compile' to CSS if need be. There's some early promise for dynamic layouting with repeat grid in Adobe XD, but this is too primitive still.

      In Sketch there are also already plugins that let you use real-world API data inside your designs. Clunky implementation and not polished yet, but again, I think it shows promise.

      When it comes to app logic, I think this can actually be achieved with dragging lines, but not between artboards. Those lines could be drawn from component to component and state to state, and when that's not enough (and it won't be) there's also a more powerful way of doing logic visually. I have a lot of faith in Visual Scripting tools from game engines, such as Blueprint from Unreal Engine. I can see the potential of this being used as a tool for building apps without writing code.

      The old Dreamweaver and Frontpage approach was flawed. It married code to design. What I'm suggesting is to completely decouple them. The design is the intent and 'code' is the engine responsible for simply presenting that intent, which can then be replaced by whatever engine is needed for a given platform or need. This makes the design the source of truth, and removes the need to constantly re-implement the same behaviors across platforms. This is one of the reasons why React Native has taken off so well.

      Again, I realize this sounds ridiculous today, with the tools we have now. But I really don't see how this wouldn't eventually happen anyway. We're already going towards that direction, we just don't have a clear focus on it yet. I don't know what the tool(s?) will look like, I have a rough idea of what I think might make sense.

      This is not to say that I think coding will go away. Just as Visual Scripting tools didn't make game programmers obsolete. It just shifted their focus to providing tools and generic components for use by designers.

      ANYWAY... Back to today.

      I think having layouting and visual design, prototyping, and animation in one tool is possible in a sane way using states. It sounds more scary than it really ought to be. I have faith that we can marry those in a fluid and simple way (like literally seeing animations and transitions between states on the document, while you're designing).

      I have to agree with you about rendering quality. It's simply inexcusable for a visual design tool to have any sort of rendering artifacts.

      So for me what I would want in one tool is visual design, dynamic layouting tools, states and then couple states with animation and prototyping in some nice way. I have ideas for that, if I get some time I'll write about it.

      3 points
      • Marc EdwardsMarc Edwards, over 5 years ago

        This might sound ridiculous now, but I think this will make more and more sense over time.

        Ridiculous is good! Aiming high is good! I think you’ve hit on some great points, and the industry isn’t addressing them now.

        This will become especially important in AR and MR interfaces, where the visual appearance and functionality is not really possible to work with separately (I had to do that with VR and it was an extremely painful process to say the least).

        I can imagine AR and MR would make the current tools even more unsuitable.

        What we're doing now is essentially double or triple work. A designer makes the mock-ups and then those are recreated in a prototyping tool and/or animation tools and then recreated once more when implementing (or some combination of those).

        Yep, it could definitely be smoother. I don’t inherently think double or triple work is bad — the initial pass aides in thinking and can evolve quickly, my prototypes are usually Hollywood sets with giant faked bitmaps to give us the starting values for the code, and the code is the real deal. Some repetition, but each stage is optimised for a different thing, and not all work is replicated. But yeah, it would be great if there was a nice way to keep these things in sync better.

        Again, I realize this sounds ridiculous today, with the tools we have now. But I really don't see how this wouldn't eventually happen anyway.

        I don’t disagree, but I can think of two good counterpoints (for the sake of the discussion and completeness):

        1. It is in the platform vendors best interest to not have this happen. The last thing Apple wants is for everyone to build iOS apps using React Native and not using Swift and their own APIs.
        2. Platforms keep evolving, and platform agnostic engines have to continue to add and deal with platform specific APIs. Those will keep coming, given point 1.

        It’s been the promise since the dawn of computing (Java and Swing, anybody?). That doesn't mean it’ll never happen, but I think we’re likely to still have vast mix of native and platform agnostic tech in the future, as we do now.

        Thanks for giving me a lot to think about, and for this discussion.

        0 points
      • Philip A, over 5 years ago

        So much yes. Please blog about this :)

        0 points
  • Bianca Mangels, over 5 years ago

    I think Fireworks was on a good way regarding states. The user designs pages and each page can have different states. In combination with symbols (that already had basic scripting abilities) and the ability to share layer-folders to all states, Fireworks was a very powerful tool. Of course it had other major drawbacks, but the core ideas are still pretty good regarding these issues.

    8 points
    • Account deleted over 5 years ago

      Fireworks was the shit. Only people that never used it think otherwise.

      5 points
    • Riho KrollRiho Kroll, over 5 years ago

      I agree. There's plenty to criticize in FW, but some of the concepts were not inherently flawed.

      0 points
    • Sven LoskillSven Loskill, over 5 years ago

      Second that.

      I had applied custom key commands for cycling through states (⌘ + Cursor Up/Down) and pages (⌘ + ⇧ + Cursor Up/Down) which resulted in (I admit very basic but for that time quite sufficient) presentable app- and website-design-flows – pretty similar to todays prototyping-tools.

      Designing too was a process more akin to trickfilm, where you draw one frame after the other (which by the way is how apps and websites are comsumed anyway) – and not that pan-intensive ill-driven magazine print-design approach from the former era, where you lay out one page next to the other.

      Not one tool today has the flexibility and robustness (I’m looking at you you f**** finicky PS layercomps) of this simple state/page-combo – combined with a smart designer who knows how to use them.

      [Edit:] Oh, and yes I’m aware of the plugIns for Sketch who try to approach that – but this needs to be deeply build into the concept of the tool (and the tool itself), otherwise it’s an afterthought which breaks all too often (looking again at you again, layercomps)

      0 points
    • Marc EdwardsMarc Edwards, over 5 years ago

      Adobe really, really, really should have rebooted Fireworks, rather than killing it. :/

      3 points
  • James GreigJames Greig, over 5 years ago

    Check out https://compositor.io/ for a vision of what's possible when design meets code.

    The video in this tweet gives a good overview of how it works...

    https://twitter.com/getcompositor/status/936527770607341571

    4 points
  • Adam Bitner, over 5 years ago

    Many of these reasons are why I refuse to leave Axure

    4 points
  • John PJohn P, over 5 years ago

    Separating all raster work from a UI tool isn't perfect, at least for me

    Trying to cram everything into one app is a mistake for me, if you look at 3D and videogame tool pipelines which are at the forefront of creativity and make 2D UI tools look like a bad joke they definitely don't approach it this way.

    The trick is to have pipelines, ability to load assets and auto-updating. E.g if I want to edit how a chair looks in a videogame I don't do that in the game engine, I do it in my 3D tool and the game engine updates on save.

    Plugins and extensibility is huge though, I even find sketch a bit anaemic in this and Adobe stuff (except AE) are a joke.

    3 points
    • Marc EdwardsMarc Edwards, over 5 years ago

      I agree. Pipelines and better production flows are the way to go, with specialised tools handling their specialised tasks (in some cases that scope might be big, in others it might not be). Everything should be automated and part of the development workflow. A design tool on its own island (or cloud) isn’t much use, from this perspective.

      1 point
  • Todd FTodd F, over 5 years ago

    The term "UX" has been appropriated by people who make tools for screen-based user interfaces. Human interaction with modern technology happens in a lot more ways than just clicking on screens (voice, gesture, etc) My usual reply the mentioned tool makers crowing about their new features is "who says there is a screen at all?" These guys are stuck in the past.

    2 points
  • Thomas LoizeauThomas Loizeau, over 5 years ago

    So you're basically describing Sketch with only 2 additional plugins that are http://states.design/ and http://principleformac.com/

    Seems to me like Sketch is actually exactly on point.

    2 points
  • Rafael FernandesRafael Fernandes, over 5 years ago

    Check subformapp.com and haiku.ai. Maybe these can solve the component states issues.

    2 points
    • Mikael StaerMikael Staer, over 5 years ago

      Wow Haiku looks great. Like the ideas above about a pipeline, it takes the asset from Sketch, focuses on building out animations with final result in code that can be used in a frontend, which itself is built out in another tool.

      We need all our tools to communicate much more closely. Or have open APIs or something similar. Could Haiku be modified to export animations into a different language, if you weren't using React?

      Compositor (above) is also doing something very interesting. Have been watching the development for several months now, and they are updating and iterating so fast.

      0 points
      • Nad Chishtie, over 5 years ago

        (I'm on the Haiku team) — yes, it can be used with frameworks, everything created in it is just pure JavaScript.

        We'll add more wrappers but so far we've only shipped React for the web while in beta, and native iOS/Android renderers powered by Lottie.

        0 points
  • Artur MaklyarevskyArtur Maklyarevsky, over 5 years ago

    for now there is this: http://states.design/

    2 points
  • Samantha S, over 5 years ago

    so basically Axure + sketch + photoshop hybrid

    1 point
  • Vlad Danilov, over 5 years ago

    States eliminate repeating work. They naturally expand to artboards and allow exportable symbols with per-resolution adjustments.

    I even implemented the latter in the plugin for Photoshop a while back. But that alone would not fix it.

    1 point
  • Josiah TullisJosiah Tullis, over 5 years ago

    I like to think of design tools as a spectrum between an idea and implementation. The closer to the "idea" side of the spectrum you are the easier designers are going to find it to work with. The closer to the implementation side the more performant the design will be, but also the more overhead and learning curve it will require. Considering this, I actually think design tools are in a real golden age.

    1 point
  • Jack HallahanJack Hallahan, over 5 years ago

    Recently I've been coding some of my design prototypes in ReactJS to combat these issues. React is built with components rather than pages, and is stateful at its core. Of course it's not without its tradeoffs, there is a steep learning curve and some things can be difficult, even things that are trivial with other tools.

    It's not for everyone, but if you're interested I wrote a short post talking about how and why I use React for design.

    1 point
    • Riho KrollRiho Kroll, over 5 years ago

      In a way what I'm asking for is something like React for design. I think the declarative way of working shows promise for both code and design.

      1 point
  • David ThornDavid Thorn, over 5 years ago

    Stay away from my artboards.

    Task the infinite monkeys with fixing symbols.

    1 point
  • Corin EdwardsCorin Edwards, over 5 years ago

    I'm not sure if these tools are missing the point in as much as they haven't landed on complete solutions yet.

    The statelessness of artboards aren't a symptom of rectangles, they're a failure of design.

    I'm not a big fan of clunky layer comps either, but I do agree they are a direction to move towards. However I can sympathise with tool makers not wanting to commit to an unresolved and clunky direction.

    1 point
  • shmulik kl, over 4 years ago

    1 Year later, Still using Photoshop's layer comps for full scale product design.

    0 points
  • shmulik kl, over 4 years ago

    1 Year later Still using Photoshop's layer comps for full scale product design

    0 points
  • Andree Huk, over 5 years ago

    Hi Riho, I do agree that our design tools still have to evolve, especially in regard to states - and those are really missing in tools natively. There is a nifty Sketch plugin out there to which I forgot the name. It allows to create UI states for artboards.

    In regard to artboards: It is just a matter of evolving the concepts of static, 2D artboards into dynamic multi-states ones.

    I do feel that Adobe XD is the way forward. I have been waiting for a workflow that combines wireframes, interaction design with prototyping in a way that XD does. The remaining issues is though that XD still plays catch-up with Sketch and the likes, especially in terms of Open Data. And of course, it is hardly anywhere complete as of now or 2018.

    Here is the bottom line as I see it: A user interface is much more than a collection of nifty interactive UI elements and states. I'd argue the most important aspect of a UI is to communicate its meaning, allowing a user to finish her task at hand.

    UI states are important but in the overall collection of things in a UI they play a smaller role. However, it would be awesome to see Sketch, Adobe come up with some nifty dynamic multi-states artboards or symbols.

    Cheers!

    blended.io

    0 points
  • Charlie McCullochCharlie McCulloch, over 5 years ago

    Probably a bit late to this conversation but one very useful advantage of designing with artboards is that you can see the whole story at a glance. Especially useful for goal-based products. I want to know how many steps I'm asking the user to make in order to see where it can be streamlined

    0 points
  • Phil LegrosPhil Legros, over 5 years ago

    I feel like a lot of the issues you're describing could be resolved with Axure. It doesn't really use artboards in a sense (though one could argue that a dynamic panel is an artboard). And it does have some degree of animation support (though not as robust as something like Sketch + Principle).

    I don't know, I'm just a fan of Axure. Try it, if you haven't yet?

    0 points
  • Thomas Michael SemmlerThomas Michael Semmler, over 5 years ago

    I agree with everything.

    0 points
  • Andrew C, over 5 years ago

    This sounds very complicated.

    Also I've never encountered an easier way to do animations (for web, anyway) than HTML and CSS. And I don't really endorse the "design is code!" mentality at all.

    0 points
  • Jesse Wallace, over 5 years ago

    This is ultimately most of my gripe as well. The popular ux tools for prototyping don't do much other than give you the most base of interactions possible, and simply don't allow prototypes to feel as real as they should.

    I think the best tool out there for stateful design that includes animation is [Proto.IO](www.proto.io). It also has the timeline for designing exactly the transition you want.

    You should probably check it out, it checks a lot of the boxes you were mentioning.

    0 points
  • Tom ReinertTom Reinert, over 5 years ago

    I agree – not only because I wrote the same thing a little while ago ;)

    In my opinion, the flow of such a design tool is quite simple and not that different from what we have now.

    From the top of my head:

    1. Create a "symbol" of some element
    2. Go into that symbol
    3. Create a new "state" of that symbol
    4. Name the state (e.g. "hover") and modify accordingly
    5. Switch to prototyping mode
    6. Click on symbol to add new interaction (as we do now to set links to other artboards)
    7. Set: On hover: Change to state: "Hover"
    8. Done

    Of course, there are some details to be worked out and maybe there's an even simpler solution. But for now, this would solve a lot of pain with creating duplicate artboards where one element changes it's state.

    I'm pretty close to mocking up the complete tool now. But I'm also sure, that Framer, Sketch, Figma, XD, etc. will get there eventually.

    0 points
    • Riho KrollRiho Kroll, over 5 years ago

      In that example, I'd almost say you don't even have to connect the hover state. It would just be there as a default state that you can modify if you want and it automatically works. Same for other common states (pressed, dragging)

      0 points
  • CJ CiprianoCJ Cipriano, over 5 years ago

    Hit the nail on the head with animations. Extremely time consuming to design out flows, then go back in with Principle and carve out each interaction.

    0 points