The layout

The project was based on the target group "People who play board games". We would explore the needs of the target group, validate the need and develop a concept idea before the design sprint. We started with a hypothesis and initiated the process of getting to know the target group.

The team

The project group consisted of five UX students and three Java students from the Stockholm Institute of Technology. One of the goals of the project was that all UX students would gain insight into working with the different roles within SCRUM, and this was solved by rotating the roles every week.

During the project, we got along very well and over time we worked in a fast and solution-oriented way where everyone strived for the same intentions and goals.

Goals

• Develop a board game trade service
• Create an MVP
• To develop as UX designers in agile and cross-functional teams

Roadmap

Our roadmap describes the overall steps that followed our process and these defined the work ahead.

Get to know the user

Hypothesis 1

“Users need guidance to find a game they want to test”.

We conducted 6 interviews with people in the target group to investigate whether your hypothesis was correct or not.

Results

The target audience does not need guidance to find games that they want to test. They know where to find information about games. One problem we identified was that many have games they do not have time to play as well as games that "collects dust".

Hypothesis 2

“The user wants to exchange or sell some of the games they have at home.”

We conducted a questionnaire study where we received 33 answers and performed three qualitative interviews to investigate whether our second hypothesis was correct.

Results

The survey results showed that the target group has an interest in exchanging or selling games that they no longer play. We were also able to confirm that they were positive about using a service where they can exchange or sell games. During the interviews, the results from the survey were confirmed and we also received concrete examples of what the target group would value with a game exchange service.

Visualization of target group survey

Target group

People who have board games at home that they no longer play.

Persona

In the persona, we get to know "Ulrika" and her goals and frustrations. During our interviews, we gained many valuable insights into the need to get rid of games that the user no longer plays at home. Many also had a strong feeling that new games were expensive and that they were happy to exchange games with friends or family.

"Board games are the best activity on a friends night as it is social and fun for everyone"

- Ulrika “Ullis” Wallenphil

Idea generation

Based on the target group and their needs, we started an idea phase to investigate as many alternative solutions as possible. To involve the developers and give them an early understanding of the user, they were involved in the idea generation. With the exercise "The Problem Generation Process" we explored many alternatives to solutions. The challenge was to develop the solution that will work as an MVP and best meet the user's needs.

Concept idea

“A digital platform that allows users to exchange/swap used board games with eachother”.

Objectives and Key Results

Vision

• Board games should be played, not thrown away.
• Create gaming joy and a more sustainable future through a pass a long network for all board games.

Mission

• We will create an ecosystem where all playable board games are reused instead of being thrown away and thus give new life to games that "stand and collect dust".

Objectives

• “Speltornet” is a working exchange site that meets the user's main needs and frustrations.

Key results

• Users should be able to create a replacement ad on “Speltornet”.
• Users should be able to respond to an existing ad on “Speltornet”.
• Users should be able to find games on "Speltornet".

Note-n-map

To get an idea of ​​the service's structure and flow for the user, we created a note-n-map. We started from the needs and developed a possible flow for the service.

Crazy 8

When it was time to start exploring possible solutions to what the service would look like and work visually, conducted a Crazy 8 exercise to start the brainstorming. We realized that we had a relatively common view on the main functions page and we came up with some unexpected suggestions.

Story mapping

To concretize the service and begin the work of limiting the service to an MVP, we created a comprehensive story map to start from. We started by "dreaming big" and wrote down everything we wanted to include in the service.

Then we started to scale down the number of selected tickets in Jira to get a basis to design from the outside. Selected tickets are marked in green.

Customer journey

We developed a customer journey to give us and the developers a better understanding of the user's condition during the various parts of the process. The customer journey provided value for us prior to the design work in that we could see what critical elements there were for the user.

Sitemap

The last thing we did before we started sketching our prototype was to develop a sitemap to know what pages and views would be needed to make a complete prototype. During the work, we could return to our sitemap and see what would be done here next.

Lo-fi prorotypes

Prototype #1

We sketched simpler wireframes to be able to quickly start usage testing our idea. The sketches were made in Figma and we got a clickable prototype ready for testing.

Usability test #1

We performed four remote usability tests to evaluate the prototype. The tests were based on a scenario followed by a post-interview. After the first tests, we gained several valuable insights into the second iteration of the prototype.

Insights

• We need to be clear with delivery and security for the user.
• Recurring words: Smooth, simple, clear, intuitive.
• The rating system is important and increases confidence in the site and barter.

Prototype #2

After the tests, we iterated the prototype based on our new insights and proposed changes. We tried to meet the test persons' experience and create the flow as smoothly as possible.

Usability test #2

We performed three usability tests in the same way as before. One of the most valuable insights for us was that the flow was experienced clearly and smoothly. The test subjects appreciated the limited amount of information and understood all the steps.

Insights

“It was easy and clear! I have used several swaps and sell sites and they were not as clear as this one.”

- Anonymous tester

User stories

To compile the prototype, we wrote user stories for all steps of the flow. We could then choose what we wanted to start with when it was time to produce an MVP.

Visual profile and identity

Prior to the development of our visual identity, we formulated a creative brief as a basis. Our two most important points in the creative brief were "insight" and "tonality".

Tonality

Playful and reassuring: We need to meet the target group with a positive and trusting tone to encourage game swaps and get users to keep a good tone towards each other.

Logo

With the logo and the name, we wanted to highlight the playfulness of the service and connect it to the board game culture. The tower symbolizes the meeting place for a virtual exchange experience.

Colors

We use active and clear colors that give an optimistic and playful atmosphere to the service. The dark blue main color instills confidence and stability that we want to permeate the service.

Minimum Viable Product

It was time to include the developers and start the sprint weeks. To limit ourselves and prioritize the right functions, we developed an MVP with a focus on the most centered function: Find board games and contact the swapper. We created user stories for the MVP and together with the developers, we set up a plan for the first week.

Sprint layout

User stories

Before each week, the Product Owner produced user stories and subtasks in Jira for good structure. Together with the developers, we used poker planning to make storypoints for each user story. During the week we had daily standups to make sure that everyone always knew what their daily tasks were.

Hi-fi wireframes

During the week, we worked on producing Hi-fi wireframes on the current part of the prototype. We quickly noticed that we needed to be efficient in our design work to be able to spend relevant time on usage tests and iterations.

Usability tests and iteration

Before we handed over materials to Java to develop, we needed to validate our developed wireframes. We performed a number of usability tests for each part of the prototype, which consisted of a scenario followed by a post-interview. After the usability tests, we iterated our design, tested again, then we could compile everything for the design document and hand it over to the developers.

Reflections

It took a week before we realized the importance of being one step ahead of the developers each week. We needed to work faster with our wireframes to have time to test and iterate before handover. It was an educational process and by the end of the sprint weeks we had developed a sustainable system that worked for both teams.

Final product

The sprint weeks resulted in a coded prototype ready for advanced usability tests. We focused on three areas: finding board games, contacting swappers, and creating advertisements.

Insights pt.1

The process of going from the target group to idea, to design sprint and finally seven sprint weeks has been instructive. We have been challenged to make active and motivated decisions to move the work forward. We have had to work with structure and handover to make the collaboration flow smoothly to the developers. It has been an educational and stimulating project where we have developed as UX designers and in various project roles.

Feedback loop

During one of the steps in the prototype, we encountered a feedback loop. We had to iterate several turns before the flow was natural for the user. We had an idea that the game ads would look like playing cards to be perceived as more stimulating to click on. We tested several different designs on the cards and were constantly met by the same response from users: they thought it was fun, but a bit confusing. After several twists and turns, we chose to make the ads more "classic" and follow the anchors that other services use. Users now no longer had any difficulty understanding the content and they quickly moved on to the next step.

Insights pt.2

One step forward, two steps back

During the weeks we often heard from the developers that they had taken a step forward and two back. For several sprint weeks, the developers had to recode existing wireframes as several of the site's functions were initially "hard-coded" and not functional. Therefore, when installing the backend function, many wireframes needed to be redone from the ground up. We had to be very patient with each other and in our roles to continue to support each other even if it did not feel like the prototype was progressing so fast.

Jira

Since this was the first time we worked with Jira, it took a while before we all got a grip on how we wanted to use the program so that it suited us as well as possible. We tried several different ways to write our user stories and evaluated these every week. It was also instructive to see how much difference the actual work became depending on how the preparatory work was set up. In the weeks when we succeeded well with the line-up, the work flowed more naturally and there were less question marks about what should be done and by whom.

Learnings

What has helped us move forward?

We have had a good willingness to cooperate in the group. Everyone has been involved and it has been a permissive and humble atmosphere. During the project, we have used a one-day agenda, which in the long run developed our way of working faster. We have focused on listening to each other and giving and receiving feedback, which has been rewarding for us and the project. The dialogue with the developers has been good and we have had a basic respect for each other's work.

What we could have done differently

In retrospect, we have realized that we should have had closer communication with the Java developers. The importance of clear and agile communication in cross-functional teams became clearer with each passing week. We also noticed that the design system was given a central role in communication with the developers. Had we redid the project, we would have chosen to focus on a clear design system at an early stage to avoid misunderstandings and facilitate the design process.

What we have learned

Since the start of the project, we have worked in parallel with two courses, "Agile methodology and working methods" and "Visual Design", where we worked in cross-functional teams with student Java developers. We are now familiar with working methods such as SCRUM and Lean UX where we used software such as Figma, Miro and Jira.

Personal learnings: Agile methodology

I delved into:

• SCRUM & Lean UX
• Requirements management and handover
• Vision, Objectives & Key result
• Iteration and usability tests

I also learned to account for

• User stories
• User story mapping
• Retrospective
• Backlog

I became acquainted with the following roles

• Product owner
• SCRUM master
• UX team
• Tester

Personal learnings: Visual design

I delved into:

• Layout and morphology
• Typography and readability
• Responsive design
• Color theory
• Concept visualization
• Design system
• Animation
• Creative brief
• Communication & branding

I developed skills in:

• Moodboards
• Availability in contrast and readability
• Depict image formats
• Visual effects (states, transitions, and feedback)