It won’t take long before you realise that being a UX designer means getting your hands dirty. For all the helpful articles from Smashing magazine and Usability.com; for all the jacked patterns from UI-inspiration, there will come a point where the answer to a user’s problem can only be found by digging deep. But that’s sometimes easier said than done.
In my first UX role as an in-house mobile app designer, it became apparent that there were certain challenges to putting theory into practice. These challenges included the difficulties of finding users to give feedback on process specific apps, estimating time and resources that could be put into doing user research and more long term; ethnographic studies; the ever present reality of office politics and last of all, fatigue as yet another methodology is brought in and inevitably gets a little fuzzy as it gets incorporated into existing ways of working, leading to confusion, lack of documentation and piling costs to name a few.
So what is it about the design jam that could help?
Just as a disclaimer, I haven’t yet tried hosting a design jam in an enterprise setting (watch this space) but there are some helpful things I learned:
One of the first things we do at a Jam is create a Jam culture. It’s a bit like a crowdsourced code of conduct, our own guide to design which we’ll be following throughout the Jam. The most important thing is that it’s formed from experience. Typically we’ll have a fun making session – like who can build the tallest tower out of dry spaghetti and balance a marshmallow on top – and then note all the things we’ve learned on a wall, highlighting what was successful and what wasn’t. Keeping this visible throughout the Jam helps make sure we’re all working by the principles we have discovered to work best. These aren’t just ideas, but tried and tested theories.
Testing and validating design is hard work so it’s crucial whole team is open to learning from user feedback and not designing by personal preference. Instead of a bland powerpoint presentation, why not kickstart an end-of-project retrospective with a fast paced making session, using the activity to springboard into what was learned from the enterprise project you’ve just completed. Don’t forget to document them, with some additional notes on how you will apply these lessons learned to the next project.
THINK LIKE A MAKER
If anything can be described as a mantra in the Design Jam, prototyping is it. Don’t talk, make! Prototype, prototype, prototype!
It is important to discuss and build up on ideas – that’s what a jam is, after all – and to make the most of them, it’s also important to narrow down on the best aspects of everyones contributions. Prototyping is a part of that – turning concepts into the real in a way that users can touch, interact with and test will help refine and polish whatever ideas your team (and users!) have brought forward.
If you’re working in an enterprise, it can seem a bit strange to present your potential users and stakeholders with paper prototypes, but if you opt for a more informal setting (“Can I have a quick five minutes?”) or use communication tools like slack to share digital prototypes, that often helps set their expectations appropriately. Don’t forget, it’s never too late and no feature is too small to prototype! Don’t worry about perfection either – the goal of a prototype is to answer design/feature challenges, which brings us to the next tip…
TEST IN ANGER
We often talk about the necessity of testing with users but there’s always challenges embedding this into our development practice. There isn’t really anything special to say about this other than to put some time in for usability testing, whether at the end of each sprint, or every two sprints. Seriously, just put it in! Tests are actually vital for settling disagreements about design using evidence and not just theory.
If it comes down to it, right before a project is commenced, challenge your product owner to include time to do some user testing, to gather a user focus group who won’t mind being asked to use and test prototypes at set intervals. Everyone is busy so be considerate of their time (and yours). we’ve already mentioned slack as a communication tool, but lots of prototyping services (e.g. proto.io, inVision and UXPin) also allow commenting and editing by other users so experiment a little to find the best way of testing design features and functionalities.
Of course it shouldn’t need saying but make sure the tests and results are adequately documented. You don’t want to find yourself making the same mistake in the next project!
One thing I don’t want to do is make it sound like these will cure all your ills. I’m a Jammer, not a Prophet. We all face different challenges. Different work cultures and environments can easily create unexpected pitfalls. Keep experimenting, never forgetting to document and learn from experience. Whether this is in the form of a poster or a short youtube video, whatever you try, make sure you note what worked well, what didn’t and make sure it’s accessible.
So just to recap:
- Document your learnings
- Treat everything as a case study – you can add lessons learned from experiences to the team jam culture board
- If you can’t explain it, make it
- If you can explain it, then you really should make it!
- Document your design process – the branches will help develop test cases
- Test often and test hard
- Testing with potential users is important but testing with non-users also helps solidify your user story