It is possible to use resistive connection pads like you show, but capacitive pads are generally better. Resistive pads leave a direct connection to the circuit open to the outside. They are therefore susceptible to damage from static discharge and noise.
Capacitive pads are a better method, although they require a bit more firmware to sense, at least if you want to do it well. Note that to get even rudimentary noise immunity, resistive pads require firmware too. Just connecting two pads to something sensitive, like the gate of a FET, is a bad idea. You won't be able to cancel common mode and other ambient noise.
Here is the layout of a small board I did recently just to research capacitive buttons:
The cap pads are small disks 150 mils (3.8 mm) in diameter and otherwise surrounded by ground on the top layer. The microcontroller is a PIC 16LF1786. It and all the other parts that aren't for directly interfacing with the user are mounted on the bottom of this two-layer board.
The PIC continually scans the pads. When it detects a change in the pressed/released sense of a pad, it sends a message over the serial port, updates the lights at top right, and emits a beep on a press.
For testing, I can have the PIC regularly send its internal values for the pressedness of each pad. Here is a plot of all five raw sense values, in addition to the overall something-is-pressed digital state as I pressed each pad in succession with my finger:
As you can see, the noise immunity is exceptional. Even the weakest signal was well over 300, while noise was ±2 or so.
The magenta trace labeled "Pressed" shows the OR of the individual button pressed states. Its levels show the press and release thresholds. There is much extra signal that is not used in this case. These particular thresholds were tweaked to be able to tolerate a few layers of paper above the buttons.
Of course there is some clever handling of the button lines and processing, even if I say so myself, but clearly the results are achievable with quite a modest microcontroller.
I am using this in a real product where the same micro is also managing a character display. That's a basic user interface subsystem I plan to re-use in several future products. It interfaces to the main system controller over a serial port. The main controller sends commands for writing to the display, and receives asynchronous messages whenever the state of a button changes.