SEAP Dashboard
Leveraging Samsung Business units and Developing Kits (SDKs) to power your business ideas.
SEAP Dashboard
Samsung Enterprise Alliance Program (SEAP) is a marketing website and a developer portal. The redesigned dashboard provides a unified experience for Android developers to manage and promote the applications they build using Samsung Developer Kits (SDKs), all from one place, integrating analytics via APIs.
Scope
Identify gaps in the current offering
Concept development
User testing
My role
UX Design
UX Research
UI Design
Duration
Oct 2018- Jan 2019
Stack
Axure
Jira
Illustration
WHAT I WAS ASKED TO DO
-
Redesign the experience of the Developer/ Partner dashboard from concept to development
-
Collaborate with SDKs Product Managers, Project Manager and Program Manager to get priorities
-
Liaise with the Dev team to ensure feasibility
THE RESULTS
-
Twice as many renewals of SDKs license keys
-
Streamlined workflow
-
App store integration
-
80% more traffic according to google analytics
-
100% responsive
About SEAP
The Samsung Enterprise Alliance Program (SEAP) is a marketing website for both Android developers and Samsung partners to showcase their business solutions and list their businesses in a directory of service providers, download Samsung Developer Kits (SDKs), get marketing and development support material, and also reach for Samsung Business units reps to help them build their businesses. SEAP also gives its users access to an admin portal from which they can manage their SDKs, users and license keys, and raise and track support tickets.
What was happening
SEAP users typically initiate their journey as Developers, it's free to sign up and provides them with access to developing tools. One-to-one support from Samsung and directory listing were part of the Partner offering.
Although the path to becoming a Partner was clear, the perceived benefits were not.
Our users had to go to different parts of the site to get the needed information and support. It wasn't clear how to submit Business solutions, or track recent activity; the status of SDKs and license keys were hidden under deeper layers, making users lose revenue since their apps were down due to not renewing their SDK license keys on time.
In general, they were not feeling supported or successful. The research showed the following pain points:
SEAP pain points:
-
Submitting a new Business solution was an ordeal.
-
Finding marketing and dev support was difficult.
-
Raising support tickets represented a lengthy process
-
Unclear how to reach out to a Samsung Business Unit
-
SDK renewal dates came as a surprise
-
Poor communication when SDKs were deprecated and replaced. There was no clear action or direction.
Why work on it?
-
Users were frustrated trying to find critical information quickly
-
Monthly Signup numbers were going down.
-
Partner numbers were stagnating, not a lot of developers were upgrading to partners nor Partners were upgrading tiers.
-
The current dashboard only allowed for user/license key management.
-
User research and Google analytics showed dashboard was one of the top visited pages on mobile devices. The current site was not responsive.
-
Previous endeavours of badges and tiers were not enough to make partners feel engaged or supported.
What we wanted to achieve
-
An experience that makes current partners use SDKs and create more applications (business opportunities)
-
Increase conversion from Developers to Partners.
-
An experience where partners found value in the program and were supported throughout their journey.
-
Improve mobile experience and accessibility at all screen resolutions.
Design approach
I had 3.5 months to tackle the challenge before going on mat leave. In 7 (2-week) sprints, I collaborated with a multidisciplinary team using Jira for ticket management, Adobe Illustrator for graphics and Axure as the primary interaction and information architecture tool. My team was a senior visual designer, 1 project manager, 16 program managers (1 per SDK), 2 researchers, 1 sales/marketing manager, 1 dev lead and 2 senior devs we all worked under traditional agile having daily standups, a weekly scrum, sprint planning and retros.
After having our quarterly report showing terrible numbers my recommendation was to do a level set with our users. I assisted the research team with an interview script, I wanted to learn what were the current biggest pain points since the last user testing was back in 2016 .
Discover
Deliverables
Level set interviews
Competitive Landscape
Heuristics review
Define
Story map workshop
Ideate
Develop
Brainstorming
Proof of concept
Rapid prototyping
Concept testing
Learn and refine
Dev support
User flows
Task flows
User needs
Assumptions
1 sprint
Design principles
User stories
Hypothesis
1.5 sprints
Wireframes
Low-fi mocks
High-fi mocks
Interactive prototype
3 sprints
Annotated Axure file
Light weighted style guide
1.5 sprints
Discovery and initial designs
I supported the research team by providing them with interview scripts to specify the purpose of the studies, as well as running discovery workshops and usability audits. From the initial research we learned that both Developers and Partners had 3 main needs, 2 very technical and 1 behavioural:
1. Meet and track KPIs of their applications (business solutions) in one place. The App Stores data provided them with app-specific stats and SEAP dashboard all operational and admin data.
2. Keep up with multiple applications, SDKs, users and license keys. Some KPIs were missed because an SDK was deprecated, they never made the switch and their app went down.
3. Become a true Samsung Partner. Currently, it was hard to contact a Samsung Business Unit. The benefits of the partner program were unclear and overall they felt they were not in a true partnership, nor that they were receiving proper support from either a marketing or technical perspective.
Considering all the learnings from the initial research, I formulated a hypothesis:
"If users had app stats integrated within the SEAP dashboard they could keep track of all the KPIs they care about, all from one place. Using SEAP dashboard as a single source of truth "
Why a hypothesis around KPIs? Because not meeting KPIs means a loss of revenue.
How do prove this hypothesis is correct? The idea was to add a visual history of activity and analytics to the current dashboard to consolidate various tools they use to determine SDKs and app status. I used Axure for wireframes to find out which analytics were most important to our users, also adding actionable items like download, and share so users could follow up or build presentations.
First round of concept testing
Iteration 1.
What kind of analytics are most valuable?
Iteration 2.
Added user/key management, app analytics and a site-wide search feature
Pivoting
As a result of initial testing, we found out that while both Developers and Partners did care about meeting their KPIs, feeling supported on their journey to success was still important and missing. Benefits were still unclear and the logistics of reaching out for support either technical or more strategic from a regional business unit was still a hassle.
So, the hypothesis changed:
"App analytics and quick pivoting actions (ie. upgrading license keys from that view) are not enough to stop the the helpless feeling. Streamline access to Samsung resources could help users feel more supported.
What also changed was the conversation with stakeholders like the Product Owner of the Partnership program. It was clear that users needed a robust program with clear expectations and benefits that the current program was not ready to have. We reached a point of realization that the business model was in its infancy and its users demanded more of what it had to offer, at least then.
With this new realization in mind, the decision was to pursue our hypothesis and continue with usability testing to bridge as many gaps while the program itself matures.
A hypothesis around support would help us further understand why users not feeling successful and hence not returning to the site or the dashboard or using our SDKs.
How do prove this hypothesis is correct? The idea was to add marketing/news banners and a notification panel to highlight items prioritized by criticality, allowing these to be actionable and dismissible. I used Axure for wireframes and high-fidelity mock-ups for usability tests.
Also used Axure as a documenting and communication tool with the developing team.
Usability testing
Iteration 3.
All features in.
High fidelity mockup for usability testing
How did we measure success?
Increased in usability, support requests and license key renewals.
-
8 out of 10 participants knew how to connect with a Samsung subsidiary & request support.
-
Having access through a quick menu was well received.
-
10 out of 10 knew what to do when a license key was expiring. The notification block was one of the most liked features.
-
8 out of 10 still prefer sending support requests via computer over mobile devices.
If I had time
I'd build a support chatbot at a Hack day. It would:
-
Redesign intake forms.
-
Provide quick support categories.
-
Provide support 24/7/365.
-
Increase engagement by having consistent ongoing access.
The learnings
-
I'm very proud of this project, we were able to incorporate elements that truly helped our users meet their goals more efficiently. Despite the fact, that the program itself needed to mature and that was out of the scope of my role, I can confidently say that this project served as an eye-opener for many stakeholders to step back and restructure the program itself.
-
Reframe the marketing panel from being product announcements driven, to social engagement and surface relevant local Samsung events based on the user's location, interests and current SDKs and solutions.
-
Leverage the psychological effect of exclusivity and scarcity by incorporating the tier system into this dashboard, adding opportunities to upgrade to partner if the developer or upgrade to different tiers if already a partner, all within the dashboard itself.
-
Evaluate the colour palette to adhere to WCAG standards; particularly for the donut charts, the lighter shades may need to increase the contrast ratio.
