Five things I learned at General Assembly’s User Experience Design Immersive program
In March 2015 I took the ten week UXDI course in London. Here’s what I’ve learned.
From March until May 2015 I took General Assembly’s ten week User Experience Design Immersive program in London. Before taking the course I’ve worked as a (mostly) self-taught UI Designer in a small Digital Agency based in Switzerland. After the course I returned to Switzerland and continue to work in the same agency. I’m now trying to apply what I learned and slowly shift towards being a full-time UXer.
These are the top-five things I learned during the course.
Present your stuff: It’s part of your job
At GA we had to present every project we did in front of the class. It ranged from short 3 minute to more thorough 20 minute presentations. There is one simple reason for (UX) Designers to do this: YOU played a major part in the design process, YOU know why the design is how it is, therefore YOU should present it to the client. Or as Mike Monteiro puts it:
“A designer who does not present his or her own work is not a designer.”
– Mike Monteiro in Design is a Job
This quote hit me hard. I’ve never presented my designs before. It was always someone else. When feedback came I complained. I blamed the client or the one that presented it. But ultimately it was my fault.
Collaborate a lot: Don’t try to be a Rockstar
Creating great User Experiences is a Team Sport. A great way to achieve this is the Design Studio Method. It involves people from across the board (Stakeholders, Developers, Designers, Project Mangers, etc.) and forces them to quickly generate ideas. To create a great User Experience you want to get all the different perspectives from the different people that are involved in the project. This is exactly what you get from running a Design Studio Session.
In Agile environments there is no place for Rockstar-Designers that try to solve problems on their own and come up with “the perfect design”. Rockstars don’t share — neither their ideas nor the spotlight. This is poison to a collaborative environment. Be collaborative and be open to new ideas. Which brings me to my next point.
Don’t get married to your ideas
When faced with a problem I quickly have ideas on how to solve it. This is good and how it’s supposed to be. But what’s bad about it is that I used to stick to them. At GA I learned to not get too attached to my ideas. In a fast-paced and highly iterative world you want to get some distance from your ideas. Because things change. Quickly. If you’re married to your idea you start defending your design, even if testing proved that it’s probably not the best solution. And clearly it’s not about what you think is best but about what is best for the project.
Treat your idea as an assumption: “I think this problem could be solved by doing X” — instead of “Doing X will solve the problem”. And then validate this assumption by testing it. If the assumption was wrong then that’s fine: Learn from it and adjust whatever needs to be adjusted. Then validate again.
Don’t be afraid to show unfinished work
I often hear people saying: “I can’t show this to anyone — it’s not finished yet”. Before GA I would’ve said: “Ok, take your time to finish it” Now I say: “Doesn’t matter”. Whether you’re about to test a paper prototype with a user or show your client some wireframes: It’s all about communicating the idea. And if it does that then it’s good enough to show it to anyone. Why spend time polishing something to perfection when what you’re looking for is feedback? That’s wasted time. Because feedback is going to change it anyway. I’d much rather spend time gathering feedback and adjusting my design than trying to polish something that I know is most likely going to change anyway.
Note: This may not necessarily apply to Visual Design. When doing Visual Design you might want to take some time to polish certain elements and then show it to someone — because small details can have a huge impact. But don’t overdo it. We all know that perfect is the enemy of good.
Expose your client to user research
Clients often say they know their users. They make assumptions on who they are, how they use their app and what their problems are. It’s your job as a UX-Designer to do the research and show them how it really is. And then expose them to your research. It’s your magic weapon. You can argue for hours with a CTO if what he built is actually usable or not. Or you can just go out, observe some people using it, film it, and then show him what you found. Or even better: Let them be part of a testing session.
Show your client what real people think. Show them what their needs and problems are. And then design something that addresses those needs and problems. Because at end of the day, this is what UX is all about: Building something that adds value to people’s lives. You can’t do that without talking to them.
That’s it! It was an intense course and I learned a lot in those ten weeks. Way more than I could pack in a blogpost. But these five things definitely stuck with me the most.
Feel free to hit me up on Twitter @yannschaub
If you enjoyed this piece, please scroll down and click the “recommend” button. Thanks!
