The 7-Day Sprint: Turning Ideas into Reality with the Grad Team

Summary:

What happens when you condense the software development lifecycle (SDLC) into just 7 days? Following a fast-paced introduction to digital consultancy, Rachel and Kieran discuss the reality of building their first apps while navigating a landscape full of unknowns. From the unexpected twists of user research to using AI as a mentor, they share how they played to their strengths and drew inspiration from one another to broaden their design perspectives.

About us:

Kieran:

Shortly after completing my Bachelor’s in Marketing, I applied for the graduate program, as a graduate digital consultant. During my studies, I worked as a freelance designer for SME’s. Now, as part of the user-centered design team, I’m excited to apply my skills in UI/UX by building accessible digital services that make a real difference.

Rachel:

After studying Computer Science and completing an MSc in Human-Computer Interaction, I joined Solirius as a graduate digital consultant this November. I’m thoroughly enjoying working within the user-centred design (UCD) team and looking forward to applying thoughtful, human-centred approaches to building digital services.

7 Days, 1 App: The Graduate Challenge

Our time at the Graduate Academy was a high-energy dive into the digital consultancy landscape. In just a few weeks we covered a breadth of disciplines, ranging from business consulting and user-centred design to DevOps and agile delivery, before diving into our final challenge: a seven-day sprint to build a working application from scratch.

This project was our chance to put that fresh knowledge to the test. In this post, we share the reality of that week from the unexpected twists of user research to the technical problem-solving. We also reflect on the experience of working alongside such a talented group of graduates. Seeing how others played to their unique strengths didn't just inspire us, it encouraged us to focus on where we could add the most value too.

The Reality of Building from Nothing

We were all tasked with the same challenge of building a working 'Journal App' minimum viable product (MVP) using Ruby on Rails. While the preceding weeks provided the theory, this sprint was purely about application. We had just seven days to take everything we had learned and turn it into a functioning product.

The short timeframe was challenging, however, our daily stand-ups provided an enjoyable opportunity to step back and see how everyone else was tackling the challenge. With 15 graduates from different backgrounds working on the exact same brief, we saw 15 completely unique interpretations emerge. Hearing these updates didn't just keep us aligned, but gave us a fascinating insight into everyone’s strengths and the specific areas they decided to focus on, inspiring us to push our own designs further.

What we did

Kieran:

Coming from a design background with zero coding experience, I knew that learning to code in seven days to solve a real problem would be a challenge.

Confronted with a list of “I don’t know’s”, I thought it best to turn to my mentors and peers for advice. Their answer was clear: go all in on your strengths. Speaking to them made me realise that if I was already good at something, I should exploit that to its maximum potential, and use tools and collaboration to bridge the rest of the gap.

So my ‘eureka’ moment was – what’s something I can do that others can’t? And so, I realised my unique value was defining the problem and transforming it into a concrete visual solution.

The problem I set out to solve stemmed from my own frustration with wanting to combine all my playlists from different streaming platforms into a singular ‘master’ playlist for easy listening and sharing. To find out if others felt the same way, I distributed a survey to understand people’s listening habits. I was able to conclude that people shared the same pain points as me, but most insightfully, it revealed which features they didn’t actually want. 

For example, I found that users didn’t want the creative features like custom webpages for playlists, and would only consider it if it was an effortless process. Insights like these underpinned my entire design process. As a result of this example, I added ready made templates for users who prioritised listening more but still wanted to express themselves. 

I turned insights into wireframes and user journeys, eventually creating high-fidelity prototypes to truly visualise the service and feel. This is where my strengths really shone. To cover what I lacked in coding, I used Gemini as an AI tutor to guide the technical implementation, while conferring with my peers to double-check my logic.

A presentation board displaying six high-fidelity UI screens for a music app called "Notify". The design features a modern, editorial aesthetic using a beige and soft black colour palette with bold serif typography.

For me, this experience became a real reminder that you don’t need to be perfect and be completely skilled in everything! Imposter syndrome exists and the way to go forward is to find what you’re already good at and build upon that with tools and complementary skills; this is how you’ll thrive!

Rachel:

My immediate priority was getting the technical foundations in place. This presented my first major blocker of the project. Working remotely for the initial environment setup meant I didn't have the immediate, over-the-shoulder help my peers in the office had.

However, thanks to the DevOps practice mentors who were incredibly helpful and responsive online, it didn't slow me down. Like Kieran, I supplemented their help by using AI as a technical tutor. By asking it to explain why a configuration failed, I could understand the solution rather than just copy-pasting it. This combination of human expertise and AI tools helped me bridge the gap and get my environment running smoothly.

If there was one "golden rule" we took away from the week, it was this: You are not your user. It is easy to build features you think are cool, but without research, you are just guessing.

I saw this firsthand when I began building my application idea called 'CrewExchange', a trading platform for rowing kit. I mapped out my initial ideas based on my own personal preferences, but to validate them, I circulated a survey among the rowing community before writing any code. The results were surprising. They revealed that what I valued was completely different from what my potential users actually wanted.

Diagram showing the steps taken to map assumptions, from documenting early assumptions to forming survey questions to avoid confirmation bias.

The data showed users actually valued the sentimental history of their items more than the label on the kit. This insight drove a pivot in my design. I scrapped the transactional model I had planned and redesigned the core functionality to prioritize community connection instead.

Diagram showing my ‘Connection’ hypothesis, which suggests that kit trading will be encouraged by highlighting the emotional value rowers attach to their kit.

This experience was a real reminder that relying on personal bias can lead you down the wrong path. Going forward, I know that validating assumptions isn't just a 'nice to have'. It can be the most critical step in the development lifecycle to ensure you are solving the right problem.

Crucial Tools During a Crucial Time

Kieran:

Gemini was really pivotal in teaching me to implement features and code. With no prior coding experience, I had Gemini break the code down into easy to digest explanations for the role of each 'Gem' (the pre-written code packages used in Ruby) and how to write the syntax for it. It was important for me to not just copy and paste but to understand why I needed it and how to use it. I found AI to be a massive asset, helping me grasp complex concepts in formats that made it easier to process!

My learning objective for this project was to learn Figma Design to wireframe and prototype. Previously, I had used Adobe Photoshop for wireframing but after transitioning to Figma, I’m never looking back! 

It’s simple and intuitive, with vast resources online from Figma and independent creators to help guide you through simple tutorials. Personally, I found that transitioning from low fidelity to detailed high fidelity wireframes in Figma was seamless and I could easily add interactions to make professional prototypes and show what my app could do.

Figma Jam was another Figma tool that helped me map out my user research. Essentially, it’s a whiteboard tool with everything you need to brain dump and organise your ideas into meaningful insights. It’s a hundred times better than paper and you can connect ideas easily in the context of the bigger picture.

A structured board titled "USER RESEARCH SYNTHESIS." It organises research data into five columns: "Research Overview," "Methodology" (featuring pie charts and bar graphs), "Key Findings" (highlighting insights like "Users want a unified platform"), "User Needs" (categorising pain points like multi-platform annoyance), and "Assumptions & Validation".

Rachel:

Whiteboarding with Figma was the backbone of my project, allowing me to evolve a single sticky note into a comprehensive architecture without losing sight of the big picture. Crucially, my board grew horizontally, with each stage of the design process directly informing the next. This visual flow kept me honest; it ensured every feature I eventually built was rooted in the research that came before it, rather than just being added at random.

Overview of the digital research Figjam whiteboard, showing the full product design process from early assumptions and affinity mapping to key statistics and personas.

To keep the project grounded, I used Personas. It’s easy to get lost in what you want to build, but having a persona meant I had a constant reminder of who the app was actually for. I combined this with user journey mapping to help me spot what moments mattered most to the user, showing me exactly what to prioritise. This was critical when time was my most valuable resource.

User journey map for the persona ‘Sentimental Sarah’, showing her actions, mindset and emotions across four phases, and highlighting opportunities to improve the experience.

When it came to the actual build, Gemini was a game-changer. Coming from a Computer Science background, I was already familiar with the logic behind the code, but I wasn't fluent in the specific language (Ruby). Learning a new syntax from scratch in five days would have been a massive bottleneck. Instead, I used Gemini as a "syntax translator", taking the concepts I understood and helping me implement them in Ruby. This allowed me to speed up the learning curve and focus on building value rather than fighting with syntax errors.

Marketplace view from the ‘CrewExchange’ prototype showing rowing kit listings with trade or sell options and brief item details.

What we learned

One of the most valuable parts of the week was the final presentations, where everyone showcased exactly how they tackled the brief. We feel the most impactful part of the Graduate Academy wasn’t just the technical skills we acquired, but the collaborative community that was fostered. Watching the final presentations was a standout moment for both of us; fifteen graduates working from the same briefs, resulting in fifteen completely unique interpretations, all showcasing strengths within different parts of the Software Development Lifecycle (SDLC).

Kieran:

I was inspired by Rachel’s project with how she incorporates a ‘gamified’ experience when trading kits. Her project featured a ‘tinder-style’ swiping function when a user wants to find kits to trade. Rather than a discovery page, presenting one option at a time reduces cognitive load and engages the user. Her design showcased solid design principles, sticking to what her users valued, and the execution in her presentation was flawless.

Rachel’s take on her project was an inspiring and refreshing perspective into how you can both make an experience satisfying while meaningful to its users, something I’d love to improve upon in my own projects.

Swap Zone screen from the CrewExchange prototype showing a gamified interface with two items side by side and options to pass or offer a trade.

Rachel:

I was particularly inspired by Kieran’s project. He learned Figma from scratch during the week, playing to his creative strengths to create an interface that felt incredibly intuitive and market-ready. It was a brilliant reminder for me not to be afraid of picking up a new tool, because the rewards really pay off.

I’d love to develop my own design skills in the future, and it’s great to know I have a friendly face in Kieran to lend a hand.

A Look Back At Our Experience

The relationships we’ve built between our colleagues have been influential in our understanding of being a consultant. Everyone has vastly different skillsets and still achieved their project outcomes – it means that you don’t need to know everything to be successful. Instead play to your strengths, learn from those around you, and you can solve much larger problems than you could alone.

Kieran:

I’m much more confident than I was before in understanding the SDLC and knowing I have a solid community supporting me, I’m ready to tackle the challenges my client might be facing, and to provide value through my strengths.

Rachel:

I am incredibly excited to bring these skills into a real client project. This week proved that I can pick up new tools and deliver under pressure. I'm ready to take that momentum forward and start solving real-world problems for our clients.