This week was dedicated to a design critique of our third and final project for this module, an educational app to teach users about the UN Sustainable Development Goals. The critique went well for me, I received some useful feedback which I can now implement to improve my project and I was able to get the confidence I needed that my project was on the right track and with some minor improvements I would have a really nice final product to be handed-in for marking.
We also covered the details around what we needed to hand-in, when and in what format, which is always useful to get that information set to avoid any issues later on.
As I mentioned during my project research blog, I wanted to take some time to look at my experiences of learning and using DraftXR for my SDG project. I had not used it before, if I’m honest I can’t say I was even aware of it as an option for prototyping Virtual Reality projects. I found good and bad points through the process of using it for this project and this is what I will go into in this blog post. I’m going to start with the good points and the first is how easy DraftXR is to use right from the start, it is really simple to get along with and I found it very easy to get a project up and going with it. I used the provided template file that you can download from DraftXR themselves to get an idea of what I needed to do and how that would work. The template is very basic but by being able to see both the design file in Figma and the prototype as published on DraftXR in the browser really helped me understand the text instructions that are provided. To start it really is as easy as setting a Figma file opening the plug-in and following the instructions within the plug-in window. As I mentioned I do believe when using it for the first time it is definitely useful to look at the template file as this makes the instructions clearer and helps with understanding. Within Figma you simply setup as many 1920 x 1080-pixel frames as your design requires and add your UI components within this frame, just as you would with any Figma design you are working on. The same goes for the basic prototyping you simply connect your screens and interactive elements to build your user flow. The key thing that DraftXR requires is a clear flow start point for your prototype, so much so that it will not allow you to publish a draft to the web without it. While DraftXR is wonderfully easy to get started with and create a VR prototype it does have several issues when it comes to more advanced Figma skills especially when using components or different prototyping methods. It works perfectly with basic designs but as soon as you try to use nested components or anything other than on tap or on click interactions it simply stops working. I found this frustrating because as my Figma skills have improved I have begun to find, learn and use some of the program’s functionality and have implemented this into my workflow, while using DraftXR felt like going back to how I used Figma when I first started using it. With nested components, I use these for consistency across multiple screens and often a piece of my UI can contain three layers of nested components for example I may have an icon with label nested within a navigation bar nested with a card with content. This building block approach is how I build my Figma designs now and when I discovered that the buttons or icons when nested would not work as interactive elements, I had to spend a lot of time going and ungrouping components so they would work. In the end I got them to work but it definitely took longer than it would if I could have used my nested components. In terms of advanced prototyping this was also frustrating, I know the importance of hover effects in design as they give users a clear visual cue that an element in the design is interactive. Unfortunately, DraftXR currently doesn’t support hover style effects, so I simply have had to do without. Another prototyping issue I discovered was that I could not use the back prototyping feature where you can link an element to a back arrow and the prototype will know when this is clicked it should go back to the previous screen the user was on. I was going to use this feature to for my menu as it means I would only have to create one menu for all my screens, but as I could not and adding an individual menu screen for each screen that could navigate to it would have meant creating twenty-five copies of the menu and individually wiring up each one as part of the prototype, with all the extra loading time this would cause, in the end I decided to not have a menu in the prototype. This also was because even before I discovered this my menu was already a compromise, I had wanted to use the overlay prototyping method so that my menu would come and be overlaid over my content when required and then be closed, however, I discovered DraftXR did not support using overlays, so I had to ditch this idea too. This also affected my plans for my map where a user would choose their university to tour, and it did compromise my final design. The final issue I discovered was that you cannot see the background of your screens in Figma, for accurate placing of UI elements, you must place them on an empty frame, publish the draft and then check their position on DraftXR in the browser before returning to Figma if changes are required. This is frustrating and being able to make even just minor positional tweaks within DraftXR would be incredibly useful. While I have discovered several annoying little things with DraftXR they tend to appear when I used more advanced parts of Figma’s functionality, when I stuck to basic Figma design it worked perfectly. Most of the more advanced functionality is there to save time and most of the issues I discovered could be worked around, it would just take more time and make for an untidy design file. And this is my conclusion on DraftXR, it makes prototyping VR projects possible, and it in truth has made it easy for anyone to have a go at designing a UI for VR or a very basic VR product. Figma cannot do this natively currently (although they may look at adding it if XR products take off) so DraftXR does offer an extended capability to Figma. This is the key when I was researching the possibility of doing a VR project there was no prototyping tools available, it seemed the only way would be to build the product, and this would be outside my skillset at the moment. So, Draft XR is definitely a useful tool and one where once you know its foibles you can work with and quickly develop a VR prototype, and this is another thing to remember this is a prototype, of course I would add some nicer features like hover effects in a developed product, but for validating an idea and working out some early development stage issues it works well. Improvements could be made and if it becomes popular enough, I’m sure they will, but for now it is a useful tool that lets you extend Figma into the VR and AR sphere.
You can try Draft XR for yourself here: https://www.draftxr.com/
This week’s critique as usual has provided useful feedback and has me going into the hand-in confident I can deliver a good product for marking. The hand-in guidelines will be really useful as now I can use them as a checklist to ensure I have everything I need where I need it by the deadline.
DraftXR is a really useful tool it is not without some frustrating issues but I feel it adds to Figma’s already amazing uses and it is incredibly easy to use. I hope it gets some further development to allow it to be even better, but I would not hesitate to use it again to prototype a VR project.