↵

Which tool(s) are you using for designing UI animations?

3 years ago from Thomas Michael Semmler, UI Engineer. I'm a bit mean sometimes

  • Nicolas PythonNicolas Python, 3 years ago

    I know your situation just too good. As I mentioned above it's not really the single feature that made the change for us. It was the combination of cloud based file handling, versioning and prototyping (with animation).

    I totally would also not to switch for the switch's sake. That would be a terrible idea, specially because it's not only about the tool. It's also about the learning curve to relevant people (business, devs, etc.) which costs a lot of money. In our case: we had to consider that elderly POs needed to learn something else than InVision.

    We decided to risk the switch after discovering SmartAnimate. It was just the last bit for us. After the switch Prototypes got better, communication through the whole company got better and never did we have problems with file management or library synchronization anymore.

    As you might have recognized, I'm a huge Figma believer. But not because it does something fancy. It simply saves us a s***t load of time. Not while designing, but while the discussion and decision phase with our stakeholders.

    And for us designers, we are now able to talk "visually" (high quality realtime wireframing) with our stakeholders in front of their eyes - no matter where they are.

    It's a game changer. It's the combination. It's the workflow. It's not the feature. (Shit that sounds like a really bad commercial hahah)

    0 points
    • Thomas Michael SemmlerThomas Michael Semmler, 3 years ago

      It simply saves us a s***t load of time. Not while designing, but while the discussion and decision phase with our stakeholders.

      I do find this interesting to hear that from a designer. I used to do this as well in where I would invite clients into the very early phase of a design. They would sometimes find some obscure detail and would give rather uneventful feedback, something like "can we push that 2 pixels to the left?". But they would then get attached to that specific detail and obsess over it, entirely forgetting the rest of the design "why haven't you moved this to two pixels?" - It's a placative example. It created a narrative of where everything they notice for some reason has to be taken care of from that moment on, because otherwise I have basically ignored their wishes. So I am a bit afraid that bringing the process that close to stakeholders will lead to much unproductive feedback and overhead in trying to manage that feedback.

      I can understand though how that makes a lot of sense to your specific needs. And a lot of designers find themselves in similar situations nowadays. Thanks for your insights, thats super valuable! Its much better to hear actual reasoning instead of being told "go die on a hill" lol

      0 points
      • Nicolas PythonNicolas Python, 3 years ago

        "go die on a hill" haha. Not from my side. That' not helping either of us.

        We know the problem with the stakeholders early in the process as well. What we did is specifically talking a language that fits the stage. We do not allow our team to use the UI Library elements for early discussions. We just do it Wireframes or even more abstract. As soon as a design "seems" finished (but it's nowhere near to that) by using library components, the discussions get heated up. Like you said with pixels etc. The more abstract we are, the more we discuss problems not visuals.

        Figma helps also with that. All relevant people in the same file, gray squares, descriptions and cursors pointing where something is missing. "Here we're missing the VAT information". (I love missing VAT information btw.)

        But once you've got that solved, it's extremely valuable to get stakeholders knowledge as early as possible. And as visuals are consumed much faster than confluence pages, we have a lot of visual discussions. Even with accountant and or sysarchitecture guys.

        for example: we've solved the whole unexpected errors flow visually in figma. It was way easier for all the architects and devs to see what should happen. A pimped flow chart so to say.

        To not include stakeholders out of fear from that discussions is in my opinion the wrong approach. I agree it's a challenge to adapt visuals and discussion style to the production stage. But it's harder to adapt "finished" designs when problems are not fully solved yet.

        And one side-note. In our company I introduced the Design-Process in a totally Dev-Driven Company two years ago. Everybody thought of Design as a "make things beautiful". Therefore I had to include our CEO in early stage discussions. So he saw the value of solving problems, making better products and being faster in development. Being visual with Figma helped a lot. We're now heading towards fully design driven.

        1 point