Skip to content

Shared Presence for Other Disciplines

Platform Guidance and Content Considerations Across Fields

Who This Document Is For

This document is written for groups whose projects sit outside — or only partly within — the CS, IT, and Engineering space.

It is also useful for mixed-discipline groups, and for any group that has decided a GitHub Pages website is not the right medium for their shared presence.

The underlying purpose of a shared presence does not change across disciplines. What changes is the platform, the content emphasis, and the vocabulary of what a strong presence looks like in each field.

If you have not read What Is a Shared Presence yet, do that first. The principles there apply here equally and are not repeated.

The Common Thread

Before addressing specific disciplines, it is worth restating what any shared presence — regardless of platform or field — must do to be worthwhile.

It must show progression, not just outcomes. It must explain, not just list. It must connect to the individuals behind it. And it must be updated while the project is happening, not only at the end.

These are not technical requirements. They are habits of professional communication that every discipline already has a vocabulary for — design portfolios, research summaries, practitioner reports, campaign case studies. The goal of this document is to help each discipline group recognise what that vocabulary is and apply it to their shared presence with intention.

Look at what practitioners in your field actually publish

This document gives you a starting point. It does not give you the ceiling. Every discipline has practitioners who communicate their work publicly and well. Before your group finalises what your shared presence will contain, spend time looking at examples from professionals in your field — how senior UX designers present case studies, how research groups publish project summaries, how education practitioners communicate programme outcomes, how marketing professionals write campaign case studies. The conventions you find there are the professional standard your shared presence should aspire to.

UI/UX and Design Projects

The nature of this work

UI/UX and design projects are defined by their process as much as their outputs. A final screen or prototype tells only part of the story. The decisions that shaped it — the research that informed it, the iterations that refined it, the problems it was designed to solve — are where the professional value lies.

A shared presence for a design project must make that process visible. A gallery of final screens without context is a portfolio entry, not a showcase.

Behance is the established professional platform for design and UX work. It supports rich visual presentation, project case studies with narrative, process documentation, and professional networking. For UI/UX students, publishing on Behance signals awareness of where the design community lives. It is where designers look for talent, and where students should be building presence.

Figma Community allows teams to publish their Figma files publicly with accompanying description. This is appropriate for groups whose primary deliverable is a prototype or design system — it lets readers interact with the work directly rather than viewing screenshots of it.

A dedicated portfolio site — built on Webflow, Cargo, Adobe Portfolio, or similar — gives full control over presentation and is appropriate for groups with a strong visual identity for their project.

For groups that want something simpler: a well-structured Notion page with embedded Figma links and a clear case study structure works effectively and is easy to maintain.

What your shared presence should include

Problem framing — What design problem were you solving, and for whom? Be specific about the user group, the context, and the gap you identified. Avoid reproducing the brief — describe the human need behind it.

Research insights — What did you learn from user research that shaped the design? Surveys, interviews, observation, and competitive analysis all produce findings. Surface the ones that mattered — the ones that changed your direction or confirmed an approach.

User personas — If you developed personas, include summarised versions. Present them with the research that supports them. These are distillations of patterns found in real research, not fictional characters.

The design problem statement — A clear articulation of what the design needed to solve, written after research and before ideation. This demonstrates that the design was a response to evidence, not an aesthetic preference.

Iteration evidence — Show early and late versions. Wireframes alongside final screens. First-pass information architecture alongside the refined version. What changed, and why? This is the most important evidence of professional design practice — the willingness to revise based on what you learned.

Prototype or interactive link — A working Figma prototype, an InVision flow, or a deployed front-end. Let readers experience the design, not just see it.

Decisions and trade-offs — What design directions were considered and rejected? What constraints shaped the final approach — technical, business, accessibility, or time? Explaining these demonstrates the thinking behind the work, not just the work itself.

Testing and feedback — What did you learn from usability testing or user feedback? How did the design respond to it? Evidence that the design was tested and iterated is a significant professional signal.

Individual contribution cards — Each team member's role and a link to their individual Guide B showcase.

Reference list — Design heuristics, accessibility standards, research papers, and competitor analysis sources that informed the project.

Data Science, AI, and Research-Led Projects

The nature of this work

Data science and research-led projects are defined by their methodology as much as their findings. What question was asked, how data was gathered and treated, what analytical approach was taken, and what the findings actually support — these are the questions a professional audience will ask.

A shared presence for this type of project must communicate intellectual rigour without requiring the reader to wade through a full technical report.

GitHub Pages works well for technically capable groups in this space — it integrates naturally with code repositories and supports embedded notebooks or data visualisations.

Notion is effective for research-led projects that involve mixed technical and non-technical contributors. It supports structured documentation, embedded links, and collaborative updates.

A research group-style landing page — simple, clean, text-forward — is appropriate for groups presenting academic or applied research. Look at how university research groups present their work online and use that as a model.

For groups working heavily in data visualisation: Tableau Public or Observable allow interactive visualisations to be published and embedded, which can form the centrepiece of a data project's shared presence.

What your shared presence should include

Research question or problem statement — What were you trying to find out or build, and why does it matter? Write this for a reader outside your field. Avoid jargon in the opening. The question should be immediately understandable.

Dataset and data context — What data did you work with, where did it come from, and what are its limitations? Be transparent about the boundaries of your data. Do not share sensitive, personal, or confidential data publicly — describe the dataset without reproducing it.

Methodology summary — What analytical or modelling approach did you take, and why? What alternatives did you consider? For machine learning projects, this includes model selection and the reasoning behind it. For research projects, this includes research design decisions.

Key findings or model outcomes — What did the analysis produce? Summarise the most significant findings clearly. Use visualisations where they aid understanding. Be precise about what the findings support — avoid overstating conclusions.

Limitations and honest scope — What does your project not claim? What would a larger dataset, more time, or a different approach have changed? Acknowledging limitations is a sign of intellectual honesty, not weakness. It is also what distinguishes academic rigour from marketing copy.

Links to notebooks, reports, or repositories — Jupyter notebooks, R Markdown files, published reports, or code repositories. Link outward rather than reproducing technical content on the site.

Visual evidence — Charts, model performance summaries, data flow diagrams, or visualisations that illustrate the key findings and make a technically dense project accessible to a broader audience.

Individual contribution cards — Each team member's role and a link to their individual Guide B showcase.

Reference list — Datasets, papers, frameworks, and methods referenced, using the citation format appropriate to your discipline.

Education and Applied Social Projects

The nature of this work

Education, social intervention, and applied research projects are defined by their context and their impact on real people. The project exists because a problem in a community, classroom, organisation, or system was worth addressing.

A shared presence for this type of project must communicate that context clearly, present evidence of engagement and impact honestly, and reflect the ethical responsibilities that come with working with people and communities.

Google Sites is accessible, free, and familiar. It requires no technical skill to maintain and supports text, images, embedded documents, and video. It is a practical choice for groups focused on substance over presentation.

Notion works well for structured, document-rich projects — particularly research-led education projects where the shared presence is closer to a project report than a visual portfolio.

WordPress (free tier) offers more design control and a more professional appearance than Google Sites, at the cost of slightly more setup. For groups with someone willing to spend an hour configuring it, it is worth considering.

A well-maintained PDF one-pager updated periodically is also a valid option for some project types — particularly where the primary audience (a school, an NGO, a community partner) is not digitally native. The principles of liveness still apply: version and date each update clearly.

What your shared presence should include

Programme or intervention description — What did your project do, in plain language? Who was it for, and what need or gap did it address? Write for an audience that includes the community involved, not just academics.

Context and setting — Where did the project take place? What was the institutional, community, or organisational context? Be specific without being intrusive — describe the setting without identifying individuals who have not consented to being identified.

Methodology or approach — What did you actually do, and in what sequence? What informed your design choices — literature, observation, consultation? How did you involve the community or participants in the design?

Ethical considerations — How did you approach consent, confidentiality, and the responsibilities that come with working with people? This is not a bureaucratic checkbox — it is evidence of professional and ethical practice. Include it.

Evidence of engagement and impact — What happened? What did participants or stakeholders experience? Where possible, use data to support claims — pre and post assessments, attendance, participation rates, qualitative feedback. Be honest about what the evidence does and does not show.

What changed during implementation — Projects working with people rarely go exactly as planned. What did you adjust, and why? How did the community or participants respond in ways you did not expect? This is where the most authentic learning usually lives.

Individual contribution cards — Each team member's role and a link to their individual Guide B showcase.

Reference list — Literature, policy documents, programme frameworks, and sources that informed the project design.

Confidentiality with vulnerable populations

If your project involved minors, vulnerable populations, or participants who consented only to participating in the project rather than to public documentation, take particular care about what is published. Photographs, names, and identifying details should not appear without explicit, informed consent from participants and — where relevant — their guardians or institutions. When in doubt, describe rather than identify.

Business, Marketing, and Strategy Projects

The nature of this work

Business, marketing, and strategy projects are defined by their real-world applicability. Whether the project was a market analysis, a campaign proposal, a business plan, or a strategic intervention, the shared presence should communicate that the work was grounded, evidence-based, and professionally credible — not just theoretically sound.

WordPress (free tier) or Wix offer professional visual presentation with minimal technical setup. These platforms are appropriate for groups who want a site that looks credible to a business audience.

Notion works well for strategy-heavy projects where the primary deliverable is a document or framework rather than a visual artefact.

LinkedIn — while not a traditional platform for group project websites — is worth considering for business students already building professional presence there. A shared LinkedIn post or article documenting the project is visible to exactly the professional audience most relevant to this discipline.

What your shared presence should include

Client or market context — Who was the project for, and what was their situation? Describe the business context clearly. If the client is real, acknowledge them with permission. If the client is hypothetical, say so and describe the scenario.

The problem or opportunity — What business problem, market gap, or strategic challenge did the project address? Be specific. Avoid generic framing — "improving customer experience" is not a problem statement. What specifically was broken, missing, or underperforming, and for whom?

Strategy or proposal overview — A summary of the strategy, campaign, plan, or intervention — not the full document, but enough for a reader to understand the logic and the key choices made.

Evidence and research basis — What data, research, or analysis informed your strategy? Market research, competitor analysis, consumer insights, financial modelling — surface what grounded your recommendations.

Key decisions and trade-offs — What strategic directions did you consider and reject? What constraints shaped the final approach — budget, timeline, regulatory environment, competitive dynamics? Explaining trade-offs demonstrates that your strategy was considered, not just confident.

Outcomes or projections — What did the project produce? If outcomes are measurable, present them. If the project was a proposal, present the projected outcomes with the assumptions behind them stated clearly.

Individual contribution cards — Each team member's role and a link to their individual Guide B showcase.

Reference list — Market data sources, research papers, industry reports, and analytical frameworks referenced. Business credibility comes partly from being able to show where your evidence came from.

Choosing a Platform — What Matters Most

Across all disciplines, the most important factor in platform choice is not capability — it is sustainability.

The platform you choose should be one your group will actually update across the project timeline. A simple platform updated regularly is always more valuable than a sophisticated platform neglected after week three.

Ask your group:

◆ Who will be responsible for maintaining the shared presence?
◇ How will updates be triggered — after supervision meetings, sprint reviews, milestones?
◆ Does everyone in the group know how to add content to the chosen platform?
◇ Is the platform accessible to our intended audience — client, supervisor, employer?

If the honest answer to any of these is uncertain, simplify the platform choice. A shared presence that works is always better than one that was planned to be impressive.

In Summary

A shared presence for a non-technical group is not a lesser version of a project website. It is the same act of professional communication, expressed through the platforms and vocabulary of a different discipline.

What makes it meaningful is the same across all fields:

◆ it starts early and shows progression
◇ it explains the thinking behind the work, not just the outcomes
◆ it connects individual contributors to the collective project
◇ it is written for an audience outside the institution
◆ it reflects the professional conventions of the discipline it belongs to

The platform is a container. The thinking inside it is what matters.

Guide B individual showcases and a shared presence work together. Each team member's individual showcase provides the personal narrative; the shared presence provides the collective context that makes individual contributions intelligible to an external reader.

If you have not yet worked through Guide B, that is where individual showcases are developed.