OBSS Apps

Role and ownership

I led design on this account and built it: product strategy, research, information architecture, wireframes, testing, interface design, and a reusable Figma design system, with no dedicated engineering team on the project.

The planned experience was adapted to a compatible HubSpot theme, built and published; strategy through to the live site was one pair of hands.

Decisions, and what we set aside

The implementation approach changed part-way through: custom development was dropped in favour of HubSpot. That answered an operational need as well as a technical one: the marketing team can publish and manage content without a developer, and the platform's own analytics are there for later measurement.

Rather than rebuild the planned experience for the new platform, I adapted it to a compatible theme.

What was delivered

• Product strategy & research
• Information architecture
• Design system in Figma
• HubSpot CMS build

Product journeys

7

Publishing model

HubSpot CMS

Connected actions

Demo · docs · Marketplace · support

Counts describe the scope of the work, not its results.

Where it stands

The site is live. Post-launch analytics were outside the project's scope, so there are no result figures here: what shipped is the platform, seven product pages, and the paths from discovery to demo, docs, Marketplace and support.

The work 9 views

1. 01
   Home page

   One suite, not seven listings

   Seven Marketplace listings, each stopping where the detail begins. The suite got its own site so the depth could live somewhere searchable, and so more than one kind of buyer could find a way in.

2. 02
   Product cards

   One card, one need

   Every card leads with the need, not the name, a product-strategy rule rather than a layout preference: time in status, the bottleneck it exposes, and where to read more. Seven products, one card shape.

3. 03
   Docs and support

   Docs where the buying happens

   Moving the documentation inside discovery cost nothing and bought two things: someone still deciding reads from the same place as someone already using, and the depth becomes searchable.

4. 04
   Product identity

   What a buyer checks, in the order they check it

   The order is not a guess. It came from what the Marketplace data showed buyers looking at, then from what the sales team kept being asked: what it does, why it matters, how to start a trial, with the security proof they would go looking for anyway.

5. 05
   Use cases

   A feature is a situation, not a bullet

   Nothing was dropped in the move from list to situation, every function that could be told got told, only through a case a Jira team recognises: where work piles up, how long it sits in a status, and what that costs the release.

6. 06
   Comparison table

   The comparison, made once

   The competitors are in the table on purpose. A buyer compares either way, and a set they can read openly is worth more than one they assemble by hand: reporting, workflow analysis, scale and performance, side by side.

7. 07
   Partners

   What a reseller actually gets

   The strongest thing leads here too, the product carrying the most advertising and the most use, and the rest of the programme follows it: licences, training, priority support, pre-sales help. Draw the reseller in with what they already know, then show what else is there.

8. 08
   On a phone

   The suite, one column deep

   Mobile use was high enough that a reduced version would have left grey areas. Nothing is dropped: the proposition, the apps, the proof and every route out of them survive, stacked instead of laid out.

9. 09
   Reading on a phone

   A dense page, read standing up

   Shortening the page was the easy answer; the order was the real one. It was cut into passes in the sequence the product's own analytics pointed to: the case, the use, the proof, the next step.