This week I attended a UX Budapest meetup event. Besides the always great networking I liked the talks too, as they offered an interesting insight on how people were getting along on learning UX. The talks were showcasing the project based work done by the learners coming from the different hands on courses started in recent years in Budapest.

(Disclosure: this semester I mentored on one of these courses, and did some grading on an other.)

image-center

From fitness app to charity websites, all presentations were pretty great. Especially considering that most participants started their UX education quite recently. I may explain this quality in one part with the improving teams behind these courses. But it also seems that more and more very talented people are choosing our discipline, even if this means switching careers for them.

All course organisers made the choice of having the students not just to listen to talks, but to also do project work. There seems to be an agreement, that UX cannot be learned with just listening to lectures. You need to have some hands on experience, you need to make your hands dirty on user interviews, on usability tests, on small experiments, on drawing your wireframes, and on making through a project from start to finish. I like this approach, as fits well with my mentoring style, promoting the experimentation mindset.

One thing I noticed on all the projects, whether the participants came up with their own ideas, or worked with external stakeholders, is how disconnected the results seem to be to the work we are producing in our day jobs. I’m not talking about the quality, but rather the sophistication, the compromises, the realities that product design teams face on a daily basis at a product tech company. Most presenters mentioned things like “so we came up with a new way to search”, or “it just combines the different databases”. Such statements sound like 6 month projects from idea to production with techleads getting super anxious. When you are a product team, most of your todos are not about hand crafting pixels or making extensive research on user pain points. Not even about coming up with world changing ideas (maybe rarely). You spend more time on making everyone involved with your project have a shared understanding on what needs to be done, on getting input about constraints on time and effort to be spent, and getting feedback on your ideas and progress. You shouldn’t fall in love with your ideas, and need to understand what is possible to achieve to make your users life easier. Probably all this together could be called communication, though I’m hesitant to use this word. I think this is design itself, not in a sense what a few people do with postits in one hand and a Photoshop in the other. Rather it’s the process of how teams arrive from problems to the end product from discovery to delivery.

I’m not saying that these courses are bad or their approach is wrong, as the participants still learn tons of useful stuff that could help them land a UX job later on. The projects just need a little bit more diverse input, maybe as a next step, maybe even in their first job as UXers.

So here is an idea. If you are a designer working on speculative project work, maybe to improve your portfolio, get more feedback. Try to get feedback from somebody who understands business goals, try to get feedback from somebody who understands technology and the cost of implementation, and try to get feedback from somebody who understands organisational realities, so what could get done in what time. I don’t say that you need to have real numbers on anything, we are talking about speculative after all. But you should have some knowledge on what parts of your design will remain just a file, and what parts have a chance of actually improving some user’s life.

Comments