Launching a rocket ship in six weeks
As a UX intern
The summer of 2017, I attended a UX internship at a small tech company in Uppsala, Sweden. The ambition was simply to learn new stuff and have lots of fun. This is the story of the process creating “Custodians of Space” — a mobile slingshot gravity game developed in Unity — with a focus on learnings and takeaways!
The game — Custodians of Space
These days, humans are not only stuffing the planet with trash, but we’re also starting to litter in space. From old rocket parts to cameras are orbiting the Earth, posing a threat to future space adventures. Now, you have the opportunity to help scientists and future space travellers by cleaning up some of the debris floating around.
The mission is to save space from floating debris. To do that you are given control of the launch of a debris collecting rocket ship. By using the gravity and orbits of different planets your mission is to calculate the perfect route to be able to collect as much debris as possible. The more missions you complete the trickier it gets to collect the debris. Join the Custodes on the mission to save the Universe but watch out for asteroids, meteors and black holes on your journey!
Make sure to check out the game at App Store and Google Play!
The process
I will now take you through the process of this project, focusing on the takeaways. I’ll share tips and tricks on everything from meeting the team, coming up with the idea, making a plan, execute it, test the product and launching it on both App Store and Google Play to finally wrapping up the project and prepare it for “hand over”. Enjoy!
Greetings
New city, new company. I didn’t know anyone. I’d never been in Uppsala more than for a night or two — always passing through or just too busy to actually see the city. It’s amazing, at least during the summer! Monday morning and I was excited to meet new people and starting a project I had no idea about.
Throwing yourself out there, meeting new people can sometimes be intimidating and exhausting. With that stated, try to dive into the project with an open mind. Everyone else is in the exact same situation as you are and things almost never turn out as we plan them to, but that doesn’t guarantee they won’t turn out amazing. Whether you’re familiar with the people involved in the project or not, it’s always a great idea to gather over a casual coffee before diving into the project for real.
I don’t think I need to remind you that people are very different. But they are. Don’t expect anyone to know how you work and more important, don’t assume other people work in a certain way or the same way as you do. Explain how you work and ask others how they want to be treated. This can be tricky, but if you don’t know how you want to be treated yourself, don’t expect anyone else to do you right. Good communication is everything within a project group.
Brainstorming
Focusing on the project. In many cases, there is some type of project specification. In those cases, give the specification a read-through together, make sure everyone is on the same page with the project. What are everyone’s expectations?
In this specific case, we didn’t have any guidelines for where the project was heading. What do you do then? Instead of just carelessly throwing out ideas, ask yourselves this:
- What do we enjoy doing?
- What do we want to explore?
- What tools (skills) do we have, and what do we need to learn?
- What are the expectations?
A good way of structuring this is to give each team member some time to write down an answer for each of the questions. When everyone feels pleased, take turns to share what you’ve written and then document it in a way so everyone can see. When everything literally is out on the table it’s much easier to start working on the project specification.
Background research
When you’ve come up with some kind of idea what the project should be all about, ask yourselves this: “Has this been done before?”, “How can we twist it to make something unique?” and “How can we learn from what’s already out there?”
If you don’t have a designated person with research skills, just sit down together and google. There’s no need to reinvent the wheel, but at the same time, you might want some kind of challenge. When you’ve looked into possible competitors and related work it’s time to prioritise and estimate how to spend the time.
Make a plan & don’t stick with it
Think scalable and write down the basics. Literally, as little as possible for the project to still make any sense. Then make different steps of scaling. What is your vision with the project? What’s the dream?
Decide on a method of how to execute the project. We went with a classic physical scrum board made from a whiteboard some coloured pens and post-its. If you’re working in a new environment as we did, it can be hard to estimate how much time that needs to be spent on different tasks, especially in the beginning of the project. Don’t worry. Just try to be specific about the tasks and set the least amount of time to 1/2 working day. Don’t put too much value in the time estimation of each task – there’s no punishment for spending more time on a task, and no reward for finishing early. It’s simply a method to estimate the total time of a sprint. Gather all the tasks for the first sprint, add up the time and divide it with the number of team members. There you have the time of the sprint!
Getting through the “honeymoon phase”
Every new group of people will go through something called the honeymoon phase. This is the period of time when you put up with your best behaviour and carefully try not to step on anyone’s toes while trying to figure out how everyone work. Even if it’s very comfortable to be in this phase, especially when everything is new, the goal is to make this state last for as short a time as possible. Why? Well, when we’re trying to please others and get along we tend to avoid confrontation, be less honest and outspoken. All of this can lead to decreased productivity. But hold up, the phase of politeness is only the calm before the storm. On the way to effectivity, innovation and productivity there’s often a roadblock.
Disagreements and conflicts are unfortunately what often takes the team out of the honeymoon phase and onwards. This is probably the most common place for teams to get “stuck” and ultimately not achieve their full potential. How do you get past it then? The hard way. Open communication is the key, rather than shoving the problems under a rug. The only way you get out of this unpleasant situation is to find a way to resolve the conflicts constructively.
Along the way, we had some disagreements and something that helped us cope with these where our semiweekly “retros”. Having scheduled retrospectives is a great way of providing an opportunity for the team to vent and discuss problems. When dealing with disagreements etc. it can also help to have an agile coach around — guiding you through the retro, making sure everyone gets a say and that the problems are solved properly.
Celebrate both success & failure
We were sure to celebrate every tiny bit of success, which also made us spend time together and it really enhanced the team spirit. Keep it simple. Celebrating with a fika*, a ping pong break, or even just a high five after a sprint’s finished or the team have accomplished something is enough.
Most teams experience both success and failure. When doing so, make sure to succeed and fail as a team. Don’t forget that celebrating failure also tend to make it more OK to fail. The journey will most likely be crooked and your team (in the same way as mine) will face all kinds of unexpected obstacles. But remember, when you fail you’re always one step closer to getting it right.
* A Swedish term for getting together over a coffee/tea and/or something sweet.
Sharing knowledge
6 weeks is an extremely limited time to build a whole application in a new environment and with no prior knowledge of the area. With that said, it’s still important to make time for learning and sharing knowledge. Don’t hesitate to share your skills, +1 heads are better than 1.
Everybody knows something that the others don’t, in relevance to the project. Prepare and hold workshops or talks about your area of expertise with a focus on improving the product. Sometimes taking a break and focusing on something else is a great way of keeping everyone motivated.
Sharing what you’re working on in the project is also good. Have some kind of sense of what the others are working on makes it way easier if someone needs to leave abruptly. Start with something as simple as standups every morning, and share what you did yesterday and what you’re planning on doing today. This is also a perfect time to reach out to the team and ask for help if you’re stuck with a problem.
Why are you scared of feedback? It doesn’t bite!
Know your value – feedback really doesn’t bite. So many people have said it before, but I’ll tell you once more. Differentiate yourself from your work! People commenting and giving feedback on your work is a positive thing. They’re helping you to improve by either challenging you to view the problem from another angle or giving you a chance to motive your choice — take these chances.
Something is always better than perfect (nothing)
A big part of the challenge of the project was to launch it on App Store and Google Play. While we knew that App Store has a detailed process and is kind of complex, we took this in consideration early on and started focusing on just getting something up and running on TestFlight (App Store’s test mode). After 10 days we had something up and running. It wasn’t pretty, but it was a start.
The idea of perfection is often just that an idea. If no one sees “the perfection”, what’s the point? In the long run, you will benefit from focusing on getting the functionality up and running before spending to much time on the polish. One of our winning concepts for the project was to always strive to get something out there! It doesn’t have to be perfect — nothing’s ever perfect.
The value of testing
Being a UX designer, I’m of course biased in this field. But in my opinion there really is no other way to know what an audience wants than to ask, test and observe.
We decided to hold a workshop. Starting by throwing the game in the users’ faces, only having explained that it was a game with a space theme. We encouraged the test group to think out loud (speak their mind, always telling us what they’re doing and thinking of) and then we observed. This is really valuable because it’s the scenario closest to the reality. You’ll also discover that people tend to say one thing but then act in the complete opposite way. We all want to be good and sound smart.
After this kind of “first expression” session, we had prepared some tasks. While the users were figuring out how to complete the tasks, we once again sat back and observed. These user tests we then iterated over the time of the project. Find the problem, define the problem, come up with a solution, evaluate/test the solution — repeat.
Documentation ≠ a separate document of boredom
Finally, something we could’ve been better at during the project was to document the process of the project. We started off pretty good (as most do) and then when the project got more intensive, we fell behind and eventually stopped.
Documentation is important, even if it from time to time can seem pointless it is valuable. A common mistake is to limit the definition of documentation to external text files that describe how the product/service works.
Documentation doesn’t necessarily belong in a separate text document. Making sure that your code is readable and well commented and that your design files are structured will carry you for a good amount of time. It will also definitely simplify the process of letting go of/handing over the project to someone else.
What I learned from the project
So, what did I take away from this awesome experience? Here is a summary of my main takeaways:
- Try to dive into the project with an open mind.
- Explain how you work best and ask others how they want to be treated.
- Straighten out everyone’s expectations on the project.
- Don’t reinvent the wheel, do your background research.
- Make a scalable plan, but don’t be afraid to adjust it as you go.
- Celebrate both success and failure!
- Get out of that honeymoon as fast as you can and communicate openly.
- Don’t hesitate to share your skills, +1 heads are better than 1.
- Feedback doesn’t bite. Know your value!
- Shipping something is better than nothing, it doesn’t need to be perfect.
- You’re never the user (even if you’re going to use the product every day).
- Keep your code clean and your design sheets structured.
If you have any thoughts or question, please, don’t hesitate to reach out (remember to be kind though).
Thank you for reading! ❤️
