My favourite tool for UX prototyping
Weeknotes #24: Nov 2–6, 2020
On the User-centred design team at the Canada Revenue Agency, we prototype a lot. We conduct baseline usability tests on users’ top tasks, then we design possible solutions to address any problems, and run a follow-up test to determine how successful our revisions were.
Having a way to explore and mock up options is critical to our ability to move quickly, and there are numerous tools and philosophies about the best way to approach prototyping. (For more information, you can also check out the blog post a former teammate and I wrote for the Code for Canada blog last year: Prototyping in the Public Sector)
This week I dug into iterating on a concept a teammate had initially started. As I wanted to find a way to communicate what I was thinking as quickly as possible, I pulled an old trick out of my bag: reviewing the page in a web browser and using developer tools to make minor changes to the layout and copy.
Using developer tools to make changes to a rendered page (then screen shot it)
This may not be an approach that everyone is comfortable with, but it harkens back to earlier days in my career when I was a web developer.. I find it can sometimes be simpler to make changes directly to the code and have it rendered in the browser than try to recreate it visually using design software. I say sometimes because this is an approach that works really well if the changes you’re looking to make are primarily content changes, and you can let pre-existing CSS determine the styling.
Note that this only changes what is displayed locally on your own browser, so you need to be sure to grab a screenshot to share with others. I can’t tell you how many times I’ve started with this approach, and then navigated away or refreshed the page and lost what I had been working on. The drawback to this approach is when you are trying to do more than a static page.
After I created my first screenshot, I pulled it into Figma as a starting point.
Figma
This saved me from having to recreate the navigation and heading of the page with the design software: anything that wasn’t the focus on the concept. The image was the bottom layer in the frame, then I added a big white box to cover the content I wanted to replace, and then on top I added the content that was the focus on my work. Definitely pretty hacky, but it saves a lot of time ‘designing’ elements that aren’t going to be the focus of the test.
Figma is great software. I personally love that it’s browser based and I can use it cross-platform, and share links with others. As I worked on the concept, I linked together a few screens into a prototype and shared the link with teammates. They could take a look and give me back feedback without our having to schedule a meeting for me to ‘show it to them’. At the same time, I could keep working on it, confident that they weren’t looking at outdated static screen shots.
But… they were still pretty static.
For rich interactivity, Axure’s still a winner
I first started using Axure for prototyping in 2012, years before Figma was created. I’ve really only seen it adopted by *ahem* more corporate or government organizations, and it’s certainly not the most powerful design tool. In fact, I may not really consider it a “design” tool at all.. A quick google search finds it described itself as “software for creating prototypes and specifications for websites and applications” and that seems about right.
Axure shines when it comes to creating interactive prototypes. Interactive components, or widgets, mean people can interact with your designs as though they are real applications. You can create variables to calculate and persist values across a session, so users can really get a sense of what the experience would be like.
I haven’t tried the latest version of Axure, but from my experience with the past version, Axure didn’t have the fine granularity of designing a beautiful interface. It’s a workhorse, not a show pony.
I enjoy working with Figma.. it’s just easy to use and I feel like things look good. But Axure has spoiled me with its robustness.
I was mocking up a screen that had some interactive elements: a few expand/hide controls, two form fields and a button. In Figma, I duplicated a screen, then made slight changes (this is both controls closed, this is the first control open, this is the second control open, this is both open, etc). Yet when I went to try to create a prototype that responded to the user, it quickly became a mess to try to work through.
Axure ain’t dumb. You can create an accordion menu that works like an accordion menu. You can add modals, and because you’re not creating a ton of pages that are copies of each other, if you have to change something on the page, you can change it once.
When it comes to creating a mockup that looks like the real thing, Figma is a dream. But if you’re trying to prototype something to get a sense of how it will function, it leaves some things to be desired.
You’d think I’d have learned by now, but I have happily started designing things in Figma and then realized its limitations as it relates to usability testing at three different jobs over the past three years. I’m not sure if that says more about the software, or my decision-making skills… 🤔
Consider what you’re trying to get done, before selecting the tool to use
There’s another option, as well.. the one that I started my career with, and that I’m flirting with returning to.
Build the thing with code
I started my career building prototypes in ASP. No, not ASP.net, I’m talking “Classic” ASP. Our prototypes weren’t a couple simple screens, they were robust applications in their own right, that pulled content from databases (including a translation database that enabled us to make sure our designs didn’t break when the German or French translation of our content was displayed.. if you’ve ever done any work with other languages, you know what I’m talking about).
Actually building the thing in code rather than in a design or prototyping tool gets closer to the ‘real thing’, which decreases some risk. If you can build a prototype that leverages production styles and scripts, you can feel more confident in your testing. You can play around with resizing your screen and seeing what comes out of it. You can see how existing styles may interact with what you’ve designed.
Of course, just jumping in to prototype in code can have some barriers, so I’m not quite ready to jump in. Although in the long-term there are plenty of benefits, for me right now it’s more important to be able to explore and communicate concepts quickly. Getting the pixel-perfection can come later (if needed.
There’s not a single best approach or tool for prototyping. It really comes down to why you’re prototyping. Is it to quickly explore or communicate an idea? To create something interactive and responsive? And how important is it to look or feel “like the real thing”? (we actually built a delay into our classic ASP prototype that more closely emulated how long it took for the results to display in our production product to make it more ‘realistic’). For any given job or project, a different tool may be the most appropriate.
