Firstly with the state changing I wouldn't worry about the button being in the same place. The user is performing a different action in both instances so will likely expect there to be different consequences.
There are 3 options you could go with for this.
Option 1
Which from what I understand is fairly similar to what you have already.
Replacing the posted note state itself with an inline edit state is a fairly recognised pattern amongst large communication applications for desktop. This would be a good option to go with. I would look at what the Slack desktop client does when it comes to messaging.
This is a message that has been posted:
Then when someone wants to edit their message, the state of the message itself changes to this (similar to what you have above):
The same thing also happens on Microsoft Teams client/browser app.
Original message:
Editing message:
This is a fairly recognised pattern.
Option 2
Do what Stack exchange does when posting an answer and present the edit window above/below the original post with the editable text in and allow the user to see the post change in realtime with the edits they're making.
Option 3
Like Evernote, you tap on a note and the whole thing becomes an editable text window. Red (left) is the note you tap (or in your case select 'edit') and on the right (yellow) is the space where you edit and it autosaves negating the need for a save button.
Both would be reasonable ways to do this, Im aware that these are comms apps but its a good example.
Test
To validate either of these you could test it with users and ask:
- Before you press edit, what would you expect to happen once you click it?
- Now you have clicked it, is that what you expected? Why?
- Have you seen this anywhere else before?
And see what they say. It doesn't need to be an all singing all dancing prototype just something simple.
