It sounds as if you are seeking a formulaic answer about a specific button pattern fit for an exclusive purpose and feel that this goal is not being met.
Straight off the bat, there is no such formula. But here are a few things to consider.
Link Buttons Are a Thing
Text-only, rimless buttons have become a fairly common interface element without being restricted to a sole purpose of hyperlinking. Are link buttons used elsewhere in your application? Are they readily identifiable as buttons, in other words, do they have appropriate affordance? And have you tested that with actual users?
A link button, which is what your UX coworker likely specified, is not the same as a hyperlink when used in isolation. Confusion between the two will likely only result on a page with a lot of body text into which true hyperlinks are embedded, such as a wiki. But even in that event a link button is still distinguishable from a body of text with interspersed hyperlinks by spacing and brevity of labelling.
Bowing to Superior Knowledge
It is perfectly legitimate to ask the UX'er you're collaborating with for a rationale behind his or her decision if you have concerns about a control's affordance (its discoverability or findability). Withdraw from the opinion bashing party and test with users. Don't make that the sole objective of the exercise but roll the affordance question into a wider usability test setup where you devise an authentic workflow for your participants to pursue and observe whether they find the appropriate controls, and whether it causes them hesitation.
A Short Thing About Modals
Use true modal behaviour - whether implemented as a side panel or floating dialog is secondary, I'm talking about behaviour - to intentionally stop all other interactions and force the user to complete a critical intermittent step. Everything outside the modal zone should cease to function until the task presented modally has been completed or abandoned. I'm describing this, if perhaps in a slightly dogmatic tone, to illustrate the difference of a true modal as opposed to an expanding/retracting side panel the content of which works interactively with what's on the main screen. That difference is not trivial.
Another Short Thing About Language
By your description the label 'Close' may not be enough. It sounds like the information a user has just provided will be cleared, so it's more akin to an abort function. That consequence to my mind needs to be clear to them, for instance by a label 'Clear all and close'. I cannot imagine that that is the primary purpose of the modal, so your colleague likely had a reason to tone down the abort function.
So we need to consider something else:
Calls-to-Action, Affordance, and Decision Hierarchy
To leave the user in no doubt about the need to finish the intermittent task, the modal needs to present unambiguous calls to action (CTA). If your modal presents a series of forms to fill out, or profile type selections to make, that would be a 'submit' function (irrespective of the true labelling of that button, which is context driven).
If that 'submit' function conveys a simple two-way decision like 'Cancel' and 'OK', decide whether by the application's context the two CTAs need to be presented evenly (bias free) or in a way where one is marked as the intentional path, in which case you may use button hierarchy for emphasis: The intentional path - usually the confirmation option - should have higher visual salience than the abort option: Both are available but you're leading the user toward a preferred outcome. The same applies to a multi-way decision with more than two CTAs, of which only one (if any) should be presented as primary, and only if that reflects the truth of the matter. Else, present all CTAs as equal, in a flat hierarchy.
If your modal has a singular call to action (e.g. 'Done', meaning done and close), CTA hierarchy becomes irrelevant as such. In that event I would set the visual strength of the singular CTA appropriate to the rest of the content.
A common three-tier CTA hierarchy often uses filled buttons for the primary, outlined buttons for the secondary, and link buttons (label text only) for the tertiary layer of importance. Treat a three-tier hierarchy in a modal with caution.
A Matter of Context
Critical to CTAs is salience: How assertively is the you-must-finish-this requirement of a modal conveyed, in context of the rest of the modal content?
If the modal content is complex and visually noisy, a punchier button design is indeed warranted as the CTA must 'out-shout' the fussiness of the rest of the modal's UI. All the more so if you keep the CTA disabled pending completion.
However for more visually reticent modal content, a rim-less link button, offset by enough whitespace or padding, fulfils the same purpose. In that case, an overly bold CTA would actually dominate the content we want the user to focus on.
Don't Skimp on Testing
A simple usability test (with real users, not other developers or other in-house coalitions of the willing, please) on the discoverability of the CTA should bring clarity over whether it's salient enough. In that case, suppress your urge to win the argument and start with the link button option, and observe (and neither of you lead the witness, please) whether the call to action has sufficient affordance for users to know how to complete the task. If the affordance is too weak, and check this with min. five unbiased users, there might indeed be a case for a visually punchier button.
Users consume page content as a whole, and how you strengthen or attenuate the look and feel of calls to action needs to fit with the total composition of the page.
Review the above in context with what your modal shall accomplish; by all means express concerns about salience, discoverability, and affordance - here's some vocab to Google - and encourage user testing so both of you distance yourselves from mere opinionatedness. In so doing, however, be mindful that it is the UXer's
professional responsibility to ensure the thing you're developing together is up to the task and meets the user's needs.
<button>
and<a>
, or is it just about the styling of the element? – Bergi Aug 22 '19 at 23:07