Case study · UX design lead · Product strategy · User research
ArcGIS Hub Site Templates
A no-code, responsive website builder to help organizations achieve their initiatives — redesigned from the ground up to serve users at every level of technical proficiency.
Understanding the problem
Hub has always been a more technical app — a little too "GIS-y" according to our more critical users. The site builder is our most used feature, and it's what makes Hub special amongst other GIS products. However, it's also confusing to use for those who are less technical, and limiting for those who are much more technical.
We needed to find a sweet spot that allows for a varying degree of technical users, so that this tool is powerful for everyone.
Relevant personas
We identified two primary user archetypes whose needs were in direct tension — and whose pain points defined the scope of the problem.
"I'm here to keep everyone on track so that we meet our organization goals."
Core needs
- Easy-to-use web builder she can update herself
- Ability to delegate to others
- A way to connect with her organizers
Frustrations
- Confusing, tedious apps without a higher technical wheelhouse
- Feels other sites are designed better — making editing feel inadequate
- Making edits is a clunky, time-consuming process
"Complex app building and maps don't scare me. I spend my days elbow-deep in code."
Core needs
- Smart, intuitive apps for open data and mapping solutions
- Time savings and efficiency
- Advanced add-ons and automation
Frustrations
- Manually updating because less-technical colleagues can't
- Complexity of mapping apps overwhelming the team
- Non-work tasks taking time away from what matters
User flow
Mapping out the site creation user flow to visualize and understand the current experience — where it worked, and where it broke down.
User journey mapping
To build empathy and understanding of what our users experience with our current site templates, I focused especially on Mary — our low-tech persona — because she tends to have the most pain points. By solving low-tech problems, we also remove a lot of the high-tech friction.
Exploration & discovery
I ran a brief, week-long research effort to learn more about how our site editor and templates were performing. The data confirmed what our personas had suggested — and gave us the quantitative backing to build a case for change.
Top takeaways by persona
After reviewing all the feedback from interviews, I noticed major themes that grouped cleanly by persona. This confirmed assumptions from the discovery phase and helped direct us toward next steps.
"Site editor is confusing to use and doesn't feel intuitive at all. I need an expert on my team whose sole job is to maintain this site."
"We are burdened with the task of having to constantly manually update our site. The lack of automation is very time consuming."
"The template gallery is so vast that I don't even know where to begin. It's overwhelming. It would be much more helpful to see templates that are relevant to my needs."
Goal setting & team alignment
As a proponent of intentional UX strategy, I met with all the teams involved to ensure cross-functional alignment. I confirmed the goals of all stakeholders — including users — and outlined them in a single source of truth. This is also where we identified constraints and mandatory requirements.
- Increase customer retention
- Reduce churn caused by site editor frustrations
- Clearer, easier path to beautifully designed websites
- Less effort needed to maintain and update
- Rebuilding the site editor would take ~1 year — out of scope
Ideation
With customer feedback and goals in hand, we widened our ideation to generate design solutions that solve the problems and produce the outcomes we were looking for.
Design sprint
We worked asynchronously on a FigJam board to generate ideas and narrow them down by impact, scope, and feasibility. Several teams were involved — designers, developers, and project managers — which helped surface constraints early and build shared ownership of the direction.
1. Spotlight top templates
After assessing our entire template library alongside years of usage data, I identified three major use cases that mapped directly to our personas. Rather than a vast, undifferentiated gallery, we could curate around these three archetypes.
- Simplest template
- Notifying the public about initiative info, updates, events
- Needs to be very scannable
- Branded
- Moderate complexity
- More engaged with end-users
- Clear CTA
- End-user flows are important
- Onboarding users is the main purpose
- Most time-sensitive use cases
- Most technical
- Needs a clear path to data
- Can be time-sensitive (e.g. COVID response)
- End-users typically there to gather data
- Misc. needs
2. Improve the template gallery
The gallery was too vast and lacking curation. Users weren't receiving as much value as they could be, which was reducing template usage and causing friction for those who wanted no-code websites. By curating the gallery around the three archetypes, we could make discovery feel intentional rather than overwhelming.
3. Automated template editing
For power users like Techy Tammy, the lack of automation was a constant drain. Batch editing, auto-updating connected data, and more advanced options would reduce the manual overhead that was pushing users toward third-party tools.
Design
While there were many existing components within the design system that would be used for these new flows, we were still going to create new components. The design phase moved from rough sketches through to polished, prototyped flows.
Sketching & wireframing
Early sketches focused on the template selection experience and the three archetype cards. We iterated quickly across lo-fi concepts before moving into Figma for higher-fidelity wireframes.
Prototype
The final prototype demonstrated the full template selection flow — from landing on the curated gallery, choosing an archetype, previewing a template, and entering the editing experience with pre-populated structure and scaffolded content.
What this unlocked
By anchoring the redesign around three clearly defined use cases — instead of trying to make everything work for everyone at once — we gave the product team a tractable problem. The template archetypes became a shared language across design, product, and engineering that outlasted the project itself.
The constraint was the design challenge
We couldn't rebuild the editor — that was explicit from engineering. So the design challenge became: how much better can the experience get if we only change what happens before someone starts editing? The answer turned out to be: a lot. Reducing overwhelm in the gallery and matching users to the right starting point changed what the tool felt capable of, without touching a line of editor code.