Iterating with Data
My role: Research, User Flows, Information Architecture, Sketching, Wireframing, UI, Prototyping
Read time: ~6 minutes
Highlights
Replaced an almost manual issue-resolving method (đ) with an in-app experience to enable co-working space members to raise any issues about the space or their membership on the app.
Results
- Easier to initiate a complaint.
- Response time went down.
- Issues were resolved faster.
As an early team member at CoWrks, a vibrant co-working space, we were all about building the groundwork for a supportive, collaborative environment (while figuring things out ourselves!).
Our top priority?
Making sure clients felt right at home and could make the most of their workspace. This case study dives into how we levelled up our approach to client support, evolving from face-to-face chats to a streamlined app-based solution that made handling issues and requests easier and more efficient for everyone.
A quick run through v1
Have an issue?
- Stop what youâre doing.
- If they arenât already pre-occupied, walk up to the front desk and explain it to the floor manager.
- Wait while they forward your problem in their words to the concerned person or team.
A quick run through v2
Have an issue?
- Open the app, and navigate to âHelpâ.
- Our facilities and IT teams (the guys in charge of resolving your issue) have decided on a few pressing categories - pick the one that best matches your issue.
- Describe it the best you can âď¸
A few months laterâŚ
Business was great! We brought in more clients. We were thriving, and despite the best of our abilities, a few snags always come up every now and then.
More clients â increased chances for error â more issues.
This called for a v3 that was efficient enough to cater to an expanding clientele, not just on one floor but across 5 different locations!
The process for building v3
Looking back at my notes, I could split my process into 4 phases.
Phase 1/4: Learn about the problem
via an issue lifecycle diagram
To start, I followed an issue around as soon as it began. I got in touch with anyone this issue made contact with and chalked up a diagram.
via interviews
Having followed an issue through till the end, three players come to light: the client, the community manager, and the facilities manager of that space.
From the clientâs perspective, I wanted to know how they go about raising an issue in the physical world and through the app. From the perspective of the community and facility managers, I wanted to understand how they react to an issue and how they solve it.
Using data
Remember version 2, when clients had to pick a category on the app and just write it out? I pulled ALL the complaints we had ever received into a spreadsheet. What I found: ⨠Raw data. So much raw data.
It took some time to sift through, but once we did we noticed some patterns.
Discovered pain points
- No status information - clients have no idea whatâs happening.
- Inefficient flow - communication occurs verbally or by email.
- Issues are mostly location dependant.
- A backlog of issues exists but is not tracked AT ALL.
- Constrained communication - the given categories donât help enough to narrow the issue down.
Phase 2/4: Give it some structure
via Personas
From the above interviews, a set of personas has been created to help understand each personâs point-of-view throughout the lifecycle.
via Feature Brainstorming
To brainstorm features for the Support section, I created How Might We and Point of View Statements using insight from my interview.
Insight | Need | How Might We | So, HMW? |
No status information after an issue is raised | To be kept updated every step of the way. | How might we help clients be updated every step of the way? | 1. Have a status update screen and history page after submitting an issue
2. Send a notification after each status update |
Issues are location dependant | To be able to figure out quickly where the issue is. | How might we help the teams recognise the exact location as quickly as possible? | 1. Allow users to scan a QR code that pinpoints the location
2. Attach metadata of the userâs contact details if more info is required |
Inadequate categories on the app | To be able to quickly pass an issue along to relevant teams. | How might we help our client explain the issue effectively? | 1. Allow for taking pictures to raise an issue
2. Make the categories more relevant to pick from
3. Create sub-categories to help narrow down the problem |
Inefficient information communication | To maintain the integrity of the source information throughout. | How might we help all parties be on the same page? | Introduce a third-party tool that is integrated with the app and syncs in real-time with updates |
Untracked backlog of issues | To be able to revisit older issues for reference or for completion. | How might we help all teams go through past issues easily? | Introduce a third-party tool that also has a database and allows for analytics and tags |
via Information Architecture
A simple information architecture crafted using the ideas from above.
Phase 3/4: Ideate
Basic sketches and mid-fidelity wireframes
Keeping all gathered information in mind, I explored a few wireframes on paper and then created a set of mid-fidelity wireframes of all of the key screens needed to complete the main user tasks that are part of this journey: raising the issue quickly and effectively, and view status of a raised issue.
Phase 4/4: Wrap it up â¨
I wanted to keep the final interface clean to avoid unnecessary distractions, so I just went with our brand colour and two shades of gray to wrap it up.
Many new components were created and added to the existing system as well!
đĽÂ Aaaand? What were the results?
First, the metrics we were tracking were great.
To submit an issue
New average response time
New avg resolution time
â Â Relevant issues were being addressed Tickets were now spot-on in addressing the issue since the options clients had to pick from were more relevant this time.
đ The process was now streamlined The third-party tool that the tickets were routed through streamlined the process of assigning tickets to the right person/team, thereby reducing acknowledgment and response times.
đ Increase in member satisfaction Member satisfaction increased owing to quick response and resolution times, adequate feedback, and fewer redundant interactions with our people.
đđťÂ Quicker completion times QR location codes coupled with relevant issue options to pick from meant that describing the exact problem wasnât even required every time a ticket had to be raised.
đĽď¸Â Improved organisational efficiency All tickets were now tracked via a centralised system, helping identify frequently occurring issues and how to pre-emptively address them, and analysing feedback to improve existing systems and processes.
Want to read more?
Thereâs one about introducing a new login method to optimise costs without cutting corners,
and hereâs one about onboarding clients on to an app that just received a feature-full update.