How we work

We are committed to creating better solutions for our customers. To do this, we need to test hypotheses, explore different solutions, talk to users, and continuously learn from the people who use our services.

To support this, Spor is organized around a few practices:

• Four-month goals
  The year is divided into four-month periods, each with a shared goal and projects that contribute towards achieving it.
• An open Slack channel
  Spor has an open Slack channel where anyone can ask questions, share ideas, and stay up to date on what is happening.
• Feedback
  Every four months, a voluntary feedback form is shared in the Slack channel to gather insights and learn how Spor is working for its users.
• Monthly Spor syncs
  A monthly sync provides a space to share progress, discuss upcoming priorities, explore improvement suggestions, and bring up topics relevant to Spor.
• Open contribution
  Spor’s code and Figma files are open for contribution. Anyone can create a pull request or branch to suggest new features, improvements, or changes to existing components.

Our brand was developed by Snøhetta. This is at the core of everything we create and do, and the fundamental thoughts behind the experience we want our customers to have when using our services. We work to carry this brand forward in everything we do, and have also made some adjustments to ensure that it also shines on digital platforms.

Our primary design tool is Figma, a cloud-based design and prototyping platform for digital projects. Figma allows collaborative work on projects from virtually anywhere. We utilize this tool for tasks ranging from sketches, flow mapping, prototyping, and user testing to collaboration, feedback exchange, and designing components and final pages for subsequent development.

• Slack – We use Slack as communication and coorperation tools.
• Trello – We use Trello for handling our tasks and backlog
• Testflow – We use Testflow⁠Ekstern lenke to get quick feedback from our users, by testing other solutions and prototypes
• Universal design – We use a few different tools for making sure the products we make are accessible. There are some very good Figma plugins which goes a long way, such as Contrast⁠Ekstern lenke which also supports the APCA algorithm for checking contrast. There are also online tools like Funkify⁠Ekstern lenke and Webaim⁠Ekstern lenke. Additionally, We rely on the Norwegian state body for universal design, uutilsynet.no, which has the best documentation on current regulations in Norway.
• Vy test-app – We use a custom test app, and different test environments on the web to test and validate new services and features.
• Figma mobile app – Makes it possible to test design and sketches directly on our phones
• Metabase – Used to collect data and information about our users, so that we can measure and learn.

Team Kanaler in Vy Digital holds overall responsibility for Spor, but Spor is a shared system owned by everyone who benefits from it. Anyone can contribute, whether by introducing new features and components or improving existing ones.

All changes to Spor must be reviewed and approved by an administrator, regardless of whether they are made in Figma or code. Changes should be carefully tested to ensure Spor continues to provide robust, user-friendly, and accessible building blocks.

Spor provides general building blocks that can be reused independently of specific flows, designs, components, or services. Examples include buttons, layout grids, modals, text styles, and input fields. Spor should not include components specific to individual teams, such as tickets, search results, receipts, or pricing details. We also do not manage individual teams’ component libraries.

Accessibility is essential to making Spor usable by as many people as possible. By building accessible components and patterns into the system from the start, we help teams create inclusive experiences without having to solve the same challenges repeatedly.

Consistency makes products easier to understand, use, and navigate. A shared design language helps create a coherent experience across Vy’s products while allowing teams to focus on solving their specific user needs.

To get the most out of Spor, we recommend exploring the documentation and guidelines. Here you will find useful information and tips on how Spor is structured and how to make the most of its design tokens and components.

If you want to get in touch, you can send a message to someone on the team via Slack, post in the #spor Slack channel⁠Ekstern lenke, or create an issue on the nsbno/spor⁠Ekstern lenke GitHub repository.

If you need new components or variants that don’t currently exist, you can contribute to the design system so that others can utilize them later. The more we adopt, discuss, adjust, and align these components, the greater the impact of having a robust design system. Please see the description of the flow for new components below:

Flow in “Team X”

A team is working on a new flow to enhance our customer experience. The design is based on the design system, but certain elements will be used across multiple teams.

Component

To understand the scope and overall impact, it’s essential to test how this component functions on different surfaces and in various contexts.

Collaboration with other teams

Collaboration with designers from other teams or with Spor members may be necessary to adapt the component’s design for different surfaces.

Development in team “X”

The team that initiated the work completes the necessary components and variants. Development efforts can be shared among the involved teams as needed.

Local deploying

The solution is deployed locally, allowing the design to be finalized and the project to proceed without significant delays.

Suggestions to Spor

While the solution is being used locally, a pull request is made from the responsible team and sent to the design system. Members of the Spor team reviews and approves the component and variants, allowing them to be published in the design system. Adjustments may occur during this process, which will then be pushed back to the team. A final review takes place before the component is officially approved and implemented in the design system.