Manager Support - Service Design
Manager Support
A service design study of how a university actually supports its managers, and a prioritised set of measures for the gaps it found.
Design Studio 2, Halmstad University, team of five, five weeks.
Team
5 designers
Tools
Miro, ClickUp
Role
Project Leader & Service Designer
Timeline
5 Weeks
Client
Halmstad University, central operations support and the academies
Methods
Desktop research, stakeholder mapping, SWOT, shadowing, 12 semi-structured interviews, thematic coding, personas, current- and future-state journey mapping, process mapping, storyboards, reverse thinking, effort/impact prioritisation
01 - Context
The Support Exists. Nobody Knows Where It Ends.
Halmstad University supports its managers through a central operations function and the academies’ own support structures. Case handling, meeting coordination, KPI analysis, recruitment, leadership development and so on. the offer is broad, and it reaches everyone from the top leadership down to academy and department heads.
The client did not come to us with a product to design. They came with a question: what support do our managers actually get today, and where does it fail them?
That is a harder brief than a screen. There was no artefact to critique and no obvious user flow. The first job was to turn an open question into something a five-week team could answer with evidence.
02 - Problem
An Open Brief Is a Design Problem of Its Own
As project leader I made two framing decisions in the first week, and both shaped everything after.
We mapped the present instead of proposing a system.
The temptation with a brief this wide is to jump to a new platform. A concept built on assumptions would have been unfalsifiable and useless to the client. We scoped the project to a rigorous current-state mapping, with solutions grounded in it.
We narrowed the target group from “leadership and managers” to managers.
Nothing in the early research indicated unmet need at the top leadership level. Following it anyway would have thinned the evidence across both groups. I wrote the narrowing into the assignment description and flagged it to the client as an explicit limitation rather than letting it happen silently.
03 - Research and Insights
Watch First, Ask Second
I planned the research in a deliberate order: observe before interviewing, so the questions came from real working days rather than from our assumptions.
Shadowing - 3 managers
We followed three managers through their day to see how they actually work, what they are responsible for, and where they reach for help. Observation showed us the shape of the support relationship; it could not tell us how it felt.
Interviews - 12, roughly 90 minutes each
I built the interview guide in four blocks- role, tasks, support, needs. Each with follow-up prompts so an interviewee who stalled could be helped forward without being led. We pilot-tested it before running it live.
Desktop research, in parallel
Client material, the intranet, and how comparable universities structure support for their managers so that our recommendations had a reference point outside the building.
Thematic coding
We transcribed and coded every interview, and sorted the codes into recurring themes: communication, systems, access to information, how the support is experienced.
Key insight
Coded across twelve interviews, almost every pain point resolved into one of three underlying needs: communication, reliability, availability. Not three problem areas but three needs that kept reappearing whether the manager was describing a system, a recruitment or a meeting. From that point it worked as the filter for every idea: a solution that did not serve one of the three did not survive the shortlist.
The second insight was structural. The problems managers described were rarely with the support function itself. They sat in the touchpoints around it: the systems, the intranet, the channels. So we widened the SWOT to cover those touchpoints, not just the service.
What works is worth stating too: collegiality is strong. there is always someone to ask, and HR and legal support were described as genuinely reliable, giving managers confidence in decisions. The weaknesses were unstructured, inconsistent communication paths and frameworks that exist on paper but were never taught.
04 - Current State
Two Versions of the Same Process
To make the research legible to the client, we visualised it.
Process mapping, recruitment
We mapped the recruitment process twice: once as managers described it in interviews, and once as it is documented on the intranet. Reading them side by side is the finding: the documented process has more steps, more handovers and more systems than the one managers carry in their heads. The gap between the two is where work gets dropped.
The largest pain point sits before the process even starts: the need for a new hire is discovered too late, when the work environment is already strained. In the words of one interview, the time it takes to recruit is longer than the time until you need the person. Recruitment starts under pressure, every time.
A second gap was migration and residence-permit questions. Nearly half of the staff have a foreign background, and no one owns that area so the manager absorbs it, without support and without authority.
Recruitment process — as described by managers
Recruitment process — as documented on the intranet
Journey mapping
We built a current-state journey for a composite persona, a 45-year-old department head, across a normal working day: fragmented information, inconsistent communication, time-consuming manual steps. A second journey followed a department head entering a new assignment into the university’s planning system. The emotional curve runs neutral, frustrated, exhausted, and the cause is visible at each step: manual handling, double entry between systems that do not talk to each other, and private documentation kept to compensate.
Current-state journey — a working day
Current-state journey — entering a new assignment
Personas
Three personas covering systems, communication and recruitment, then one composite persona combining the patterns they shared. It became the reference point for the rest of the project — concepts were argued against a person, not against a preference.
one composite persona
05 - Concept Development
Four Principles, Then Ideas
Before generating anything I set the criteria a solution had to meet, so that selection was not a matter of taste:
Availability - information and support exist where and when the user needs them.
Coherence - solutions integrate into existing workflows and systems rather than adding another.
Autonomy - a manager can get through a step without needing someone else at every stage.
Time-saving - the solution removes double work and unnecessary communication.
Ideation ran directly off the process maps and journeys, so every idea started at a step where something was already known to break. Where the obvious answers ran out we used reverse thinking, asking how we would make the support measurably worse and inverted what came back.
Every idea then went through an effort/impact matrix. Comparing what each solution demanded against what it would return made the shortlist quick, and it killed the proposals that read well on paper but would not survive contact with the organisation. A consolidated documentation bank came out top: modest effort, and it touches several of the most-cited problems at once.
Effort/impact matrix
06 - Solution
Three Tracks, One Ecosystem
Communication
A shared documentation bank so that meeting material stops living in individual inboxes including voice recording and automatic transcription of meeting notes, stored where everyone with access can read them. A communication framework that defines where tips, requests and files belong, so a message cannot quietly disappear in a feed. One common channel for managers, replacing the current split between mail and Teams. And a proactive information flow: managers told in advance about planned changes, rather than after those changes have already collided with their week.
Systems
Single sign-on, to cut the repeated logins and make it visible who has approved what. A connection between the systems that currently require the same information twice. And tiered system guides a first level for someone who has never opened the tool, a last level for someone who wants to work faster in it.
People and recruitment
Personality-based pre-screening to make the first selection, so that fewer interviews can be deeper ones. And proactive hiring: communicating staffing needs early enough that recruitment does not begin in crisis.
Future-state journeys and storyboards
We rebuilt the same two journeys with the concept in place. The same task, guided; several steps automated; the emotional curve rising through control, efficiency and satisfaction instead of falling. For the client that is the argument not a list of features, but a visible before and after of the same working day.
Future-state journey — a working day
Future-state journey — entering a new assignment
07 - Recommendations
What Should Happen Next
Shadowing as a standing practice
The support function should spend time in managers’ working days. It is the cheapest way to see where help is actually needed, and it turns the relationship into an open dialogue rather than a ticket queue.
A system-by-system audit
The systems are spread out and the gaps between them are where the double work lives. Diagnosing that properly needs more than five weeks but connecting them lowers the learning burden for every new manager, and stops loading the current ones’ attention for no reason.
Proactive support
Information from the support departments passed on earlier, and the support function asking managers where help fell short this week instead of waiting to be asked.
A support guide for employees
Many of the systems are advanced and hard to learn. A layered guide would raise both efficiency and confidence, at the level the reader actually needs.
08 - Impact
A Grounded Baseline the Client Can Build On
The client received a current state they can act on: two recruitment process maps, current- and future-state journeys for two roles, three personas plus a composite, a themed coding of twelve interviews, a SWOT covering the surrounding touchpoints, and a prioritised set of measures with the reasoning behind the priority visible.
The value is not the individual concepts. It is that a diffuse complaint "the support could be better" was turned into named problems attached to named steps in named processes, with evidence behind each one. That is what makes it possible for the university to decide what to fix first.
09 - Reflection
What I’d Do Differently as Project Leader
We went into detail too early
By the first critique session the team was already designing solutions on a problem we had not finished defining, and we had to pull back and re-frame. That correction cost us valuable time. Running it again, I would hold the team in the problem space with a hard date, and make the transition to concepts an explicit decision rather than a drift.
The narrowing is the decision I’d defend
Dropping top leadership from the scope reads like a gap in the deliverable, and I would make the same call again, five weeks buys one group studied properly or two studied badly. What I would change is the framing: I should have handed the client a short plan for how the leadership half could be studied later, so the limitation arrived with a next step attached instead of as an absence.
Coordination is a design tool
Setting up the WBS, the group contract and the shared board looked like admin at the start of the week. It was the thing that let five people run parallel interviews and still arrive at one coherent coding. I underrated it going in.