Context

Source2Sea is a Danish startup on a mission to bring transparency and efficiency to maritime supply chains. It offers a B2B SaaS platform connecting suppliers with on- and offshore purchasers, allowing them to browse catalogues, manage orders, and coordinate deliveries. In a world where one wrong order can disrupt an entire voyage, Source2Sea’s promise is simple: what you click is what you get.

Most portfolios are full of UI screenshots. Fewer show how someone works in real-world constraints: priorities, sprints, field research, backlog management, design debt, QA, etc. My aim is to give you an overview of my work environment at Source2Sea.

My Role & Responsibilities

As the product designer, I worked across the entire product lifecycle — from discovery to delivery. My key responsibilities included:

• Design activities from research to delivery and QA

• Interview onshore suppliers, offshore Chefs and Crew

• Capturing insights and translating them into design directions

• Advocating for user needs across product discussions

• Collaborating closely with engineering, product, sales and customer service

• Maintaining, scaling and changing the design system

• Managing front-end scope, transactional emails, and design QA

• Supporting Agile ceremonies and backlog prioritization (Azure DevOps)

• Improving design maturity through heuristics, documentation, and guidance

Ways of Working

At Source2Sea, we followed an agile model grounded in Lean UX and a by-the-book Scrum, driven by OKRs. We delivered iteratively in small, validated chunks — always aiming to reduce waste and deliver value. We were able to experiment with our ways of working as a team, and establish new processes that was tailored to our team's liking. I was part of the product design squad and reported to the Head of Design. We have had our team ways of working as well as global ways of working.

Design as a discipline had an integral place at Source2Sea. For a 20 person startup we had 4 designers who were involved into all areas and discussions of product delivery. All development work started with design first.

We worked with a strict and well oiled rhythm that looked like this:
Problem discovery → Definition → Prioritization → Design → Validation → Build → QA → Feedback → Repeat

Problem discovery

At Source2Sea, some of our most meaningful design work began with field research — whether through expert interviews, remote sessions with vessel staff, or site visits.

Field research was by far the most impactful. It allowed us to immerse ourselves in the user’s environment and uncover needs that no interview script could surface. As an example, after spending time onboard a vessel with a chef (our end user), we gained crucial insights into how our provisioning app needed to adapt to real-life constraints like delivery timing, cultural needs, and harsh weather conditions.

Each field trip was done in pairs: one designer moderated, the other documented. We also took a PM or internal expert with us. We prepared thoroughly ahead of our trip — crafting a plan with hypotheses, guiding questions, and logistics. Our goal wasn’t just to ask, but to observe: what did they do while on a ship, how did the crew receive their stock, what did the paperwork and invoicing look like, how did they solve issues with the order, how does the stocktaking work, how about miscellaneous items in the order. We aimed coming back home with the most information possible to ensure practical decisions in design for our end-users.

Problem Definition

The learnings that we have returned with were organised and analysed.
The raw notes have been transferred into a document that we shared on a company platform so that any colleague could access it for reference.

Designers analysed the data and turned them into an affinity diagram, that typically covered two of our office walls. This helped visualising which areas of our service of software performs well, where are the most frequent issues and what kind. With this knowledge we were able to form problem areas.

These areas were translated into requirements, sliced down into feasible pieces, and defined well with rich information. At Source2Sea, all projects were formal agreements between the product trio: product, design, and development. There was no room for ambiguity — each initiative was clearly defined in terms of scope, goals, and constraints. Developers played a vital role during definition sessions, contributing technical perspectives on logic, feasibility, dependencies, and complexity.

These collaborative discussions were supported by a detailed requirements specification document, initially drafted by product and then presented to the delivery team. Together, we clarified, adjusted, and completed the document to ensure shared understanding before work began.

Sprints

As a designer I have worked in 2 week sprint and aimed to have my work completed by every second refinement session - some complex features required more time. As we worked in Lean framework we delivered small chunks often.

Before the beginning of the sprint we kicked of one of the requirements from the definition session per designer. Within these 2 weeks I have done a couple of discovery meetings with internal domain experts and began sketching an idea and the new components where applicable.
I brought those to developers almost after each decision point. This was called the Jam session. I learned a lot about our software from the technical side during these short meetings that helped me be better with future decisions. The solution was not aimed to be perfect, nor high on visuals. The goal was providing value to the users fast. We could always iterate on the implemented solution in the next sprint.

During the same sprint I have done 1-2 review and a handover session so all developers were onboard before the refinement session.

Sprint ceremonies

Retrospective, Refinement, Planning, Backlog refinement, Standup.

As a designer, I was part of a development team, therefore I took full part in all of the above ceremonies.

Retrospective - The most important of them all. After each sprint has ended we took a look how the last sprint has been. We always had 4 'L' areas to fill out: Liked – things you really liked, Learned – things you have learned, Lacked – things you have seen the team doing but consider that could be done better, Longed for – something you desired or wished for. We filled out these areas and took turns in reading them aloud to fully convey the message. We created action items from the inputs and added an assignee. We followed up on the progress next retro. These action items gone into sprint planning when necessary so all the works were carefully counted into our sprint capacity.

Backlog refinement - I've initiated this as it was a lacking process. I loved organising all our AzureDevops works, cross-team. We have teamed up with our PO, QA, a knowledgable BE and a FE developer.
Together we have gone through the work items, every one of us bringing the next important item from our own domain and placed them to the top of the list within each epic that we have used as a drawer. We gathered once a sprint. With QA we prioritised (at least) 3 most urgent bugs for the next sprint making sure they get their chance.

Refinement - Booked for 1,5hr. We usually made it in time, thanks that all the designed work has been clarified ahead of refinement. During this session we have gone through the items located on top of the backlog. We have read out the description, need, requirements, scope and out of scope items, future iterations and acceptance criteria. As a designer I have read out the tickets about my own work. Based on all that knowledge developers voted on the effort and decided on a story point. Gradually I have voluntarily taken care of the whole refinement sessions myself.

Planning - We have had a very strict step-by-step recipe how to do a proper planning. The tasks and responsibilities were all documented. This may seen much but our plannings were perfect because of that effort. No spillovers, accurate capacity, dedicated time for discovery.

Standup - We were throwing the random ball. There was a volunteer who started the standup and mention what has been accomplished yesterday, what are the plans for today and if there are any blockers. Not more, not less. The volunteer then picked a random next person. At the end of the meeting we shared 60sec outlining absences for the day.

Design ceremonies

Warmup, Design align, Backlog refinement for Design system.

Warmup - At the beginning of each week designers got together for a warmup session. We discussed accomplishments from the last week and our plans for the current week ahead. We aligned this way to know if share a path with another designer. This space was also used for the Head of Design to share new knowledge about the product and business.

Design align - Occurred towards the end of the week each week to align on our progress, suggest new or improvements to our process, we did a show and tell of our work and thinking behind it and gave each other feedback. We were thus informed about the individual solutions coming out, we knew the products inside out. This was a space for our Head of Design to share new techniques or principles in design, maintaining our fitness as designers.

Backlog refinement of Design system backlog - I have initiated and lead this meeting. Once per sprint we designers met with the FE developers to align on the next UI components that we should implement. We decided based on the upcoming feature's requirements, having the foundational UI components done, design debt, tech debt as well as implementation logistics.

Design phase

Each designer has been associated to a solution. I have been working on the Supplier Portal together with another designer. As a new feature was formally kicked off within the delivery team and I have had completed some internal discoveries with domain experts, architects or customer service, I got an idea how to solution could work in practice.

I started works with a user-flow in FigJam, showcasing user actions followed by system reactions. This was very helpful way to realise the entire flow of the solution, integrations with different tools, data points, times of transactional email communications etc. I have already validated this flow with stakeholders. Such step-by-step flow diagram is already a base for designing the individual screen states. This was then adopted to be the standard start of the designing process.

Above are some feature flow diagrams and UI designs done by me, Order types feature, Header attachments and the updated order list screens where Suppliers could now get a better overview of the orders, filter and sort them.

At each update I called a developer for validation. I treasure these conversations. Developers provided guidance, better architectural decisions or how to potentially modify the complexity to meet both user needs and the dedicated time.

Half way through designing I had Design Review were I looped in the PO and domain experts for feedback and see what must be done to reach handover state. By the next session, Handover, the designs were prepared to their highest state, tidy document, UI designs organised into user stories, Azure ticket with acceptance criteria. We followed a Definition of Done checklist.

Design QA

No design is completed without quality assurance. Capturing the UI bugs as early as on component level is great in evading most glitches. In both component and feature design cases a designer verifies the developed solution on test environment. The component were checked using Storybook and Chromatic, feature designs were tested end-to-end of test environment.

I worked closely with the QA tester who while performing tasks before design QA has came across issues around behavior. We together tested them, and worked out what should be done next.

When there was more work to do, I have communicated this fact with the developer as well as kept a paper trail in the Azure DevOps tickets for transparent and traceable workflow. When everything was done well, I have let the developer know and commented on Azure that the works have passed design QA and are ready to be merged.

Feedback gathering after release

Work does not stop at implementation. In design team we called up the Chef or the Steward via video-call after the new features were released to production and asked for their opinion.

My contributions to the process

• Brought design into the discovery phase to shape problems early, not just solutions

• I initiated that the solution designs should begin with a user flow diagram

• Affinity diagram to be applied when analysing large amount of data - it got CEO, COO attention

• Introduced Definition of Done for solution designs and UI components

• I have made the design works visible and transparent across the organisation on AzureDevops

• I have created and lead the Backlog refinement meetings

• I have created and lead the Design system component backlog refinements

• I have taken over and governed our new Design system implementation

• I have taken over the work item management on AzureDevops for all teams

• Made priority score visible in AzureDevops

• Initiated transactional emails - identification, mapping, templates and as part of service design

• Designer collocation - all designers were now seated together to collaborate better

• Enabled design presence at a maritime tech expo to collect user and stakeholder insights

Testimonials

PO: 'I refer to the fact that you are always writing good stories, and acceptance criteria. Your work is always good.’

FE dev: 'Hi! Just wanted to let you know I'm psyched about working with you again in the team. It's not that bad in Team B, I just miss the awesomeness that came out of your hands'

CPO: positive feedback on user flows (in Order types as example)