Tools & Techniques
Throughout the course I used several tools, ranging from hand sketched drawings, to audio recordings and digital prototyping. In total, I used 8 different tools. Here’s a list (in no specific order):
- Paper prototypes
- Hand drawn wireframes
- Digital wireframes
- Whimsical
- Adobe Illustrator
- Adobe XD (desktop and mobile apps)
- Adobe Audition Pro
- Audio recorder
I have found it easier to work with the visual tools as they are the ones I use the most, with an exception of paper prototyping.
I feel like I do not do enough of hand drawn prototyping and sketching, and I now understood how important it is to include them in the design process. Since week 3 – when I had to prototype the journey planner – I have been practicing a bit more my drawing and sketching skills.
I have also l learned that audio prototyping shouldn’t be underestimated. During the second week I kept thinking it was completely unnecessary to put thought into the audio testing I conducted, until I tried it by myself. From a usability standpoint, audio feedback is already an incredibly useful function, but then I thought of accessibility issues and realized it is indispensable to provide auditory cues on services.
Usefulness of the tools and techniques
Since starting this degree, I have researched many times on which tools or techniques I should include in my design process. I think it’s one of those things you never think you’ll need to research, until you do.
As I mentioned, before attending this course I completely underestimated the power of hand drawn and audio prototyping. Before, my design process in a real product would probably something like this:
Design Briefing → Digital Visual Prototyping → Implementation/Final Product
After this course though, I think it must have adapted into a process with more tools, but much more efficient since it minimizes errors:
Briefing → Low-Fi Prototyping → High Fi Prototyping/Testing → Implementation/Final Product
This process still doesn’t mention the research phase, but it is already much more complete when the testing phase comes up. I believe a process like this makes things easier for different teams when information must be passed on. For example, the developers can take advantage of well-designed prototypes that are done after good testing and feedback sessions. The designers (experience, interface, graphic…) can then benefit from not having to constantly ask the developers to iterate things because of either bad instructions or lack of testing.
I am eager to apply this all in a professional environment, where this process has a bigger pressure to be done properly.
Helpful activities
From all the activities we did, I have to say the A/B testing was the one I took less advantage of. Even though we had sessions before the workshops, it felt like the tests were built on a sort of void. The freedom we had to decide on not only the type of test, but also the product we were going to test on, made A/B testing seem like not such a serious thing.
The lack of a pressure for the test participants can also contribute to this. Maybe I set up the tests wrongly, but it felt like some participants didn’t really take the outcome of the test seriously, and that may have biased the results.
END OF COURSE :)