Great question because power users are often forgotten about when considering usability testing.
You have two different types of users.
These two types are commonly called 'novices' and 'experts'.
A novice is anyone who is seeing your application for the first time (or one of the first times). This group is still deciphering what your interface is communicating regarding what is possible (the features and content available to them), your application's structure (the information architecture) and how to navigate through it and interact with it all (the interface). They could be subject matter experts, but they are novice in the sense of not having had exposure to your application.
When you test this user, you are typically testing 'learnability' - how well they do the above mentioned and complete tasks as new users of your application.
An expert has interacted with (or seen documentation or had training for) your application before, enough that they understand the steps needed to complete the tasks you're interested in. This is as you put it, your 'power user'.
When you test this user, you are typically testing 'efficiency' - how quickly and effortlessly they can complete a task given they already know how to do it.
What you're testing is different (and thus your approach has to be).
I think you probably have the novice user testing for learnability under control. This is the type of testing most UX Designers / other practitioners are familiar with - getting newly recruited test participants to work through tasks, talking out loud as they go for further insights.
Expert users and testing efficiency
Without users (predictive)
- KLM/TLM GOMS - This is the process of counting the number of interactions a user would need to complete a task. Each type of interaction (like a movement of the mouse, a swipe of the thumb, a pressing of a key) is given a time cost, and then summed together to give an approximate total time to complete a task. This assumes the task is completed with no issues encountered and no detours taken (which is why this method only makes sense in the context of expert users). You would use this to compare your two designs and see just how much of a difference there really is.
- User testing (but done seemingly incorrectly) - Where we've all learnt not to help the user, that goes out the window. Make your test participant an expert by providing them training resources (like how-to guides), prior access to the designs/prototype/application, and conduct a walkthrough where they can ask further questions. Also, rather than your typical think aloud session, don't instruct the participant to talk out aloud. While Jakob Nielson disagrees with that (advocating for still getting them to do so) he also says "Skilled behavior is often automated behavior... when people are unaware of how they think about a certain behavior, they can't verbalize the reasoning behind their actions." My preference is to only prompt them if i think the pause or hesitation warrants explaining, otherwise ask afterwards.