Sitemap

10 Differences Between Your Academic Case Study and a Real-World Project

7 min readJul 7, 2024

--

Have you ever felt that your university design projects prepared you for everything — except the real world?

In 2019, while working on my final MA project, I realised that while academic projects offer valuable learning experiences, they often miss the practical steps and dynamics of real-world settings.

In this post, I’ll explore how a university project would unfold in a small company and share tips for transitioning from student to industry designer.

Photo by Kaleidico on Unsplash

1. The Process: Academic vs. Real-World Chaos

At Loughborough University, I learned to use the Double Diamond framework, which accommodates some degree of messiness.

However, in a real company, this messiness is magnified, with time and budget constraints making the process less predictable.

Here’s a comparison:

  • Academic: Discover > Define > Develop > Deliver
  • Industry: Collect stakeholder requests > Prioritise > Prototype > Feedback > Test with users (if you’re lucky) > Hand-off > Iterations and new features. Not necessarily in this order.

In companies, processes are often managed through tickets and organised into sprints. While trying to linearise the chaos can help, it’s important to stay flexible with sudden changes in requirements and deadlines.

Tip:

Embrace tools like Jira early to get comfortable with managing and tracking tasks in a sprint-based environment.

2. Choosing the Project Topic: From Decision Paralysis to Stakeholder Requests

Selecting a project topic was one of the most challenging aspects of my academic journey, and I experienced decision paralysis.

The good news is that, in a company, this is less of an issue since stakeholders usually have specific ideas about new features or products. They’ll present you with a set of unorganised requests, and your task is to begin addressing them promptly.

Photo by Brett Jordan on Unsplash

3. Prioritisation: Quick Wins vs. User Happiness

When deadlines are tight and requests are extensive, prioritisation becomes essential. In university, the focus is primarily on enhancing user satisfaction, which guides your prioritisation.

In a business setting, however, prioritisation involves additional variables. The first Minimum Viable Product (MVP) should focus on “quick wins” — features that offer significant value to the business (closely linked to user satisfaction) and can be developed faster.

Tip:

Set a meeting that includes someone who understands the business, knows the users, and is familiar with development constraints. This will help in making informed prioritisation decisions.

Photo by Kelly Sikkema on Unsplash

4. Wireframes: Non-Tech Stakeholders

Non-tech people are often unfamiliar with wireframes and might not fully understand them. They may approve these initial designs but then disagree on fundamental aspects when they see the actual UI — issues that could have been addressed at a low-fidelity level.

I began to view wireframes as something primarily for designers and stopped presenting them altogether. While wireframes work well in a university setting where feedback comes from tutors and peers, outside that environment, people often struggle to imagine what those grey rectangles will look like in a final product.

My Approach:

I usually use sketches or very low-fidelity FigJam wireframes to visualise flows and the general layout of pages with the UX team, and then present only the polished UI to stakeholders. I previously tried using low-fidelity UI designs with Lorem Ipsum and a coloured high-fidelity wireframe, but it was too distracting.

Tip:

Minimise distractions. If stakeholders see incorrect data or a strange UI, they may comment on superficial details like “shouldn’t that button have rounded corners?” rather than providing feedback on the core aspects we’re seeking input on.

Photo by Tirza van Dijk on Unsplash

5. Designing for Scalability and Iterations

Since I start working with high-fidelity UI early on, I’ve developed the habit of using Figma components and styles early in the process. While a university project is typically just a means to graduate, a real project will go live and evolve over time. A design system is crucial for scalability.

Scenario:

Creating a design system in Figma early in the process helps ensure that when you receive feedback late on — such as comments about font sizes — you won’t be overwhelmed. It’s all about establishing a solid foundation.

Tip:

Begin building your component library early and iterate as needed to accommodate feedback and changes.

6. Technical Limitations

Once you reach an acceptable version of your design, you’ll start sharing it with the development team so they can begin working on the infrastructure.

At this stage, you’ll be constrained by the features and flows of this version and won’t be able to make significant changes to functional aspects. However, UI changes and styling are still allowed.

Double Tip:

  1. Learn some development basics to suggest realistic solutions and avoid disappointment. Over time, you’ll develop a sense for what might get strong disapproval from your development team.
  2. Check your design with developers early in the process. This will help you identify technical limitations and prevent you from working on features that may never be implemented.
Photo by UX Indonesia on Unsplash

7. Advocating for Research and Usability Testing

Depending on the design maturity of the company, you may need to use strong communication skills to persuade management to allocate time for research, even if it means no immediate visual outputs or design progress.

“I know the users.” — Typical Stakeholder

While stakeholders may believe they are user advocates, they often lack the training to filter biases. You might be surprised by how different users’ priorities can be from those of stakeholders.

How to Convince Them:

Demonstrate how understanding user needs aligns with business goals and reduces long-term costs. User research acts as a filter for what users will actually use, saving both development time and money. Many companies only turn to user research when users start complaining or metrics decline.

Tip:

Actively recruit participants by connecting with colleagues who are most in touch with users, such as those in sales, and ask them for contact recommendations.

8. Time-Efficient Analysis

To manage stakeholder anxiety, avoid spending a week transcribing and analysing findings. Take notes during interviews and use tools like Otter to double-check details you might have missed. ChatGPT can help identify patterns and summarise insights.

Tip: Since companies often limit research time due to its lack of immediate visible progress, stay updated on the latest technologies and AI tools. These can speed up the research phase and help present findings clearly.

Photo by Campaign Creators on Unsplash

9. Persuading Stakeholders

Your design recommendations might conflict with management’s priorities, so you’ll need a compelling presentation to convince them that focusing on user needs is better for the business. Tailor your recommendations to speak the stakeholder’s language.

Example:

For business-focused stakeholders, go beyond “this will make our users happy” and explain how it will increase revenue and align with their core values.

Tip:

If you’re unsure about their goals and needs, describe the person and their job role to ChatGPT to generate a quick persona.

Photo by Pankaj Patel on Unsplash

10. Handoff to Development

Most uni projects never see the light of day. That’s why many designers, especially in their early experiences, often struggle to communicate their designs to developers. We all know the frustration of creating a cute UI and being horrified by its implementation. Most often, the fault lies on both sides.

Tip:

Ensure developers know how to read your designs on Figma and where to find all necessary documents. Most importantly, design with developers in mind by standardising your work. This means using consistent components, clear annotations, and providing detailed specifications to make the implementation process smoother and reduce misunderstandings.

Conclusion

The transition from academic projects to real-world design involves navigating new processes, constraints, and expectations. By understanding these differences and preparing accordingly, you can make this leap more effectively and set yourself up for success in your design career.

What challenges have you faced in transitioning from academic projects to industry work? Share your experiences and questions in the comments below!

Suggested reads:

--

--

Claudia Sabbadin
Claudia Sabbadin

Written by Claudia Sabbadin

Product Designer | Venice-born, Amsterdam-based | Updates when inspired | claudiasabb.com

No responses yet