I tried Layervault, but I didn't like how it takes a 'snapshot' everytime I save - since I was saving to prevent crashes and losing my work, not because I felt it was it a good place to call it a separate version. Then I'd end up with a ton of versions on LV, most of them not true versions.
OP here - I also have the Cmd-S habit and get tons of versions in my timeline. But I actually would prefer to have that, because I don't usually pause all the time and think to "save" a version that I want to show for process later.
They also have a "Signpost" feature which lets you mark real versions, which you probably want to be using instead. (Might not have been there when you tried them first.)
That being said, my use of LayerVault is purely as a backup since I'm the only designer on the team.. and I just email out mockups via screenshots.
I really, really enjoyed reading this. The insights are awesome and the ability to see each small iteration was really cool. I would definitely encourage you to do this in the future.
Love it. This is a great read on the evolution of a design and what goes through a designer's head as they're iterating on a concept. One thing that should particularly stand out is that the format of the article is a continuous loop of 1) Design problem followed by 2) How I solved the problem. This is how great designs are made: constant iteration.
What is more interesting to me is that it seems like one of the key things to generating this loop is identifying design problems. If you can't really pinpoint what is wrong with a design, how can you make it better? Here, Ian seems to get a lot of feedback from other people, but I'm curious as to what kinds of internal thought processes he has when trying to identify exactly where a particular design is lacking.
One heuristic that works for me is thinking about the context of a design. In other words, how did the user get to this particular screen? What are their intentions when entering this view? Almost no individual UI element is self-explanatory when it's devoid of context. Just thinking about what the user wants to do at this particular part of your UI flow can help identify ways in which you can make the design clearer and more in line with their intentions.
In any case, there are a ton of great design patterns to pick up from seeing how Ian thinks about problems. Every designer needs to read this.
Thanks! Truth be told, my internal processes are way less useful than just asking the rest of the guys for feedback. I usually get way too familiar with the design, and devolve into just perfecting the visual appearance. Forgetting the bigger problems, until I ask someone and their reaction is basically what Peter said in the article, AKA "WTF?". :p
5 comments
[ 1.7 ms ] story [ 26.1 ms ] threadWhat are your thoughts on this?
They also have a "Signpost" feature which lets you mark real versions, which you probably want to be using instead. (Might not have been there when you tried them first.)
That being said, my use of LayerVault is purely as a backup since I'm the only designer on the team.. and I just email out mockups via screenshots.
Anyone know of similar write ups in this style?
What is more interesting to me is that it seems like one of the key things to generating this loop is identifying design problems. If you can't really pinpoint what is wrong with a design, how can you make it better? Here, Ian seems to get a lot of feedback from other people, but I'm curious as to what kinds of internal thought processes he has when trying to identify exactly where a particular design is lacking.
One heuristic that works for me is thinking about the context of a design. In other words, how did the user get to this particular screen? What are their intentions when entering this view? Almost no individual UI element is self-explanatory when it's devoid of context. Just thinking about what the user wants to do at this particular part of your UI flow can help identify ways in which you can make the design clearer and more in line with their intentions.
In any case, there are a ton of great design patterns to pick up from seeing how Ian thinks about problems. Every designer needs to read this.