UX/UI Design

Web App

Confidential Document Portal

Web Application for secure documentation

UX/UI Design

Web App

Confidential Document Portal

Web Application for secure documentation

UX/UI Design

Web App

Confidential Document Portal

Web Application for secure documentation

This project was completed under a non-disclosure agreement (NDA). To protect confidential information, I’ve omitted sensitive details, replaced proprietary elements with placeholders (e.g., Lorem ipsum), and generalized metrics. The focus here is on my process, problem-solving approach, and impact.

Company

Automotive (heavy vehicles)

Year

2023 - 2024

Product

Confidential Document Portal

Role

UX/UI Designer and Business Analyst

Duration

One year

Task

Design a MVP of the web platform.

Tools

User Interviews, User Profiles, User Flows, User Testing, FigJam, Figma

Target Users

Engineers who work for the company.

Results

A secure sharing platform used by most of the company's engineers.

Problem

A global automotive manufacturer needed a secure, high-performance web platform for internal engineers to access confidential technical documentation. These were the known points indicating the need for a secure sharing platform:

  • There are more than 10 different type of documents. Some documents are multi-thousand-page PDFs (averaging ~4,000 pages) with embedded system models, resulting in massive file sizes.

  • No way to prevent unauthorized distribution—documents could be freely downloaded, printed, or shared externally.

  • Different stakeholders (engineers) have different needs using the documentation.

Problem

A global automotive manufacturer needed a secure, high-performance web platform for internal engineers to access confidential technical documentation. These were the known points indicating the need for a secure sharing platform:

  • There are more than 10 different type of documents. Some documents are multi-thousand-page PDFs (averaging ~4,000 pages) with embedded system models, resulting in massive file sizes.

  • No way to prevent unauthorized distribution—documents could be freely downloaded, printed, or shared externally.

  • Different stakeholders (engineers) have different needs using the documentation.

Problem


A global automotive manufacturer needed a secure, high-performance web platform for internal engineers to access confidential technical documentation. These were the known points indicating the need for a secure sharing platform:

  • There are more than 10 different type of documents. Some documents are multi-thousand-page PDFs (averaging ~4,000 pages) with embedded system models, resulting in massive file sizes.

  • No way to prevent unauthorized distribution—documents could be freely downloaded, printed, or shared externally.

  • Different stakeholders (engineers) have different needs using the documentation.

Responsibilities

Working alongside the development team (6 developers) and the Product Owner, I took on a dual role as both UX/UI Designer and Business Analyst. I led the research phase, conducting interviews with several engineers, collaborated with the team to define key features and designed the interface for the MVP.

Working alongside the development team (6 developers) and the Product Owner, I took on a dual role as both UX/UI Designer and Business Analyst. I led the research phase, conducting interviews with several engineers, collaborated with the team to define key features and designed the interface for the MVP.

Design Process

User Research and Discovery

To address the platform’s global scale and complexity, I led a multi-phase research initiative:


In-Depth Interviews

Conducted 30+ interviews with engineers across 5 distinct functional groups in Sweden, the U.S., France and Brazil. In these interviews, I:

  • Uncovered critical regional and role-based differences in documentation needs.

  • Observed how each group of engineers uses their work tools related to documentation.

  • Observed how they share or access documentation.


User Tasks and User Flows

Created 6 different user profiles and their user flows to accommodate:

  • The tools/softwares they use.

  • The different documents they need to have access to.

  • Their workflows for frequent actions based on their role-specific tasks.

  • Their tasks and responsibilities related to the creation/reading of the documents.

  • How they share and get access to the documents.

  • Their pain points in the actual workflow.

  • Their needs and whishes to make their workflow faster, easier and more efficient.


Tool and Document Taxonomy

Developed a centralized knowledge board on FigJam to map and organize the amount of data collected:

  • Software/tools used by each group and what is their function in this context.

  • The different types of documents, who produces them, who needs to consult them, and for what purpose.

Design Process

User Research and Discovery

To address the platform’s global scale and complexity, I led a multi-phase research initiative:


In-Depth Interviews

Conducted 30+ interviews with engineers across 5 distinct functional groups in Sweden, the U.S., France and Brazil. In these interviews, I:

  • Uncovered critical regional and role-based differences in documentation needs.

  • Observed how each group of engineers uses their work tools related to documentation.

  • Observed how they share or access documentation.


User Tasks and User Flows

Created 6 different user profiles and their user flows to accommodate:

  • The tools/softwares they use.

  • The different documents they need to have access to.

  • Their workflows for frequent actions based on their role-specific tasks.

  • Their tasks and responsibilities related to the creation/reading of the documents.

  • How they share and get access to the documents.

  • Their pain points in the actual workflow.

  • Their needs and whishes to make their workflow faster, easier and more efficient.


Tool and Document Taxonomy

Developed a centralized knowledge board on FigJam to map and organize the amount of data collected:

  • Software/tools used by each group and what is their function in this context.

  • The different types of documents, who produces them, who needs to consult them, and for what purpose.

Design Process

User Research and Discovery

To address the platform’s global scale and complexity, I led a multi-phase research initiative:


In-Depth Interviews

Conducted 30+ interviews with engineers across 5 distinct functional groups in Sweden, the U.S., France and Brazil. In these interviews, I:

  • Uncovered critical regional and role-based differences in documentation needs.

  • Observed how each group of engineers uses their work tools related to documentation.

  • Observed how they share or access documentation.


User Tasks and User Flows

Created 6 different user profiles and their user flows to accommodate:

  • The tools/softwares they use.

  • The different documents they need to have access to.

  • Their workflows for frequent actions based on their role-specific tasks.

  • Their tasks and responsibilities related to the creation/reading of the documents.

  • How they share and get access to the documents.

  • Their pain points in the actual workflow.

  • Their needs and whishes to make their workflow faster, easier and more efficient.


Tool and Document Taxonomy


Developed a centralized knowledge board on FigJam to map and organize the amount of data collected:

  • Software/tools used by each group and what is their function in this context.

  • The different types of documents, who produces them, who needs to consult them, and for what purpose.

Key Findings

More problems were identified after the interviews:

  • The reason why the main document can have over 4,000 pages is that it contains layers upon layers of embedded system models, which must be converted and added as images to the PDF.

  • Some engineers do not have access to the software that generates the embedded system models and rely on the PDF to view them. These embedded system models contain information within their components that is essential for the engineers' work. Currently, this information is displayed through pages and pages of tables, significantly contributing to the PDF's massive page count.

  • There is no consistent process for document sharing. Some teams use a shared folder, while others send documents via email. As a result, files are often mistakenly overwritten in the shared folder or get lost among countless emails.

  • Some engineers still need offline access to the documents due to the lack of internet connectivity in remote locations where vehicle testing is conducted.

  • Some engineers would like to be able to compare two versions of the document.

  • Many users only need to consult a specific part of the document.

Key Findings

More problems were identified after the interviews:

  • The reason why the main document can have over 4,000 pages is that it contains layers upon layers of embedded system models, which must be converted and added as images to the PDF.

  • Some engineers do not have access to the software that generates the embedded system models and rely on the PDF to view them. These embedded system models contain information within their components that is essential for the engineers' work. Currently, this information is displayed through pages and pages of tables, significantly contributing to the PDF's massive page count.

  • There is no consistent process for document sharing. Some teams use a shared folder, while others send documents via email. As a result, files are often mistakenly overwritten in the shared folder or get lost among countless emails.

  • Some engineers still need offline access to the documents due to the lack of internet connectivity in remote locations where vehicle testing is conducted.

  • Some engineers would like to be able to compare two versions of the document.

  • Many users only need to consult a specific part of the document.

Key Findings

More problems were identified after the interviews:

  • The reason why the main document can have over 4,000 pages is that it contains layers upon layers of embedded system models, which must be converted and added as images to the PDF.

  • Some engineers do not have access to the software that generates the embedded system models and rely on the PDF to view them. These embedded system models contain information within their components that is essential for the engineers' work. Currently, this information is displayed through pages and pages of tables, significantly contributing to the PDF's massive page count.

  • There is no consistent process for document sharing. Some teams use a shared folder, while others send documents via email. As a result, files are often mistakenly overwritten in the shared folder or get lost among countless emails.

  • Some engineers still need offline access to the documents due to the lack of internet connectivity in remote locations where vehicle testing is conducted.

  • Some engineers would like to be able to compare two versions of the document.

  • Many users only need to consult a specific part of the document.

Value vs. Effort Matrix

To help define and prioritize other MVP features, our team used the Value vs. Effort Matrix. As a UX Designer and Business Analyst, I advocated for the features I believed would deliver the most value to users based on insights from the interviews. Meanwhile, the development team identified which features required the least effort to build. As a result, the features positioned in the "High Value, Low Effort" quadrant were selected for MVP development.

Solution

Jointly Defined Requirements

Through alignment between our team (developers, Product Owner, and designer/business analyst) and client stakeholders (project manager), the following key decisions were established:


Access and Security

Only pre-approved employees (vetted by their managers) will have access to the platform. They will log in using their corporate email and work password.


Controlled downloads

Only manager-approved users may download the full PDF.


MVP Scope

Due to technical and development constraints, only the primary document type will be available in the initial release.


PDF Format

The PDF format will be retained to leverage users’ existing familiarity with PDF readers and index navigation (Jakob’s Law). This ensures minimal training needs and immediate usability.


Interactive Embedded System Models

Users can drill down into embedded system levels, reducing effective page count and improving information access.


Component Data

Clicking any component displays a pop-up with the same data as the native engineering software—enabling access for engineers without direct software licenses.


Version Comparison

Engineers can compare two document versions to track edits (additions/deletions).




Bookmarking

Users can favorite chapters/items for quick retrieval.

Lessons Learned


  • One of the biggest challenges was navigating technical limitations. Many of the features users requested were difficult or impossible to implement due to time constraints or technical complexity.

  • I learned how to bridge user needs and development constraints by prioritizing features that added the most value with the least implementation risk—thinking not just as a designer, but also as a strategist.

  • Close collaboration with developers helped me understand technical boundaries and co-create feasible alternatives that still improved the user experience.

  • This experience taught me that great UX isn’t just about ideal solutions—it’s about finding the best possible path within real-world constraints.

Lessons Learned


  • One of the biggest challenges was navigating technical limitations. Many of the features users requested were difficult or impossible to implement due to time constraints or technical complexity.

  • I learned how to bridge user needs and development constraints by prioritizing features that added the most value with the least implementation risk—thinking not just as a designer, but also as a strategist.

  • Close collaboration with developers helped me understand technical boundaries and co-create feasible alternatives that still improved the user experience.

  • This experience taught me that great UX isn’t just about ideal solutions—it’s about finding the best possible path within real-world constraints.

Impacts


  • In May 2024, the MVP was launched. This first version is basic and only includes a simple search system.

  • Most engineers now use our web application instead of downloading and sharing PDF files, drastically reducing file downloads.

  • Currently, the developers are working on developing the advanced search.

  • The next features to be developed will be the interactive models and the version comparison tool.

Impacts


  • In May 2024, the MVP was launched. This first version is basic and only includes a simple search system.

  • Most engineers now use our web application instead of downloading and sharing PDF files, drastically reducing file downloads.

  • Currently, the developers are working on developing the advanced search.

  • The next features to be developed will be the interactive models and the version comparison tool.

Impacts


  • In May 2024, the MVP was launched. This first version is basic and only includes a simple search system.

  • Most engineers now use our web application instead of downloading and sharing PDF files, drastically reducing file downloads.

  • Currently, the developers are working on developing the advanced search.

  • The next features to be developed will be the interactive models and the version comparison tool.

View More Projects

LORE

The first AI-powered livestock management assistant, using data to optimize farm productivity, leading to PRODAP's acquisition

Product Design

App

AI

LORE

The first AI-powered livestock management assistant, using data to optimize farm productivity, leading to PRODAP's acquisition

Product Design

App

AI

LORE

The first AI-powered livestock management assistant, using data to optimize farm productivity, leading to PRODAP's acquisition

Product Design

App

AI

PRODAP Views Master app in a blured cattle field background

PRODAP Views Master

Livestock management app to to streamline pasture and cattle monitoring nearly 1 million cattle across 1.45M hectares for 190+ clients

Product Design

App

PRODAP Views Master app in a blured cattle field background

PRODAP Views Master

Livestock management app to to streamline pasture and cattle monitoring nearly 1 million cattle across 1.45M hectares for 190+ clients

Product Design

App

PRODAP Views Master app in a blured cattle field background

PRODAP Views Master

Livestock management app to to streamline pasture and cattle monitoring nearly 1 million cattle across 1.45M hectares for 190+ clients

Product Design

App

A screen of a laptop with Nanolyze application opened

Nanolyze Analytix

Developed a scalable e-commerce platform that increased sales by 35% through intuitive navigation and faster load times.

UX/UI Design

Software

A screen of a laptop with Nanolyze application opened

Nanolyze Analytix

Developed a scalable e-commerce platform that increased sales by 35% through intuitive navigation and faster load times.

UX/UI Design

Software

A screen of a laptop with Nanolyze application opened

Nanolyze Analytix

Developed a scalable e-commerce platform that increased sales by 35% through intuitive navigation and faster load times.

UX/UI Design

Software

Contact

lucisprados@gmail.com

+46 73 860 5149

Connect on Linkedin

Back to top

Contact

lucisprados@gmail.com

+46 73 860 5149

Connect on Linkedin

Back to top

Contact

lucisprados@gmail.com

+46 73 860 5149

Connect on Linkedin

Back to top