Digital Game and Web Developers
Plan, develop, transform and maintain digital games and websites.
Launch day for a game and a website
You are a developer at a small studio, and today your team is launching a new game and a matching website for a client. It is 9am and launch is at 5pm. Everyone is excited, the client is nervous, and the team lead has just asked for a word with you. You have a long list and not much time.
Choose what you would do. Then see what happens. There are often good reasons for each choice.
I've had a brilliant idea. If we add a new power-up before launch, players will love it. It would be a small change. I know it's late, but the client will be thrilled. Can you do it?
Say yes and squeeze it in this afternoon, because the idea is exciting and the client would love it
The power-up works on your machine and fails on a different phone. The game launches with a fault and a rushed fix. A last-minute feature is a new chance for new bugs.
Say no outright, since launch is today and there's no time for anything new or untested
You protect the launch, but Darcy is hurt and his idea vanishes. A better answer would have kept the idea alive for an update.
Say you love it and propose adding it to the first update next week
Darcy agrees, and the power-up becomes the headline for week one. The launch stays safe. Good developers protect the plan without killing the idea.
I just tried the site on my mum's tablet and the text is really small. She says she can't read it. I don't know if this is a big thing, but she's quite upset. Can you look at it?
Tell him it works on the studio's screens and that it is probably his tablet
You may be right about the tablet, but he walks away feeling dismissed. His mum is exactly the kind of user the site is meant to serve.
Test it on a similar tablet, find a fix for the text size and explain what you changed
You find the text is fixed at a small size and make it adjustable. Marcus is pleased, and the site is easier for everyone to read. Listening to one user often helps many.
Promise to add a larger text option after launch and move on
Marcus accepts it, but the site launches with the problem, and a few early visitors complain. A quick fix before launch would have been worth the half hour.
I think I broke something. A page I changed an hour ago is now loading really slowly, and I'm not sure why. I'm scared to say anything, because we launch in a few hours.
Tell him to quietly fix it before anyone notices, so as not to cause panic before launch
Wei tries alone for two hours and nearly misses the launch. The problem was simple and you could have solved it together in ten minutes.
Thank him for telling you, sit down with him and work out which change caused it
You find the cause and fix it together, but you did not tell the team lead, who then hears about it from someone else and wonders what else is unsaid.
Thank him, look at it together, and tell the team lead with a plan
The cause is a single heavy image. It is fixed in fifteen minutes, and the team lead says thanks for the heads-up. Honesty about a small problem makes the large ones easier to share.
How it went
The game and the site go live on time, with a bigger text option and a power-up planned for next week. Developers solve problems with code, but they spend as much time listening, explaining and deciding what not to build today. Does that mix of making and talking suit you?
This is a simplified, fictional situation to help you explore. It is not professional instruction or a test of your ability.
Case study: The donate button that did nothing
A fictional case set in a small studio that builds websites and games for clients, with a handful of developers and a designer.
The situation
Kiri was a web developer building a new website for a local animal shelter. The week before an important fundraising weekend, the shelter's coordinator noticed that donations had dropped even though more people were visiting the site. Kiri had tested the donation button on her laptop, and it worked perfectly. The coordinator was sure it was a problem with the shelter's advertising.
What they did
Kiri asked a few people to try the site on their own phones, and saw one of them tap the button repeatedly without anything happening. On an older phone, a small piece of her code did not run. She checked what kind of phone most visitors used, rather than guessing, and fixed the code so the button worked everywhere. She told the coordinator what had happened, in simple words, and added a step to her list to test on older devices.
How it turned out
Donations picked up again within the week, and the fundraising weekend went well. The coordinator was relieved and a little embarrassed about blaming the advertising. Kiri used the story to persuade the studio to buy a few old phones for testing.
What would you do?
- Why might a website work for the person who built it and fail for everyone else?
- How would you test something on devices you do not own?
- What would you say to a client who is sure the problem is somewhere else?