Skyscraper

During NYTimes' Maker week, I proposed, led and launched a new interactive game called Skyscraper. Skyscraper is a reimagining of a sudoku-type puzzle turned into 3D.

ROLE

Product Designer / Project Manager

TIMEFRAME

Summer 2019
(3 Weeks)

TOOLS

Programming tools: React, Three.js

Design Tools: Figma, Cinema4D

TEAM

4 Engineers, 1 Designer (Me)

The Game & Context

— Overview

The objective of Skyscraper is to input buildings with a height between 1 and n (size of the grid) inside the grid and place it so that each row and column contains all digits only once (like sudoku). The numbers around the grid indicate how many buildings are visible from that spot. To win the game, the player must complete the New York City cityscape.

The Skyscraper puzzle was first introduced in the 1992 World Puzzle Championship made by Japanese puzzle makers. The game is complicated to grasp because the puzzle is drawn in 2D but solved in 3D. Our team wanted to reimagine the puzzle to become more accessible as well as more tangible and interact-able by adding 3D components.

Live on nytimes.com

Start Screen

Game Screen

Playing the Game

Win Screen

Mobile Web

Our Goals & Questions

— Overview

Goals  |  Our first priority was to create a web version of the working game with the one week we had to create for the Maker week presentation. 3D was also an unknown and confusing conversation that hadn't existed within the New York Times' portfolio of games and we wanted to make sure it fit the brand as close as possible.

Questions  |  What does a 3D game at the NYT look like? Does this add value to the portfolio of the NYT Games? Is it thoughtful and provocative?

Initial sketch of how I imagined the
2D board translating into 3D.

Process and Communication

— Managing & Leading

Once I had gathered team members, effective communication was necessary in order to build a game from scratch.

I had so many questions. How do you show interactions(swivels, movement) in three dimension with nothing to really show? How do you lead a team of developers efficiently so that people are using their time meaningfully?

In the beginning, I dedicated my time acting and drawing out how the app should move and interact. I explained my thoughts and the purpose of different kinds of components so that the developers could collaboratively give input. I had drawn out rough wireframe that gave an idea for making different components (3D, 2D, algorithm, modules, etc.). Once we had a good grasp of what needed to be done we made a spreadsheet ordered in terms of priority and importance.

Hi-fidelity prototype.
Working web-version. On the left is the 2D Board, on the right the 3D board.

Key functions

— Innovative

Toggling between boards | A 2D/3D board that you could toggle back and forth. The 2D board good for fast solving, while the 3D board was helpful for understanding the puzzle. The 3D board also has a minimap of the 2D board where you can input the values.

Error Handlers | If the same value was used in the same row or column, the color of the boxes would turn red, indicating that there was an error.

Swivel Interactions | When clicking the numbers on the outside of the grid, it would redirect you to that position of the grid from that perspective. This helps the player confirm that they can see the amount of buildings from that point.

Click on minimap numbers → change 3D view

Locked y-axis | The only movement allowed was across the x axis. We felt that limiting movement made things more 'Timesian' and that giving movement across x, y, and z axis would make the puzzle difficult to navigate.

New York Style buildings | During our initial brainstorming sessions, Andrew, one of the game designers gave the great idea of using other New York 'items' as buildings for the board. This gave a fresher idea to building a New York City cityscape.

Getting Feedback

— User Testing & Continued Research

A week had passed, and we had made a working web version hosted on heroku-app. We eventually got the attention of interested stakeholders who had the ability to push the game to beta. However, in order for us to push the game to beta testing we needed to update and fix a lot of UX interactions. We also had to resize the game to mobile as the games team deployed beta testing to mobile-web. We worked with the master game designer and QA to find any bugs or functionality issues. We also did a lot of inside play testing to get a clear understanding of the game. Since my teammates and I were already so familiar with the game, we were blind to a lot of UX issues that would possibly help new players.

Things we noticed through play testing:
1) Some users would go straight into the game without reading the rules (a common trend in games, most people want to jump into the game).
2) Users had difficulty with clicking outside the grid. Originally we wanted the perspective to be super easy to understand, so we changed the y-axis to make it seem like the player was viewing the buildings from eye-level.
3) Beginning players wanted to stay on the 3D screen. It helped them visualize better.

Markups to the original
Before swivel update
Improved swivel interaction
Before the swivel update the user flow is confusing and there's no progression when the player returns to previous state.

Player wants to understand the puzzle better

Player clicks on the number outside the grid

Perspective changes to eye-level (changing the y-axis)

Player clicks on the number that they had originally clicked on to return to the previous state

After the swivel update the user flow helps the player progress along the puzzle and helps them continue to solve.

Player wants to understand the puzzle better

Player clicks on the number outside the grid

Swivels to the number (stays at the same y-axis)

Player understands the perspective and swipes along the y-axis

On-boarding

— The Rules.

When we first built the on-boarding screens, our first thought was to have illustrations supplement the rules so that players could have an easier time digesting the complex instructions. I compiled a ruleset that I had found online which I then divided into four steps. A lot of previous research stated that users often play games without looking through the rules. In order to combat this we tested different things such as changing the position of the buttons so that the rules button would be more noticeable. We also tested things with wording and tried to maximize the efficiency with as little as possible. We wanted to keep our comprehension at a third grade level so that the text would be accessible to anyone.

Design Considerations

— Resizing the screen

Along with the improvements added we also needed to work on resizing and reformatting components. Components needed to maintain functionality but also have enough 'tappable' space. We also had to design a custom keyboard so that the user could input numbers into the grid. We made sure that the player had at least 44px x 44px of comfortable and clickable space, following the human interface guidelines. We also had to think about how to comfortably set the 2D/3D board so that players had enough space to interact with the grids. The biggest issue we had in terms of resizing was designing for the smaller sized screens compared to the more modern iOs screen sizes. However, when the screens got too small the tappable spaces were already at their limit therefore compromising the sizes of the boards.

Beta Testing & Conclusions

— So much learned

Eventually we had a build ready for beta testing. And it was published! The launch was set for the last day of our internship and we were all ecstatic at the fact that something of our own was being published at the New York Times! It was a lot of hard work and it couldn't have been done without such a great team. I learned so much not only as a designer, but also as a project manager. I also learned to be a designer who could communicate more efficiently with developers.

Project Management
As someone who initiated the project, I also took on the role of managing and supporting the developers on the team. I scheduled meetings, made tasks through JIRA, and talked to stakeholders and got hold of important dates. This particular experience was particularly notable for me, especially since I had never planned to get management experience. Handling the role as a leader and as a designer proved to be an incredibly valuable asset to us.

Intuition
Many times product designers go through a process trying to prove their design through performed reason and 'design thinking.' I would just say starting from scratch and being innovative in creating new interactions and motions are the most freeing and exciting ways to develop products. This experience helped me become more confident with my gut feelings. Start by intuition and experience and get feedback from there.

Live on nytimes.com

Start Screen

Game Screen

Playing the Game

Win Screen

Mobile Web

It was previously live on nytimes.com
You can now access it on our herokuapp server! It takes a bit of time for the server to ping the website, so refresh if it doesn't load.http://skyscraper-sudoku.herokuapp.com