diff --git a/research/2026-09-08-save-and0return-interviews.md b/research/2026-09-08-save-and0return-interviews.md
new file mode 100644
index 000000000..f5709e2bb
--- /dev/null
+++ b/research/2026-09-08-save-and0return-interviews.md
@@ -0,0 +1,56 @@
+# Save and return interviews
+
+## 2026-09-08 / Sprint 
+
+## Aims
+- To learn about form creators’ expectations, concerns and questions about Save and return and One Login. 
+- (Stretch goal) We may also be able to confirm (or otherwise) assumptions we made about form creators' attitudes and expectations around the Copy of answers feature
+
+## Participants
+- 7 participants
+Form creators with a range of experience. 
+5 x content designers. 
+1 interaction designer. 
+1 lead developer.
+
+
+## Methodology
+- 60-minute interviews, exploring general feedback and showing some designs.
+
+## Key Headlines 
+### Scenarios: changing or archiving, disabling save and return
+- It’s important to communicate clearly to form creators what will happen when they make changes to a form that uses save and return.
+- In some circumstances, it will be important to communicate what was happening to form processors.
+- Something about processors knowing the form version submitted
+- Communication with form fillers about form changes is critical to avoid confusion or frustration.
+- Any saved data should be retained when changes are made to a form
+- Generally, it was assumed the form with saved progress would change to the new version.
+- There was an assumption that it will be possible to proactively communicate with people who have saved their progress.
+- If saved progress is going to disappear, remind form fillers in advance that you have their data and what they can / should do about it
+- If save and return were disabled for a form, there is some expectation that those who had saved progress should still be able to access and use saved data.
+- If a form is archived, there is an expectation of proactive communication with form fillers who have saved progress.
+- One Login could be a barrier to form fillers using save and return if they can't set up an account
+
+### Other functionality needs
+- Some users are likely to want different saved versions of the same form at the same time
+- The connection to personal email could be a barrier to form creators using save and return
+- Ideal data retention period is at least a month - maybe more
+- Having a “task list” view of the form would help meet several form filler needs
+- Sections would be helpful for longer forms and mentally chunking up the tasks.
+- Form creators could be keen to know who is responsible for the data and might need sign-off from their organisation again.
+- A need to better understand how it would work for the form filler
+
+### Form creator and form filler information / content needs
+- It would be helpful to know when it would be a good idea to use it, and see examples.
+- More certainty and steer would be helpful.
+- The page could be more concisely and simply presented.
+- They would find metrics on usage of save and return very helpful
+- It would be helpful to give form fillers enough information to make a more informed decision about whether to set up a One Login account
+- A lack of understanding and/or incorrect assumptions about One Login could be a barrier to form creators using save and return
+- The live form page is getting too long and busy.
+- A need to understand how the data is treated
+
+## Supporting Evidence
+- [Report](https://docs.google.com/presentation/d/16Zi3AX2MB-b3Llr1J0J6SNnKB9NNQAtlkqtwFPgUJ94/edit?usp=drive_link)
+- [Playback](https://drive.google.com/file/d/13rtyeLvcUEPt6tvAVp77s1XLkCZvTqzz/view?usp=drive_link)
+- [Further documentation](https://drive.google.com/drive/folders/1tF9HLJ9n34-0sOmjeYzTMZw5q6Dh-ynU?usp=drive_link)