Design and launch a collaboration tool
✦ Problem ⋯ How do we encourage and facilitate information sharing across Swedish Medical Group healthcare providers, staff and leadership?
✦ Role ⋯ Researcher, Designer, Content creator, Project manager
✦ Deliverables ⋯ Guiding designs, Information architecture, Use cases, Personas, Project status and overviews, Training materials, Seed content
✦ Tools ⋯ Jive Software, InDesign, Excel
Project timeline and my place in it
I worked with SMG leadership, eHealth strategists, and Jive Software consultants to design and implement the DocSpot platform. When I arrived the project had been funded and the goals defined.
- Build connections and relationships among Swedish providers
- Communicate and manage communications around a strategic direction
- Share ideas, motivate learning and use of best practices
- Help onboard new physicians and integrate new clinics into the system
My job was to translate these goals and loose requirements into the implementation and design of DocSpot, a SaaS web tool. I reported to a Sr. Program Manager and worked closely with a training specialist and Jive Software strategists and account owners.
Tools and skills used
I wore many hats. I designed the information architecture, content, and was the de facto project manager from the Swedish side. The tools I used most were Jive Software, Excel and InDesign.
I was responsible for creating content, training users on how to create pages and content, and collected user feedback that helped define the navigation, page components, the UX overall.
An additional part of my job was to champion DocSpot across the medical group. I often presented status and training to SMG leadership, healthcare providers, and clinic administrators.
A bit on how we got there
DocSpot aimed to give users a more convenient way than email to share their expertise, collaborate, and make healthcare decisions accurately and efficiently. It tried to solve the problem that providers don’t often sit at a computer and are seeing patients. They realistically had the time and ability for quick mobile-device exchanges during most of their working hours.
To gain broader buy-in, our initial launch was a pilot with leadership committees who used DocSpot for their meeting agendas, shared resources and more generally got committee work done. The pilot included 550+ users and 2000+ pieces of content.
In the pilot phase of the project, I interviewed 20+ SMG staff: providers, clinic managers and members of the leadership team. From these in-context interviews, I was able to synthesize 3 key personas: the experienced doctor serving on leadership committees, the clinic manager and a provider new to Swedish. These key target groups helped guide use cases and project priorities.
From what we heard from providers, we knew we’d have to design a platform with a great deal of redundancy and multiple paths to reaching content. Users would need to understand what content types they could create and find from the get-go. We couldn’t expect our users to go through how-to tutorials, so searching, tagging and templates would have to be robust enough to ease discovery and task completion.
The initial result of the pilot was a complex, diffuse site structure. Categories were difficult to define in this open and changing system. I was constantly revisiting and looking for ways to consolidate the 300+ groups and their group page components, layouts and permissions. It was a significant and rewarding weekly exercise.
DocSpot was released to all SMG employees 3 months after the pilot. Taking the learnings of the pilot, I created group page templates for key use cases. They could be easily applied toward a project or team by anyone at SMG. All DocSpot users could now create and configure one of these groups. The group templates had uniform structures, layouts, and permissions—and made it easier to discover content and take action. Without them, DocSpot couldn't grow with our small team managing and able to scale DocSpot across the Swedish system.
Takeaways and what I learned
No tool alone can change people’s behaviors and communication patterns. Just as it was important to understand how our users approached DocSpot as a tool, it was also critical to understand the social and behavioral aspects of medical care.
To effectively design and implement DocSpot, I had to nudge providers accustomed to working independently to coordinate and make decisions as a team.
I learned that I loved the strategy, research, use-case definition, and designing DocSpot. I was less enthusiastic about selling the platform across SMG. I’m grateful for this opportunity and to have had the autonomy and trust to experiment and move quickly. It helped me stay resilient and motivated.
The biggest takeaway was learning to slow down and define concrete use cases before jumping into solutions. I couldn’t rely on first-come, first-serve adoption. I needed to solve real user needs alongside organizational goals. Our use cases had to align with the user goals and the problems they wanted to solve for DocSpot to launch.