Episode 5: Mistakes we’ve made so you don’t have to
In this episode Cennydd and Val confess motion design mistakes they’ve made in past projects. They share stories of slow animations, mechanical easing, and why animation is so much more than sprinkles on your ice cream. Don’t miss the helpful tips on how to avoid repeating these same mistakes yourself.
Episode Links
Transcript
Welcome to Episode 5 of Motion & Meaning; a little podcast about motion designer for digital designers. I’m Val Head
And I’m Cennydd Bowles. In our last episode, if you tuned in, you’ll have heard us talking about choreography; this is the idea that by designing elements that move in harmony, you get this wonderful, cohesive feel across the products that you make. Today we wanted to get a bit more practical. Throughout the podcasts to date, we’ve been really keen to try and encourage people to give motion a go in their own projects, because it can be a fairly easy thing to get started with. We also then thought it would be useful to talk about some of the mistakes that we’ve made along the way, so perhaps you can identify some of those, maybe you’re about to step into that territory yourself and maybe you can avoid making those sort of mistakes that we have.
We’re going to get practical and start with all the terrible mistakes we’ve made. Maybe not all of them: the highlights!
Right, it’s a sort of confessional episode, I suppose, this one.
Yeah; if it was all the mistakes this was going to be a really long episode and I probably would not be recording it!
Right! So we’ll keep it maybe just to a couple of war stories each from our respective histories with motion design and hopefully there’ll be something in there you can identify and hopefully tread on safer ground than we trod ourselves.
Yeah; don’t repeat the mistakes we’ve made. Or you can just sympathise with us if you’ve done it too. Anyways! I guess I will start with one. I’ll start with a totally embarrassing story, which was, I feel like it was a really big lesson that I learned and it’s one that I know I see other people learning the hard way as well, but it’s still a totally embarrassing story.
it was kind of not that long ago, I think it was 2011, something like that, whatever. I was working for a small agency and we did a lot of kiosks and stuff so I was working on all the animation for an entire kiosk UI basically. Ironically, this was 2011 and I was doing it in Flash, which is I believe the year Flash died, but whatever! Anyways, I was building this kiosk for this big hotel chain and I was the one designing it and since we were a very small agency, I was the only one who ever really tried it out; the whole time we were putting this together but leading up to the first client presentation, it was just me demoing it for the rest of the team, so I was talking through it while I was showing people what was happening, and everything seemed fine. But the thing was, being the person designing it, I was kind of obsessing over each little animation and just paying so much attention to it that it turns out all the animation was actually ridiculously slow and I had no idea.
So we get to the client presentation and it’s Big Important CEO Guy and Big Fancy Suit because he runs hotel chains and stuff and us the agency people; creatives or whatever, terrible things people would call us, that weird sort of dynamic and he’s using this kiosk and just watching him try to use it and getting more and more frustrated by things because it’s just all going so slow. And I had no idea until I saw that and then it was like this guy who was totally judging everything I’ve just worked on for the last few weeks and he clearly totally hates it and I completely could have prevented it by not being the only person using this ever and having someone who wasn’t so close to building or designing the animations use it so I could see what it was actually like to use it. I never took that step back. So, take that step back, get someone else to use your stuff and see how it works before you’re in front of Big Important CEO Guy. That is my lesson!
Was it one of these things that you realised as he was using it?
Yeah, it was like…
Or he turned round and then shattered your illusions? Was it this ground-swallow-me-up kind of problem as the experiment was going on?
Yeah, it was one of those things as he was using it, we were talking about it and he’s trying to use it and I’m like, oh no: oh no! And you’re like, should I say anything? And he didn’t say anything about it specifically because I don’t think he really…why would he know that that was the problem? Just the whole time I was like, oh God; so embarrassing; oh no. So that was the first thing I fixed when we got back to our office!
Right, absolutely. So, how would you avoid that in future? What are you going to fix, what are you going to suggest to our users?
I think that the biggest thing to fix it is to really test these things out with someone other than yourself; even if it’s a co-worker just be like, hey, can you use this? How does this work for you? I feel like you just need someone who’s not so attached to creating the animation and they can give you a lot more insight into how it actually feels to use. Or even just you a few hours later; if you take a break and don’t look at something for a while and then come back to it, you’re probably going to notice that it doesn’t feel right to use. It’s just taking that look from the side of the person using it versus the person designing it; we’re just to close or in the middle of it. So that’s how I avoid it now!
I love that thing where you’re working on a design and then you’re done for the day and you put it away and you come back to it fresh in the morning and I find that’s really powerful when looking at visual design and changes that I’ve made, but I think it’s also really helpful when working on animation stuff as well because, as you said, there’s a tendency to slow it down to really get into the details and almost to want to show off the animation that you’ve been working on. Reality is, the users don’t really care; it’s there to support what the user is trying to do.
Yeah, you don’t need to shout, “Look, this took me hours: see, it takes three seconds to play. Clearly I put a lot of time into this!”
Right, but if you come back to it the following morning, hopefully there’s a better opportunity to see well, hang on, that’s just kind of painfully slow; it’s on critical path for user that we need to just speed that thing up.
Yeah, you just need to remember to keep checking on that side of it and it sounds so obvious but it’s so easy to forget.
Yeah, absolutely. Let’s go with one from me. This was fairly early in my motion career I suppose, so I was a pretty experienced interaction designer at the time but when I was doing work with clients when I was a freelancer and a little bit at Clearleft as well and actually in my early days at Twitter as well, when really I hadn’t done any kind of motion design other than, this thing needs to open out; you click this and it opens and everyone’s happy. And hey, let’s animate that properly; let’s just not jump from State A to State B.
Yeah, let’s have some transition!
Right, but that’s about as far as my detail went, to be honest. And so I was speaking with my developer colleagues and saying right, it should do this: it should open out. And naturally, those ended up being very linear transitions, going from State A to State B as we’ve mentioned in previous episodes. And I thought that was great! We had that stuff opened and closed and I was like, yeah, that’s good. But let’s tweak it, let’s make it that little bit faster or that little bit slower. I think the problem is, I hadn’t been specific enough and I’d focused on the wrong thing; specifically I was focusing just on the duration of the transition and completely blind to the fact that it was mechanical and un-human and very linear and clunky and I thought, well if I just focus on the timing, then that’s really the only variable here. I just hadn’t spent enough time learning about things like easing and thinking about the physical properties that this interface was meant to have, so we ended up with this thing that really wasn’t impressive, wasn’t slick, didn’t really add to the user experience in any way, but I was just leaning back in my chair going: hey, look at that; it animates!
Did you notice? That thing transitions to being open and they’re all like, yeah, we actually don’t care, I think.
Right, exactly.
I think that’s a good one too and I think a common one where you just, if it’s so new, you almost don’t know what to look for. Sometimes you might even realise, that does look really mechanical, but you don’t know why yet. You don’t know how to fix it. You can recognise these problems but you’re like, what do I do? Thinking about the easing and timing would definitely be a big thing there.
Yeah, absolutely. And I think in retrospect, when I look back on that early dabbling with motion that I did. What I really should have done is cranked open a tool and started to tweak that animation myself, start to prototype it and so on. I was just too comfortable with hand-waving. You know, when you start talking about motion and you start waving your hands around: “Oh, it needs to be more like this,” and you’re gesticulating wildly, saying, “Well, it pops in from the left, whooosh…” I’m doing a hand motion here; you can’t see it on the podcast…
Sound effects!
Yeah, sound effects. Oh, they came into it a ton, right? Which only gets you so far and I just wasn’t wise enough to invest time in just saying; you know what? Let me go and work on how this should work and then having examples that I could show to my developers and so on; there was too much standing over shoulders and saying, “A bit more, a bit less,” whereas actually I should have recognised that’s more of a responsibility of a designer to provide that kind of detail and then show it to my colleagues.
So, you almost need to have…you can talk about it a lot but if your team, if the words that you’re using don’t mean the same thing to everyone on your team and you don’t have some visual representation that everyone can share, how does anyone know if they’re doing what you said that you wanted to do, right?
ight, that’s it. Or you end up with a linear transition and everyone goes, “Hey, yeah: looks good!” without anyone actually looking at it and going, does it really look good? Does it really communicate what we’re hoping so yeah, I could have done better there, for sure.
Yeah, well it’s all part of the learning experience; it’s how these things go. So I guess kind of related, my second one that I wanted to share was, and I’ve done this more than once, which is maybe totally embarrassing because I didn’t learn from the first time, but it’s letting animations get left to the ends; letting them be considered that last piece of just this extra; like the icing or the sprinkles on your ice cream as opposed to a thing that is super-important.
Oh yeah!
Dessert metaphors are always good! But it was one of those things where it was a lot to do with trying to take charge of it but maybe not pushing on how important it was throughout the whole process where I started at the beginning of the projects, when we were doing early design thinking and early wireframes and everything of, hey, here’s where animation could happen; here’s where it might help, where it might…kind of considering that stuff from the beginning and even doing a little bit in the actual designs. The project I’m thinking of we actually did straight up mock-ups and everything, even though that’s not cool now, we did it then. Whatever!
There was some talk of it there, a little bit about hovers and stuff but most of it, your story, stayed mostly just in verbal conversation. We were like, OK, we’re looking at this static thing but then we build this out; this thing is totally going to move like that and then this thing is going to do this and that’s how it all animate and it’ll be great. But of course, then, design took longer than it should because there’s more revisions than you think and then it went to the developers and that probably took longer than it should and so by the end, oh wait: all these animations we talked about throughout this whole process, only talked about of course; never actually prototyped or anything, all these things we talked about we haven’t put in yet.
Where are they? Yeah.
Yeah, we need to do them and then it comes down to the Project Manager being like, oh well, we just don’t have enough hours, this really needs to go live and all this stuff and you’re like, oh man, I totally messed this up! Somewhere along the line, I want to say I let it lose importance but really your whole team, everyone working on it, has to feel this is important; it can’t just be one person being the annoying person: hey, have you animated it yet? Did you animate it yet? Did you animate it yet? So we kind of lost sight of it; I think even though we were talking about it at the beginning, it never became something that was important throughout the whole process and it just got pushed off and pushed off and then at the end, everyone was like, well: no time.
I think you’re right; I think you’re onto something there. Really it’s about the perceived value that it brings. If the team looks at something, looks at motion and thinks well, it’s icing on the top, it’s essentially decorative then yeah, guess what’s going to happen? It’s going to get left off, because everything takes that little bit longer and then there’s always going to be a Project Manager or someone saying, “All right, how long do you want us to do? Another two weeks on this to finesse it? What value does that bring compared to shipping a new feature.” And it’s kind of hard to argue that case, to be honest, if it is a purely decorative thing.
Once you get to that point, how do you argue that? It has more value in the beginning when you’re talking about these earlier stages when it really gets to the end of, do we add this transition or just ship it as it is? I don’t know at that point how you can really even make that argument, if you didn’t have anything to back it up from previous in the whole process.
That’s it. I think if you get to that position, you’ve lost already. Not that it’s a battle necessarily.
No, it’s always a battle!
But you’re unlikely to get that piece of work shipped. It’s really about communicating and convincing your whole team that this motion is important because it helps to reinforce the model, it helps to communicate what’s happening on screen and so on and it’s a non-optional part of user experience. I’ve had similar things even with just graphic flourishes; I was working for a long time on a price comparison site and I had a visual representation, a chart where you could compare plans and we ran out of time and it never got shipped and I was unable to convince people that that was the whole point: all these numbers and so on, really they were secondary. What people wanted was that visual representation but I couldn’t convince people; just got left off at end of the project and exactly the same, if you fail to make the case for why something’s important, it’s going to be seen as expendable.
Yeah, and as I was saying this, I was thinking the same thing; this is something that’s happened to me with actual visual design stuff as well in the past. At certain points, certain teams, certain products or whatever just don’t value design and animation’s kind of part of that, right? It’s like a part of design and if you don’t value design anyways; everyone’s kind of got their own values and I know I’ve definitely been in that position too which is visual design things: well, that was the whole point I was working on this project but I guess it’s not going to ever be live. OK!
I think if your work is seen as polish rather than core functionality then you’re going to be in for a fairly depressing existence, for sure.
That’s never a fun position to be in, as a designer. But the big thing is getting your team to buy into it and having a team that believes in it. I know, a random aside, just a quick one, but I talked to some of the guys from Stripe once and I asked them how they did it and what they used to prototype stuff and they were like, oh we just talk about it all the time; everyone is behind this idea and we all want to do it so we get it done. That’s like, that sounds kind of perfect!
Yeah, that’s the way it should be, surely? Absolutely right.
No prototyping, just talking. Wow! Anyways.
One from me then. This is perhaps a bit later in my career; this is when I was at Twitter and we had a fairly big Android project that was in London and I spent quite a bit of time working with various designers on. I think a mistake we made there when it came to motion is we assumed too much about the technical capabilities of Android: we assumed what was going to be easy on certain platforms or what was already easy on iOS for instance would be fairly easy to do on Android and we also assumed that, well, if it worked well on this flavour of Android then it was going to work well on other flavours of Android and of course anyone who has experience of Android will tell you: you make those kind of assumptions at your peril because the capability gap between a high end device and a low end device, particularly on Android, can be quite significant. So, we did a good amount of work, mostly one of our motion design experts: I’m still very happy to admit I’m not an expert, there are people who are far more experienced with this kind of thing than me, but he was spending some time pulling together these really interesting transitions for photos and things like that and we started building them on devices and we hit a few problems.
Now, we did have some excellent engineers who found their way around some of these problems and were able to route around some of those performance issues but it really added quite a lot of time, I think. Something that was meant to be fairly lightweight and not core to the user experience, but certainly helped to make the whole thing feel a bit better but we were looking at potentially having to sink weeks of effort to try and get this working on a wide range of devices, so I think we soon realised that wasn’t going to be the right option. But it was kind of a lesson learned the hard way as well; we’d made those assumptions, probably too early in the prototyping stages, without getting enough of a sense check, a sanity check, from the engineering team or from our test devices and that kind of thing, so I can’t overstate how important it is to be realistic about what you can get done on the platforms you’re designing for; I think we probably could have done better there.
Yeah, it seems especially hard when it comes to native apps because I don’t know all the differences between the different Android platforms and versions but it seems like there’s just a crazy, huge spectrum of what they can do and what works and what doesn’t. That sounds extra-hard and I know, it definitely comes up on web things as well but I think not as much. There’s definitely times where you run into things and you’re like, browsers should be able to do that and you’re like: darn, they can’t. Those jerks!
The phrasing that’s often used when people talk about Android and that capability gap is fragmentation that you have; fragmentation of different screen sizes and different versions of the operating system and different processes and so on and so on, which is true, that’s one way to look at it. But another way, my preferred way to look at it, is actually that’s choice, that’s user choice, so if the user is saying, I want a device that does this that comes in at this price, doesn’t need all these features and so on, I just need a capable Android device to run some apps and to do online banking or whatever it is, who are we to say, well I’m sorry, your handset’s not good enough for the experience? They’ve chosen that particular thing and so I don’t like to think of it as this negative framing of fragmentation; it’s really about device diversity and it’s about user choice of devices. Now, we may at some point have to say well, some of these devices don’t cut the mustard and we’re not going to be able to get that kind of experience but this shouldn’t be a punitive thing; this shouldn’t be, well in that case, let’s not bother, or force them to have this terribly animated thing because, well, they just need to buy a better device: that’s an arrogant way to go about it. I think we need to look at it more positive and say yeah, sure, we can progressively enhance if we can try and detect some of those better devices and say, these should have the full animation; these ones perhaps we can do without.
I was wondering now that you’re saying that, is there an amount of progressive enhancement technique or approach you can take for native apps as well of attempting to, if the support is there, add more stuff, kind of thing?
Yeah, you can on Android, now this is getting a bit more into the technical knowledge that I have only a very patchy amount of, but you have this kind of resource-forking thing in Android at least, I believe, where you can say: “For screens of this width, here are the assets for screens of this width, here are the assets…” and so on. And I think, hopefully, someone listening can correct me if I’m wrong, but I think you can go down to a slightly more granular level in terms of some kind of capabilities or some kind of support; I don’t know if you can do it specifically by things like processor speed and so on; I don’t know if it goes quite that deep, but I seem to recall you can target better then you might first think.
hat’s interesting to know, because I kind of assumed you’re just like, “Well, it’s either Android or it’s something else: that’s all you get!” So that’s nice to know, because that’s not one of those things for the web especially that, well I guess progressive enhancement is more of a thing for the web though it depends who you ask: I hope it’s more of a thing, but I think it’s one of the big advantages we have of being able to actually create motion with web standard things is now we actually can progressively enhance stuff. Yay! So I’m happy to hear that native apps can do it a little too, because I feel like I would just… it’s like you were stuck with everything or nothing, that’s no fun for you as a designer either: well, how do I make this? Am I just totally ignoring this huge audience of people?
Right, exactly and obviously with Android particularly, it is a huge audience and that audience is only going to get bigger as well. Get close to your engineering counterparts and see what they can find out!
I guess I never do those terrible messages like, “Your phone isn’t good enough. Come back on a desktop computer.” I love those messages. They make me so angry!
Yeah, I still see them. I had one the other day. You just have to kind of throw your hands up and say fine, all right, if you want to design experiences like that, that’s great; I’m not going to take part in that.
Like, you really couldn’t think of anything better? OK!
Right.
Anyways, before I go off on that crazy tangent which could take ages, oh well, I guess we did all four of our stories. So, let’s talk about what we’ve been reading.
Yeah, sure. Well I’ll kick off. A couple of things from me. There’s a nice Instagram account that I stumbled across fairly recently; this was linked in an article actually, the next one I’ll mention. This is gifux I think they’ve called it, which is just an Instagram account of app motion snippets, so it’s kind of shiny stuff. Some of it’s culled from Dribbble; a lot of it isn’t actually live stuff, it’s just sort of explorations and stuff.
Examples?
So it has some of the flaws of Dribbble. I also defend Dribbble but it can be a bit surface-orientated at times. But what really interested me there was the use of Instagram as a format.
Yeah, that is really interesting; I would never have thought to look for it there but it seems kind of perfect.
Well quite, because they’ve got that fifteen second limit and I suppose you could use Vine for this kind of thing as well but I haven’t seen it quite so much. I quite like that way of subscribing to a feed and having those all appear where you are already, in your favourite social network, so I quite liked that. So that’s that gifux on Instagram.
Yeah, I like the idea of having some fun animation examples mixed in with my cat photos if I’m going through Instagram like: cat, cat, ah, UI!
Oh, OK; something different! Right, exactly. And that one I saw, that was in the footer of a post called Enhance Your UX with Animated Transitions which is a Medium post. It’s a decent article; it covers some similar ground to the sort of things that we’ve been talking about earlier in the podcast as well so if you found those interesting, I’d recommend having a look at that piece too. The one I really want to talk about though is, there was a piece called A Month Designing In VR and this was posted by Julius Tarng; he’s a designer at Facebook; I think he’s come across from the Branch acquisition, it seems, and what Julius has done is, for anyone who doesn’t know, Facebook bought Oculus a little while back so they’re investing quite heavily in working on VR technology and so Julius essentially made a play to say, “Hey, I want to be involved in this.” And he arranged to essentially be seconded to that team to hack on that platform for a month and this is a really interesting post, because it talks about Julius’s experiences trying different prototyping tools. He started using Unity which is this kind of game engine that many of you are probably familiar with, found deficiencies in that and then moved to Quartz Composer and the Origami platform that Facebook have built around that. And what really interested me about this piece is, although it’s not explicitly about motion design, I think it’s motion design of a different kind. He is talking about some UI transitions and some animation in the interface, but also the user themselves are moving as part of this.
Oh, right, because they’re walking through virtual space and moving their head around.
They’re moving their head to glance at things, to gaze, to select objects and so on. And it struck me: this is something that surely is going to be particularly interesting when it comes to the future of motion design. I don’t know enough about what that really means and I suspect as an industry we probably don’t; the only people who are really looking at this are the people who are embedded within those teams playing out different UI approaches and seeing which ones work. So, I just have this hunch that VR’s going to be really interesting for the future of motion design and I kind of want to get more knowledgeable, more involved about it, if there are any suppliers out there for HTC or Valve or Facebook want to send over a dev kit for the Motion & Meaning team to have a play with, then I’m sure we could come up with some opinions.
We have lots of opinions, oh goodness!
Right. But I thought that was a really interesting article; it just started my brain spinning in a different direction really about what 2016 means for motion design and beyond because these things are hitting the mainstream pretty soon: I think there are some ambitions to get them out by Christmas actually for some of these.
Wow! That’s so soon.
Yeah, to consumers within six months and certainly throughout 2016, so who knows what kind of direction that’s going to take us? So I definitely recommend having a look at that article if that’s the sort of thing that intrigues you as much as it did me.
Yeah, I definitely want to take a look at that. I’ve used the Oculus for one thing but it was really more, essentially like, watch this really super 3D and even behind you kind of movie; it was more that thing, like here, explore this space. There was really no interface to it exactly; it was mostly just like, watch this play out. So that’s really interesting. What would it look like if you actually could make decisions while you’re in there and do things.
Absolutely.
That would be really fun. Anyways. A little bit more to this year, right now, instead of future things. I’ve been reading a couple of things which I realised are again both videos so I swear I can actually read! But once again, videos. Motionographer posted a summary of Benjamin… I forget his last name, but he totally has one, his CSSConf Australia talk. He’s a UI designer at Stripe and Motionographer links to his talk and also summarises it and it’s really neat to hear about this stuff from a place like Stripe who has done a lot of motion on the web and use it in a lot of their UI work and he talks about their best practices, their goals and a lot about how animation can both help user flow and make it seem like things are happening faster, so a little bit in that perceived performance area, which I think is pretty interesting too. So that’s a good one to check out and it’s just nice to hear it from, well it’s the first one I’ve seen that’s actually Stripe talking about themselves as opposed to someone else talking about Stripe, which I totally do all the time, but it’s nice to hear it from them and they seem to be very, very invested in it, which is great. And in a more technical sense or in a more technical vein, I was also watching Sarah Drasner’s Complex Responsive Animations talk from CSSConf New York which is super-interesting. I recently did a little episode for All The Right Moves talking about the art direction and design decisions of doing animation in responsive design but she goes into a lot more complex technical detail like, how do you take these large SVGs and the animation in them and make them work on any viewport size and it’s really interesting; very technical but very interesting, so I got a lot out of that; I liked it.
I think that title alone just makes me sweat slightly! Complex Responsive Animations. Wow, OK! That sounds like an interesting one; she’s obviously at the forefront of this stuff if she’s handling those tricky ones.
It’s very specialised but if you’ve ever run into that or you’re doing a responsive site and you have animations and you’re like, errgh… everything sucks! You will love this talk!
There you go then: Sarah is the person for you! Great stuff.
Cool, so I think that pretty much wraps it up for today?
I guess so, yeah.
like how we’re always surprised by that, we’re like, “Oh, we’re done!”
In the next episode we’re going to be talking about tools because we feel it’s probably about time to do that; talk about the whole slew of prototyping tools available for designers and then we’ll also talk about tools that are available to help developers make the most of motion in their own work, so I hope you’ll join us on the next episode.
You’ve been listening to Episode 5 of Motion & Meaning with Val Head and Cennydd Bowles. You can find out more about this show at motionandmeaning.io and we’d love to hear your feedback on Twitter: we’re @MotionMeaning. See you again soon.
Transcribed by Alison