Back to feed
Renewal·마흔의 생활코딩

Some Thoughts on Prototyping Tools

NS
normalstory
cover image
YouTube 영상 미리보기YouTube
external media

Video summaries

  1. No summary yet.

#Prototyping tools: VS? Rankings? Seriously, what is this talk

Are you serious?

Are prototyping tools a matter of planning or of design? For reference, UX and GUI should not be confused. (If by any chance you are working on a team that calls the act of using a prototyping tool "UX"... that is an organization seduced by the visual. Leave.)

Prototyping tools exist, from the outset, to make something look plausible. They are meant to make it look plausible to the viewer, so the maker should not get buried in that plausibility themselves. The maker should focus on the essence of making. Whether it is Sketch or the grandfather of Figma showing up, in the end it is just a tool and does not carry meaning on its own. Prototyping is just one tool among many in the long list of steps of design thinking, limited to expressing ideas for online services. (= one of them)

The all-too-common prototyping

They say drivers are most dangerous in their 4th or 5th year after getting a license... Sometimes, when designing a GUI, you hear "PPT is enough," "Sketch is better," or talk of XD, Indigo, Axure, and so on. I can say for sure: none is definitively better or worse. Pick what fits your taste and circumstances. If licensing feels like a burden, just pick one of the free services, and when that goes paid, be ready to switch again to another new service. Of course, using a fixed service consistently helps with version management, but in the overall flow toward the real goal (communication shared among participants to release a service quickly), fussing over the tool is not something worth obsessing about. The prototyping phase is not a phase where doing well means mastering a single tool like a craftsman; it is a phase where you need to be able to flexibly, according to environment and requirements, pick the best tool at that moment and use it only to an appropriate level and quickly

When you say design thinking, grand phrases like "innovative thinking and creativity that deeply empathizes with people" tend to follow... But how can you exercise innovative thinking and creativity just by using one tool? The more familiar you become with prototyping, the more you risk letting adding one more asset or interaction degenerate into your best creative expression, so it is worth being careful.  

 

#In my personal case,

At the very beginning I use post-it notes. Once the flow and components are somewhat organized, I move to software tools. When I use software tools, if it is not for build-out but simply to propose an idea, I use PPT; when the client is viewing the prototype, I use Axure; and when prototyping an in-house service, I use XD. (Lately, the YouTube algorithm kept recommending Figma to me, so I casually tried it once, and within 7 minutes I thought, oh! With this I might not even need Zeplin. So I am now, belatedly, deep-diving into it.) 

 

#A bad example of prototyping

The biggest reason to learn prototyping might be flow or interaction. Watching things pop up, disappear, or move as if actually built, and once you get used to that, only then do you go back to looking for efficiency in your work. 

Sometimes a designer re-prototypes what the planner already prototyped, a situation that is almost too funny to laugh at. Not stopping there, some organizations then draw wireframes again on top of that prototyping result.  

If... this applies to your situation... I hope you can recognize, as soon as possible, that you are experiencing firsthand the process of humans making tools and those tools swallowing humans. 

 

#Work order

So I am organizing a learning (or work) preparation? order so that prototyping tools do not get used like PPT.

1. Sketch the overall GUI flow 

2. List the icons and buttons you need -> compose assets 

   - When exported, icons should have the same width x height, and pay close attention to whether pixel sizes are even or odd. 

3. Define types of text and color -> compose assets

   - Sizes can change, but it is good to organize by type: h1, h2, body, button, etc. 

4. Draw component clusters before details

5. Build component details using only the assets from steps 2 and 3  

6. Set up the flow

7. Express the interactions 

 

#Assets are everyone's work

The above process focuses on assets. The point is defining and sharing a reusable UI kit by type and use. Sometimes... people say, "This is too detailed, shouldn't the designer do it?" But in fact we have already been doing work like this. This is no different from the slides we used to make before starting wireframes to explain components. 

 

#The effect of assets

Of course the detailed styling is the designer's domain, but if there is a set of type-based assets defined upstream, only then can you really have a conversation with the designer. At the very least, you will no longer make the request "design me something gorgeous yet simple." At that point, the designer gets a clearer task and can concentrate their ability on that target.

In addition, if you use Zeplin or Figma, the more carefully these elements are defined in advance, the more you can set up conditions that let design work proceed in parallel or even before implementation.

 

#Recommended references 

In Figma there is a Variants feature, which seems very useful. Personally I have a blog and YouTube channel that have been helpful, so I am sharing them.  

https://nicecarrot2.tistory.com/179

 

[Figma] Let us look at the updated Variants feature (+ organizing existing component layers)

Let us look at Figma's updated Variants feature (+ organizing existing component layers). Hello. This is Danggeun. A new year has started, and among the important issues that changed after the Figma update, components are

nicecarrot2.tistory.com

https://www.youtube.com/watch?v=lMOJ1ijO9hs 

 

 

#Finally, what I think matters most is how efficiently you share and iterate prototyping, and what happens before and after it. Prototyping is not a task you make well and finish at once; it is a process (a tool) you make, share, and improve constantly. 

 

 

#End

Many organizations misunderstand this... collaboration and division of labor are clearly different. If a relay race is division of labor, collaboration is a three-legged race. Neither is better or worse. It is a matter of taste and choice. However, in a relay race, victory and defeat depend on how well the lead runners perform, and if you lose there is no joy. On the other hand, in a three-legged race, leader or follower does not matter; everyone participates, and even without winning, something warm in the chest keeps us smiling for a long time. 

For you, is the prototype tool (Figma? Sketch? XD?) a relay race or a three-legged race? 

This English version was translated by Claude.

친절한 찰쓰씨
Written by
친절한 찰쓰씨

Pleasant Charles — UI/UX researcher at AIT. Keeping notes on design, planning, and slow days here since 2010.

More on the author's page

Keep reading

Renewal

Steadily, for the long haul, without burning out

Mar 31, 2026·9 min
Renewal

Tech-life balance

Feb 7, 2026·3 min
Renewal

Humanality, by Park Jeong-ryeol

Feb 7, 2026·11 min