This content originally appeared on Adam Silver and was authored by Adam Silver
When you design a product, you should usability test it.
Otherwise, you won’t know how well it works.
Typically you either:
- create and test a prototype
- build it in production and test there
Building it in production is usually the most expensive and risky approach so lets leave that out for today.
Which leaves us with prototyping.
But not all prototypes are created equal.
So how do you know which to use?
I follow this rule:
Do the cheapest thing to test your idea
Let me break this down:
“Do the cheapest thing”
Self explanatory. Organisations generally don’t want to waste time and money.
“To test your idea”
This is more tricky.
Because you can test your idea in all sorts of ways. For example, you could tell someone about your idea and verbally describe how it works. No need for a prototype.
But even if you articulate it clearly and users love the idea, how confident can you really be that people will be able to use it?
Not very.
That’s an extreme example to make a point, but what’s less clear is the difference between prototyping in Figma vs HTML.
Prototyping in Figma
Figma’s advantage is that most designers can use it (you don’t need to know how to code).
So it’s usually cheaper and faster to use Figma over HTML.
But Figma is not as realistic as HTML. For example, users can’t:
- fill out a form
- use a screen reader
- switch from portrait to landscape
This makes research insights less reliable.
Also developer hand off isn’t as efficient. Developers have to work a lot harder to translate (what are effectively) pictures of software into actual software.
So there’s a greater risk of something being lost in translation.
Prototyping in HTML
The problem with HTML is that most designers don’t know how to code. And HTML prototypes are usually more expensive to create compared to Figma.
But HTML prototypes are realistic and almost identical to the real thing. So users can do things like:
- fill out a form
- use a screen reader
- switch from portrait to landscape
This makes research insights far more reliable.
Also developers have less to translate. Sometimes developers can use the code that has already been used for the prototype.
“But what if the designer can’t code?”
You either:
- Make do and increase the risk to UX
- Hire a designer that can
- Train your designer to use code
- Give your designer a developer to work with
“Do you really need to create an HTML prototype if you’re just testing the general flow?”
No, probably not. But at some point, you’re still going to want to test a high fidelity version to give you confidence and reduce risk.
“But isn’t it faster and cheaper to prototype in Figma?”
No, not necessarily.
For example, I design GOV.UK services. We have a mature design system and a prototyping tool. So I’m faster in code than I am in Figma.
If you’re an interaction designer or content designer who also works on GOV.UK services and would like to be able to create interactive, accessible and realistic HTML prototypes (without knowing much code), you might like my new course, the GOV.UK Prototype Kit Bootcamp:
https://prototypekitcourse.com
This content originally appeared on Adam Silver and was authored by Adam Silver
Adam Silver | Sciencx (2024-04-09T00:00:00+00:00) Figma prototypes vs HTML prototypes. Retrieved from https://www.scien.cx/2024/04/09/figma-prototypes-vs-html-prototypes/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.