My Documents
Creating a separate domain in a closely collaborating cross-functional task force for GetAccept.
Role
Product designer
Skills used
User research, Interaction design, Prototyping + Testing
Project
Work
Year
2024
Time frame
3 months
Problem discovery
The problem
Users must go back to their emails to find a link to their received documents.
Users receive too many emails.
Users want to be able to keep track of all their received documents easily.
Users want to know what they have to do with their received documents at a glance.
The goal
Create a view where users can easily access and see all of their received documents, and the actions they should take.
The background
During this initiative, I was the main designer in a cross-functional task force.
GetAccept is a Malmö-based B2B SaaS company aiming to optimize the buying and selling process.
Solution discovery
The process
We follow a lean methodology at GetAccept and have employed build-measure-learn in this case.
BUILD
User research
Both our customers and internal users have experienced difficulties with keeping track of documents they’ve received. While our product manages sent documents, the recipients’ side is often forgotten.
We conducted internal interviews and talked to our customer-facing colleagues to pin down the pain points and what would be necessary in a recipient document portal.
We compiled this information into a MSCW list, and started ideating.
BUILD
Competitor analysis
We investigated how competitors arranged their client portals, by looking at products like DocuSend and Dropbox Sign.
BUILD
Prototype
We also created several different iterations of the portal at this point.
After presenting our flows and iterations to stakeholders, there were several back and forth discussions on what information in the portal were particularly important. We headed back to our customer-facing colleagues to ask for insights they had gathered from our users.
We were then able to decide on an MVP for our portal, and fleshed out details such as the empty state and wrote out acceptance criteria.
We started with mapping out flows due to hard security limitations. As some of the documents are sensitive contracts, we needed to assure that whoever was accessing this portal was who they said they were. Login, security token expiration, and identification were plotted out together with the platform team and product manager.
MEASURE
Validation testing
We wanted to confirm that users could find “My Documents” so we did a simple task analysis test on Ballpark asking participants to find the entry point.
LEARN
Reiterate
Following our validation testing was more fine-tuning iterating. Together with the frontend developer, we worked how to display all the necessary information and screen responsiveness.
Due to limited space on smaller screens, we had to decide together what information to prioritize in the table, and what information could be tucked into a side sheet.
The current design allows all the information to be viewed from the side sheet on a smaller screen, while maintaining the most important information (i.e., document name and action to take) in the table.
The design
The design
The final result is a table structure that follows a consistent pattern with the other domains in the core product. We made sure all the most important information is displayed from the left to right, allowing responsiveness while maintaining all the usefulness of the information and clarity.
The sidesheet allows all the information to be accessed easily at once, while the table provides information at a glance. Depending on the screen size, different amounts of columns of information can be displayed, however, all the most important pain points such as finding documents and knowing what actions to take are solved.
Of course, design process never ends. When feedback comes along, we will continue to reiterate.
What did we learn?
Results
As this domain is newly released, we are still awaiting customer feedback.
Takeaways
Close collaboration is key. Ideating with developers can save a lot of time and effort spent on reiterating.
Involve backend earlier in the process. While collaborating with frontend developers during solution ideation and iteration is a must, it’s easy to forget that backend needs to be involved at this stage also to avoid needless reiteration based on limitations from the platform.
More projects