When you say there are no changes to the screens - I suspect you mean there are supposed to be no changes to the software accessed or used by the screens.
I do not generally believe when some suggests there are no changes - even if the appearance is the same I suspect the code in the back end is changed.
Nonetheless I would usually type to regress at the workflow level.
(0) consider business - technical - organizational context factors - make sure changes to system meet intended goals.
(1) Identify usage scenarios which use screens 1 to 10 (set A)
(2) regress usage scenarios which use screens 1 to 10 (set A)
(3) identify usage scenarios impacted or added by the changes in screen 10 (set B)
(4) develop tests for (set B)
(5) run tests for (set B)
(6) review with developers for cross feature interference identify scenarios which use code that was changed (set C)
(7) regress (set C)
(8) review code changes for non-functional risks such as performance - scalability - usability - define a set of non functional tests (set D)
(9) regress (set D)
(10) consider robustness - attempt to break screen 10
(11) consider other risks based on environment - etc
note - I like to use API to access functionality