Lay's: Grab a pack. Development Strategy


UX/UI Designer



A description of the strategy our team followed to design, architect and successfully ship the cross-platform promotional game. The key to success was maintaining a constant communication with the client and adopting a development strategy specifically tailored to the needs of the project. This allowed us to build a reliable architecture, consistent UI and successfully ship the project, meeting the required deadlines.


Team & Stakeholders

2x Product Owners, Creative Director, Project Manager, Software Developer, Back-End Developer, Marketing Manager, 2x Visual Designers, 3D Modeller & Animator

tight deadlines and changing requirements

Once we went into the development stage, the two biggest challenges our team faced were tight deadlines and changing requirements. Even with an enormous effort from the whole team, often it was almost impossible to follow the development plan and it felt like parts of the game were invented on the fly. In those kind of circumstances we soon realized that to finish the project on time we needed a new development approach.

New development Approach

Design Approve Process

If we were to follow a common path for development, we would start by prototyping different parts of the game, like gameplay or UI, to test ideas and see if they work, afterwards maybe combining the two together at later stages of testing. We would then throw that prototype out and build everything from scratch. Here we could not afford to take that path. We needed to instantly develop a final version, if we wanted to make it on time.

An approach to stay rough for as long as possible allowed us to not implement the final visuals until they were 100% approved on the mockup level. To achieve this I was working with the stakeholders separately, giving the team time to focus and work on the core functionality, rather than spending time implementing features that could have been thrown out in the next several days.

Simplified Architecture

Due to the changing requirements there were only a handful of screen that we knew would make their way into the game for sure and dozens of smaller screens and popups that were constantly coming and going. So, rather than including all of them into the architecture and then constantly going through adjusting and re-approving it every time something changes, the team suggested an approach, where only the core architecture would be approved with the client. This core architecture would include only key screens everyone were sure would make it to the final version while all other screens, like details, options, specifications or legal, would just use the same layout and placement templates without the need for approvals.

Fast & Flat Communication

Apart from adjusting the approach, we also adjusted communication. We needed a quick back-and-forth with the stakeholders to ask questions, ask for approvals and discuss or flag problems. This was crucial since any communicational delay often resulted in the development pauses or spending time on features that would later be cancelled or redesigned. 

New approach postponed the implementation of designs, introduced lighter approval process for minor screens and gave direct communication channel with all the major stakeholders

Luckily for us, the whole team adopted a more opened and flat culture of communication, with the ability to address any stakeholder without extra people in between. In addition to emails, we adopted IMs to solve urgent matters, created online discussion groups for different project aspects and tried to have most of the key stakeholders to join and participate. That kind of communication allowed us to make decisions fast, voice concerns as they emerged and deal with the changing requirements more efficiently. It also fostered trustworthy relations between development team and the client, giving the development team "more room to breathe" and the client additional reassurance in the constant development progress.

These principles by no means guaranteed us a great product, but without implementing them, we most probably, would have faced a much harsher work environment, probably failed the deadlines and delivered only half of the experience that we have actually produced.

Architecture & Screen Map

Based on some high level scenarios created before, together with product managers, lead engineer and back-end developer we designed the core architecture of the game, which, at the same time, served as a screen map and as you can see from the picture, also gave a rough understanding of the main functionality that we planned to have on each screen.

Not the actual diagram used during development

We also agreed on the process of adding, deleting and changing the content so the app would remain consistent and stable. I worked on the forefront of receiving and handling the changing requirements, taking them in, clarifying the uncertainties and fitting them into the project. The process would be something like this:

Before making a feature a part of the architecture we made sure it would bring the project closer to its goals

After receiving a request, the first thing I would do is talk to the stakeholder who initiated it to understand why are we adding this in the first place. This was a sanity assessment, to make sure the request made sense within the overall structure of the project and that was a good reason to fit it in. If yes, I would then collaborate with the lead developer to figure out, if there are any constraints and limitations to implement it. Sometimes we would even start a rough mockup together, which I would later refine and send for approval. There would always be some back-and-forth with the client about minor details, but once the approve is granted, I would go back to the engineer and we would determine what was required to implement the design, breaking it down into smaller tasks and distributing them if needed.

Also, following our "stay rough for as long as possible" principle, even though a design was approved, we would sometimes hold to implement it, giving way to features that were higher in priority. Our tactics was to lay the ground work for the new design, but wait to implement it, since it still could have been canceled.



I started with creating a set of wireframes and mockups for all the major screens. Those designs served as guidelines for the overall look and feel of UI and HUD. Based on their looks we determined the theme and style for the whole experience and agreed on the designs for the secondary screens. And as requests were coming in, I was spending almost no time for approvals since everything was pre-agreed before.

The initial concept of the main menu screen also served as a guideline for the overall look and feel of UI and HUD

Also, we've used an approach of zooming into already existing objects on the main screen for most of the major screen's backgrounds. This simplified the process of designing the UI, since I was able to polish and approve the main screen and that would almost automatically approve the theme and visual style for all the other screens.




Thanks to the specially tailored development strategy, good communication and an immense effort from the development team and stakeholders, we were able to meet the deadlines, making Lays: Grab A Pack a great success.

The game was available on Web, iOS and Android platforms with thousands of people competing for prizes every day

The game was available on Web, iOS and Android platforms with thousands of people competing for prizes every day. It received great feedback from the players and fulfilled its project goal, drawing a lot of attention to the brand and serving as a fun medium for distributing prizes.