I generally believe that ideas and principles are more important than processes, which themselves are more import than tools. Your ideas as well as your basic design knowledge matter more than what you use to generate and implement those ideas. However, I think that which tools and processes you use can still provide an insight into your approach to design and your personal way of thinking.
This is my toolbox.
Please bear in mind that this is not about design methods but about my favorite tools — mostly software, that is.
Continuous stationery, Markdown/iA Writer, OmniGraffle, Sketch, CS-Suite; Code (Processing, Framer, HTML, CSS & JS, Swift), Git; Wunderlist, Trello, DayOne; lynda.com
I don’t feel comfortable using sketch books. To me, a sketch book takes too long to completely fill and until you switch to the next one, you carry around all those sketches inside. Their “lifespan” makes me nervous: I am just not very good at drawing things and while I totally get the idea of jotting things down to sort them in your mind and to visualize your thoughts for yourself and other people the sheer thought of keeping my sketches with me for some time makes me shiver. I’ve found a solution though: a pile of continuous stationery.
It is perfect for my needs: I always carry some paper around with me, but when I am finished with a sketch I can tear it off and either file it or throw it away. It’s cheap and disposable—making mistakes doesn’t matter. My fear of starting to draw something on a blank sheet (aka blank canvas fear) is gone.
Even though I have made fun of my friend Nikolas a couple of times quoting this tweet I must admit I get what it is stating.
It doesn’t matter whether you write down your ideas in the form of user stories or a faked press release or an entire walkthrough or generally describe what solution you aim to provide: having a written document (that you can change if you need to) ofter times helps you find flaws in your concept and guides you through your development process. It’s also great to clear up misunderstandings within a team before they even happen. Oftentimes simply defining certain words that you use to describe something very specific (like a certain unit of data) whithin your team makes communications much easier. You can always go back to this definition (and it doesn’t matter whether this is the final wording or just some term for yourself).
I like structured documents and so Markdown as a markup language is an obvious choice, it’s easy, super quick and since it doesn’t require a special format interchangeable.
I am not extremely picky about my Markdown editor and I’ve tried quite a few (of the many that are out there, quite a lot are very simplistic and clean), but there is one killer feature of iA Writer that I haven’t seen anywere else and that I am not ready to take a pass on anymore: overhanging punctuation. Markdown is not very intrusive, but the way headings are moved inwards by the hash sign (as well as unordered lists by the dash) is making the copy look restless and makes me uneasy. Usually hanging punctuation might be a minor typographic improvement, but in this case it is vital to me.
When I start creating an interface I try to thoroughly understand what kind of data makes up this interface and how it is connected. OmniGraffle is not a tool that’s a pleasure to work with, but so forth I have not found an alternative, that lets me create complex diagrams so quickly. The UML and FlowChart stencils are my favorite base system for modeling visual overviews over all kinds of pieces of data. I find myself coming back to these charts all the time during the drafting stage and once I’ve understood what I am working with it starts making sense to me and I can be sure not to forget anything when developing new ideas and creating wireframes. Once you have a basic interface idea process diagrams can help streamline mircointeractions and find inconsistencies within your different interactions that otherwise might go unnoticed if you don’t have time for long-term testing.
After being frustrated with using the Adobe tools for designing interfaces I switched to Sketch as my main visual design application. In the beginning it was awesome to get away from some of the constrains placed by PS, AI and ID and how they were overpowered in some things unimportant to me and underpowered in other vital categories. Back then Sketch was very buggy and the performance was awful when documents started getting larger. By now the performance has increased greatly and most of the bugs are fixed, but there is still a lot to do (especially typography-wise). With Mirror allowing you to live mirror you Sketch artboards to iOS devices feels like it should.
I am more of a concept, process and user experience designer than a visual designer and I prefer refined prototypes to pixel perfect screenshots, so Sketch suits my needs: I want to lay out my elements and try variations quickly, but I prefer to refine the small visual details once I get into prototyping. I hope Sketch will continue to improve but for now it works out great for me.
Well, duh. Can’t get around it, can you? Of course every now and then I still use Photoshop; Sketch is in my opinion not suited for vector editing, so for icons etc. Illustrator is a must-have and as soon as you get to multi-page layouts there is no way around InDesign (still my favorite of those three).
Compared to those three main applications I feel suprisingly comfortable using AfterEffects (which I actually quite like) or Premiere. MediaEncoder is still my favorite Adobe tool, even though not many people seem to be using it or know about it in the first place.
There are a couple of reasons why I believe prototyping is so incredibly import for Interaction Design.
The first reason is just a practical one: You can’t forget stuff. No matter how much you work on a screendesign in a software like Sketch or Illustrator and no matter how much you think you have thought it through, you always forget something. Maybe it’s mouseover- or active-states (hopefully not), maybe it’s a very specific combination of actions a user might take, maybe it’s how the interface behaves in edge cases (like very long names), or how it looks with loads of data (filling screens with (real, diverse) data is tiresome in these applications). As long as your interface isn’t dynamic (= is basically a screenshot) you can not design it to be dynamic properly.
The second reason is inspiration: While working on building an interface prototype I often come up with all sorts of little features that might help a user. Micro interactions and little tweaks in the UI that make some interactions faster or more fun. This is also the reason why I like to do a very rough prototype at first: During building the prototype many things change, but that’t not a problem, since the final prototype will be created once everything works. Prototyping really is an integral part of my design process.
The third reason is animation and transition: I seprate the two, because by animation I mean large scale animations like between screens and by transitions I mean smaller things like how a link changes color when you hover it. Building animations in After Effects after you have finished your static screen designs doesn’t do them justice. And have you ever seen a gif on dribble of a link changing color? People don’t create those micro-animations in AE — but honestly, wether that change takes 0.3s or 0.5s makes a difference.
My final reason for prototyping is presentation: explaining static screenshots or an over-simple click-prototype to someone is hard and not effective (especially when they are not designers). With a working prototype you can talk about specifics, have people try it themselves and give you feedback on their actual experience rather than a guided tour.
There is a large variety of low fidelity prototyping tools out there and I have yet to find my favorite. So far I have been comfortable using Processing for more technical prototypes or very quick generative experiments. Basically, if there’s hard math involved I first try it in a quick Processing sketch. It’s not fast enough for production and I absolutly won’t ever use it for a user interface, but it definitely is an awesome tool.
RelativeWare’s Form, recently bought by Google, is basically a more modern approach to Quartz Composer. One great feature of it is the “Viewer” where you can test your prototype directly on the device, using native APIs and apparently with native performance. I haven’t been comfortable with this sort of node-connecting programming languages like Quartz of VVVV until now, but Form’s new approach makes it look really interesting and definitely worth trying.
Framer.js is really hyped right now and I can defintely see why. It gives you a great set of tools to rapidly built small interactive prototypes. I have tinkered around with it a bit but have yet to use it in an actual project. However I often feel like people try to build to large prototypes with it and it grows above their head. When it comes to large scale prototypes (meaning entire interfaces, not just small parts), I don’t think Framer is the appropriate tool. Still: interactive wireframes are a bliss and Framer is definitely the right tool for that!
My absolute favorite tool for prototyping interfaces are the web frontend languages (I even teach a course about that). I have been using them for quite some time now (building websites since I am 13, though the way I used them than has practically nothing to do with how I use them now) and I am really fast at realizing my ideas. Having structure and content, look and animation and function in seperate files keeps everything well structured and you are quick to make changes (since I am using SCSS and imported files I split that even further apart: I have a file for colors, one for typography, one for structure, …). With CSS you can do basically anything you can think of by now and animations and transitions are a bliss.
The prototypes can be displayed on virtually every device and filling them with data is super easy: json itself is nice to edit and using a Google Spreadsheet with their json-API makes managing large sets of example data even easier.
Having stated my love for web prototypes, I also see the drawbacks: Larger prototypes often lack of performance, especially when run on mobile devices. And while acessing native APIs like TouchID or Geolocation is possible with Phonegap it’s not as clean and flawless as I’d like it to be.
That’s why I have recently started getting into Swift. Developing native applications is a new experience, but I think it is worth the trouble: The performance is incredible and the APIs provided by Apple are beautiful (if you know which one to use).
Version control: Git
Since almost a year now I am using Git(Hub) for version controlling and it has totally changed my coding workflow. I keep my repos tidy and when I start coding I focus on one feature at a time. I also love creating the commit at the end of a coding session: Reflecting on what you created and giving it a name has something concluding, releasing to it. Of course it also makes collaboration on code so much easier and better organized and simply getting rid of all of those “backup-150421-1244”-folders has been worth taking the barrier when getting started.
I have been using Wunderlist for a while, but in recent times I am more and more disappointed by it. This started when I began using the mobile app. I can hardly explain, but it feels fragile and brittle. It’s just no fun to use for me anymore. I am still keeping it, because sometimes having a longer to-do list is necessary, but I have basically replaced it.
I am really looking forward to the release of Things 3. I used Things to a bit, but it felt outdated and to complicated for my needs. But if everything that was done right is taken and put into a modern, refined software it will be great. I hope I won’t be disappointed.
I first looked at Trello when it was still in beta and I didn’t like it at all. It seemed clustered, unrefined and I couldn’t really find a workflow. Because of this experience I stayed away from it quite a while. After hearing lots of positive things however I decided to give it a shot again and this time I am much more pleased. I have been using it as a kind of One-person-Scrum management tool in a couple of project recently and I must say, it really helped me prioritizing tasks and keeping track of multiple to-dos at once.
I use Day One as a private journal since six months and write down what I did every day. My entries are quite unemotional and might seem dry, but I love looking at them sometimes and refreshing my memory. I also like to take pictures for these entries that are authentic, just random moments of the day, that actually document my life, rather than the kind of pictures you take for a photo album on special events.
Since the beginning I have been using a special tag to mark entries that are about work. Writing down what I have been working on everyday might not have that much value for reflection in the future, but it does basically the same thing as a commit message: It helps me reflect on the progress I made on the day and bring things to an end.
Apart from going to university and reading books (!) I also use lynda.com for educational purposes. I love how I can learn the basics of so many technologies in just a couple of hours, be that Unity, Swift, Node.js or something else — lynda courses help me find my way into new technologies incredibly fast. This allows me to be open for new technologies in project, because I have no fear having to learn them. lynda is great resource and I use it in almost every project.
Coming to think about it, to be honest I wrote this extensive essay mostly for myself: Reflection on my tools and having to write down the actual reasons why I use them has been very interesting and helped my sort out my toolbox quite a bit.
Having said that, if anyone every really read to this point I’d like to close on the following thought: ideas and principles might be the most important thing for a designer, but I genuinely believe that it is also incredibly important to have a toolbox you are familiar and comfortable with, because otherwise implementing great ideas becomes painfull, which is an absolute disaster.