How to describe a team role without inflating personal claims
Use precise role language that a prospect can verify from public evidence.
On this page
A team website often needs to introduce one person’s work without claiming they did the whole job. The strongest description states the role, the part of the work that person owned, and the public evidence a reader can check. It does not borrow the team’s full result as a personal credential.
A prospective client needs to understand what they can ask you to do. A precise role description makes that decision easier and gives colleagues a fair account of the work.
Name the role a reader would recognise
Start with the real title or a plain description of the function. “Lead researcher,” “product designer,” “engagement partner,” and “editor” can be useful when they are accurate. Broad labels such as “visionary” or “growth expert” usually make the reader work harder to understand the job.
If the formal title is internal or unclear, pair it with a short explanation. For example:
| Less clear | More useful |
|---|---|
| “Innovation lead” | “Ran user research for the service-design team.” |
| “Growth strategist” | “Advised the team on paid-search measurement and landing-page tests.” |
| “Project owner” | “Coordinated the client workshops and maintained the delivery plan.” |
The second column does not make the person more impressive. It tells a reader what they did. Use verbs that match the work: wrote, researched, designed, ran, analysed, coordinated, built, reviewed, or advised. Do not use “led” if the role was a contribution within someone else’s leadership.
Describe responsibility, not the whole outcome
Team work can have a collective result. A project may ship a new service, win an award, reduce costs, or improve a metric. Before attaching that result to a bio, separate the result from the individual’s documented responsibility.
An accurate sentence might read: “As a product designer on the team, Samira Patel designed the onboarding flow and tested prototypes with new users.” If the team reports that the new service improved activation, the bio can name the team context only when the claim is public, permitted, and clear about attribution: “Samira was part of the team that redesigned onboarding.”
Avoid wording that changes a collective result into an individual claim:
| Claim | Problem | Factual alternative |
|---|---|---|
| “Improved activation.” | It assigns a team result to one person without context. | “Worked on the onboarding redesign. The team’s public case study reports [the published result].” |
| “Built the platform.” | It may erase other people’s work. | “Built the reporting interface for the platform team.” |
| “Won an industry award.” | It is unclear who received the award. | “Contributed research to the project recognised by [award], if the public record identifies the project.” |
| “Transformed client operations.” | It is broad and hard to verify. | “Ran three workflow-mapping sessions for the operations team.” |
The alternative must still be true. If a case study is private, do not use its result in a public bio. If the award record does not identify your contribution, leave it out or ask the team how it should be described.
Link to work that proves the narrow claim
One public path is more useful than a crowded list of logos. Link to an author page, an event programme, a public project page, an approved case study, or a report where the contribution is named. Make sure the link supports the sentence beside it.
The following is fictional. Jordan Lee’s profile could say: “Jordan wrote the accessibility research brief for a public-service redesign.” A link to the public report byline supports that statement. A link to the agency homepage does not necessarily prove the role, authorship, or current availability.
Keep these limits in the review:
- A team page may show employment, not personal ownership of every project on the page.
- A client logo may show a relationship, not the work performed by one named person.
- A byline establishes authorship of that piece, not every service the person offers now.
- A public case study may describe a result, but only use the person’s part when it is identified or approved.
Google encourages accurate authorship information where readers expect it. That does not validate a claim or promise ranking or an AI-answer outcome. Google’s guidance
Check approvals before publication
Role descriptions sit at the boundary between personal marketing, employer policy, client confidentiality, and colleagues’ credit. Review the final wording with the people who can confirm it, especially for client names, performance figures, sensitive work, and shared achievements.
Use this short approval record:
| Item | Check |
|---|---|
| Role and dates | Match the employment or project record. |
| Responsibilities | Match the person’s documented contribution. |
| Team result | Public, permitted, and clearly attributed to the team. |
| Client or project name | Approved for publication. |
| Link | Opens to the promised public evidence. |
| Current status | Does not imply the person still holds a former role. |
When evidence is thin, describe the role you can support rather than reaching for a larger outcome. “Ran research sessions” may be enough to show the kind of work a reader can hire you for. Add a current service description on your own profile if you want to explain what you offer now.
Add the approved wording, page URL, reviewer, and review date to the expert source inventory. Use that record before the next bio or case-study update.