Early product ideation

I had the opportunity to partake in the early research and ideation process of creating the new iteration of AXIS, as it is seen today. I was involved in early workshops, discussions, direction making, as well as designing a large number of key features and templates that would lay the foundation of the product moving forward.

End to end feature design

Throughout the product's development I've had the opportunity to create features from end to end. Clarifying requirements early to ensure we're designing the right solution. Keeping in touch with developers to design a feasible solution, as well as providing design documentation and kick-off sessions. Finalising the feature by testing it along with quality assurance teams.

Cross-platform design

As the development of AXIS continued, I was responsible for producing a consistent experience across several platforms. Starting with responsive web, covering a wide range of screen sizes and types allowed us to solve a large number of templates and features; before translating them to other platforms such as mobile, tablet, TV, XBOX and a range of set-top boxes.

International teams

As the scope of development grew over the years, internal teams from around the world took different sections of the app development. Despite this, a large portion of the design team remained in Sydney. I've had the chance to facilitate a range of kick-off and check-in sessions for a number of features in collaboration with international teams.

Recent clients using AXIS

Features I designed on AXIS

AXIS: Hero Carousel

Creating a hero carousel component for a multi-platform service.

2023

AXIS: Design System

Creating and maintaining a design system for an existing white label product.

2022–23

What it needed to do

Operators and end-users

Operators

Operators are our clients utilising AXIS, setting up, editing and publishing their content.

As an operator I want to:

• Display Upcoming, Live or Past Sport content and have a relative status displayed to the end-user.
• Display Separate Experiences for Visitors vs Users.
• Show mixed content in the Hero Carousel, such as episodic TV show content, Movies, Sports and more.
• Display a video background to increase engagement with my carousel content.

End-users

End-users navigate and consume content published by the operator.

As a user I want to:

• See relevant information surfaced about the content without needing to enter the details page.
• See when an upcoming piece of live content is starting.
• Resume or play content straight from the carousel.
• Purchase or rent content straight from the carousel.

The process

We utilised a process based on the double diamond framework, adapted to fit our product team’s pipeline. Involving relevant parties throughout each phase in our projects and features.

Understanding the problem

The lead designer conducted a customisation analysis on AXIS. This involved investigating:

• Which components or templates of AXIS were frequently customised by our clients.
• What were the common customisation requests.
• Frequency of each request to prioritise which features to work on adding or improving.

As hero banners are often the first content presented to end-users, they were also the most frequently customised.

Combining the data from the customisation analysis, we’ve found that 4 of 6 clients customised or explored customising our “out of the box” range of hero banners to match some of the current industry standards.

Market research insights

• 5 out of 6 services use a video background on their hero carousel.
• 4 out of 6 services use a full height 16:9 background image, while carefully utilising gradients and margins to ensure legibility and discoverability of content below.
• 6 out of 6 services reduced their carousel functionality, such as using a static image instead of a video background on their mobile apps.
• Unless showing live content, 5 out of 6 services display a "More Info" button on TV platforms for Movies and TV Shows.

Complexity exploration

In the early stages and throughout the process I aim to gather insights into areas that may pose either a technical challenge during development, or that will require some more thorough exploration in design. Highlighting areas that may require discussions to take place early to understand the scope better. Here are some notable areas of complexity faced in this feature:

Defining the MVP

After conducting complexity analysis and organising various catch-ups with developers to discuss feasibility, it was deemed that video backgrounds would be the largest and most difficult to estimate. The developers still needed to perform a spike into how they’d implement it. Based on our research done earlier, we made the decision to focus on the frequent client customisation requests as our MVP solution, and handling the video background as part of the second phase.

Whiteboard sessions

The early phases involve whiteboard and sticky note sessions. Brainstorming with the design team around what the hero carousel will feature, as well as any considerations we can see that will require further exploration, either through user flows, prototypes or during visual design.

In the case of this new hero carousel, we were familiar with components on AXIS and had enough market research to base a lot of decisions on. In the case of a more complex feature with more unknowns, we could facilitate kick-off workshops with relevant parties. Using several frameworks to facilitate the creation of ideas for new features:

• Design Studio
• Crazy 8s
• Storyboarding
• Mind Mapping

Layouts, flows and states

Responsive Web App provides insight into how much extra exploration smaller screens may require with the additional elements. Solving a lot of these problems early on will allow us to translate most of the decisions over to native mobile platforms.

Native & TV platforms most of the rules and behaviours will carry over for consistency. However, platforms like iOS, Android or TV targets will have their own documentation with any platform-specific annotations.

Layouts, Flows, States, Edge Cases and Annotations documented using the wireframing and prototyping software Axure. We can quickly begin to visualise additions to the hero carousel, allowing quick iterations due to their low fidelity nature. Wireframes and flows also serve as a great discussion point allowing the design team, developers, stakeholders and more, to quickly see the direction. It's also worth thinking through high-level rules and behaviour at this stage, though it's a fine balance of not adding too much detail too early. Ensuring time is well spent in case any aspect doesn't make the final design or build.

Requirement exploration

After a series of internal reviews and discussions that helped iterate the layout, I begin to explore other requirements and goals for the feature. So far we've created the general layout based on our existing hero offerings and in reference to market research. We've also added new components to the hero such as buttons, short descriptions, metadata and more. We can now begin to explore how those components will be affected by our other requirements such as:

• Supporting mixed assets in the carousel.
• Implementing enhanced live support (e.g. countdowns for upcoming, state changes for live content).

Above you can see an example of a wireframe created to explore and showcase:

• What an event asset would look like.
• How the components translate over to a mobile device.
• Breakdown of action states that will be present on this particular asset type.
• Early exploration of how components like badges or buttons adapt to a smaller screen when their labels exceed available width.

Presentation Manager

Under the hood of AXIS is Presentation Manager. A web interface allowing operators to control their content, users, its components and more. Each component, like our hero carousel, has a range of properties allowing the operator to change aspects such as content alignment, visibility of elements like the tagline or badge and more. The new hero carousel introduced a number of additional properties to ensure the user would have an adequate level of control, without the need for developer support. As we explored each part of the carousel, we also created a document detailing properties for each component of the hero, as well as expected values, copy and tooltips:

Accessibility

Current implementation

We needed to be strategic about how we'd create specifications for accessibility; across varying devices and operating systems. Starting off by performing an in-depth analysis of existing accessibility implementation on AXIS. We discovered a number of inconsistencies between similar templates such as sport detail pages vs movie detail pages.

Guidelines research

Ensuring all apps followed rules and guidelines, I proceeded to research platform-specific accessibility standards covering:

• Browsers on Windows and Mac devices
• iOS and Android phones and tablets
• Various TVs and set-top boxes

Market research

Conducting and documenting research on the extent of accessibility implementation present on video services in the market. While it helped define the scope and expectation, it also indicated that most big services on the internet cover a minimum requirement of accessibility implementation.

Detailed design

Annotating navigation order, interactions and specific narrations, alongside any UX documentation provided to developers.

Design reviews

Making sure the implementation is adhering to designs and guidelines, I review the implementation with Quality Assurance teams. Documenting inconsistencies or need for improvements.

Visual design

My visual design approach begins with an exploration of areas that I’ve identified as potentially problematic or will simply require further exploration to ensure clear rules and good decisions. Identifying and exploring these early ensures that we focus on solving possible issues early on before creating detailed specs that may need to be altered otherwise.

Leveraging existing components and styles

I aim to utilise existing components and styles as much as possible to reduce development time and retain styling consistency. Reducing having one-off styles or components.

Meeting AA WCAG accessibility standards

• Ensuring contrast meets AA standard.
• Producing specification for developers to follow when implementing accessibility functionality.
• Creating clear focus states for keyboard navigation.

Image format for mobile

Mobile format reduces our horizontal real estate. The common 16:9 image format used on larger devices wouldn’t be impactful on mobile devices.

Height rules

With the browser set to full screen width, the 16:9 background image can take up all available height. Exploring so that image and video background are not obstructed with the new metadata, actions and more. Ensuring optimal discoverability of the content below.

Mixed content

When mixed content is present, such as a mixture of both movies and TV shows, the content area will vary in height. Sport content often has longer titles than most movies and TV shows. Exploring varying content pinning rules through quick prototypes to determine the least visually disruptive experience.

Visual design specs

Since our development team was working from Mumbai, in a different timezone, it was crucial to provide them with clear spec sheets outlining all expected rules.

• Typography rules
• Character limits
• Layout spacing, padding and margin rules
• Content area rules
• Platform specifics

Beyond development, this also serves as a reference point for design reviews and quality assurance.

Outcomes

Previous hero for comparison

Figma's properties

Throughout the creation of the AXIS design system, we utilised Figma’s component properties to reflect the control AXIS provides to operators per component. It was no different with the hero carousel, as it would be added to the design system and utilised by service designers.

Besides feature-based projects like this one, we’ve been hard at work producing a design system for AXIS. Bringing consistency between our front end apps and our design documentation, the design system served as an invaluable starting point for producing the visual designs of the new hero. Check out the Design System case study if you’d like to know more about the design system work.

Three gaps to close

Source of truth

The design documentation became misaligned over time with the front-end apps.

Lack of clarity

Created confusion for sales and solutions on what is available out of the box.

Outdated codebase

Contained functional and visual inconsistencies between platforms.

Who it's for

Service Design and Solutions

Utilising Figma’s robust set of functionality such as properties and variants, allows service design and solution teams to quickly apply a client’s branding. Allowing them to produce mock-ups for various scenarios effortlessly.

Product Designers

The Design System will be utilised as a framework for creating any new features. Ensuring consistency and saving time by allowing designers to quickly create and re-use components. Providing more time to create solutions than recreating and verifying existing functionality and components.

Developers

Developers will use the design system as a reference point for the AXIS code re-write. Translating over the established token system to allow a smoother design to development transition. The design system will also contain spec sheets where needed to help guide developers, QA and project managers in the finer details of each component and template.

What success looked like

Plan of attack

In the early stages of planning the design system, we decided our focus should begin with the responsive web app. The platform covers a range of breakpoints, including desktop, mobile and tablet sizes. Most of those components would translate over to native iOS and Android platforms. Followed by completing TV designs. This approach would also allow us to work out the structure of components built within Figma on the most complex platform first.

Striking a balance

Utilising Figma’s robust component functionality, it was important to determine a balance of flexibility, but also ensure the components don’t become so complex that they’re difficult to understand or update.

Documentation

Utilising Confluence and Jira, every page template had a detailed outline of all expected adjustments as well as their original values. This provided support for developers during the code re-write, product owners and managers in writing accurate tickets and QA with a reference for testing.

Early access

Providing early previews to the wider design teams within the company was a fundamental part in shaping the design system. Gathering their feedback and building a mutual understanding was a fundamental step in ensuring we spent our time wisely.

Outcomes

One schedule per experience

MTRIBES only allowed its users to have a single schedule per experience. This complicates things for users when attempting to publish content with complex recurring schedules, forcing them to duplicate the content to create more granular schedules.

Why it mattered

Productboard feedback

Utilising Productboard, our clients were able to vote and comment on roadmap features. Allowing us to gauge the priority. The feedback also included a lot of valuable use cases that served as a foundation of our requirements.

Existing functionality

During the initial build of MTRIBES, the scheduling functionality was created as an MVP solution, only allowing single schedules. This resulted in clients duplicating experiences in order to achieve flexibility. Complicating the workflow for publishers using MTRIBES.

Goals

The process

We utilised a process based on the double diamond framework, adapted to fit our product team’s pipeline. Involving relevant parties throughout each phase in our projects and features.

Understanding the problem

We gathered user feedback using Productboard. Allowing our clients to either vote on roadmap features or suggest ones based on their use cases and pain points. There was a high frequency of requests to expand our scheduling functionality by adding the ability to create recurring schedules.

We based our use-cases on client comments from Productboard. This allowed us to focus on creating a feature that solved customer pain points rather than simply adding a recurring schedule mechanism without grasping the bigger picture.

Users

The key audience for this feature would be content publishers using MTRIBES.

Market research

Research of various competitors and products using recurring schedule implementation was useful to reference different mechanisms. However, each competitor’s or software’s recurring schedule functionality was built around a specific context. None of which provided examples of solving similar use-cases to ours.

Ideation and exploration

The design team got together early to workshop the direction of the feature, breaking down use-cases from our clients’ feedback to creating some high level sketches on the whiteboard.

One of our early options referenced our in-house presentation manager used on our product AXIS. Presentation manager serves as the web interface used to manage content on AXIS. It also features a recurring schedule mechanism our customers were familiar with, so it served as a good baseline of what our customers would expect.

Wireframing

After generating ideas and deciding on a few options to explore, I begin to create wireframes based on everything gathered and explored so far.

Below is an example of my wireframes covering key screens and states, accompanied by annotations outlining rules and behaviour.

Multiple recurrences

Exploring nuances of having multiple recurrences as well as thinking through implications of removing them for an active experience.

Recurrence options

Working through various mechanisms that satisfy our user needs. While utilising clear language and UI elements to ensure a reliable user experience.

Edge cases

Exploring and documenting validation and errors the user may encounter.

Challenges

Cross discipline collaboration

I'm a big believer in making sure not to work siloed from the rest of the team. Here is a brief summary of collaborations that have taken place during this feature, and across most others I've worked on.

• Design team check ins for transparency and retaining momentum.
• Feasibility catch ups with developers to ensure we don’t detail solutions that won’t be possible with our current resources, tech or knowledge.
• Sharing early explorations with developers and quality assurance teams to gather technical insights that help shape the solution.
• Stakeholder check-ins to present progress, and discuss decisions that are backed with research and usability testing results, as well as addressing any feasibility concerns.
• Kick-offs with relevant teams when designs are ready for development.
• Working with copywriting teams to assist with release notes and help centre documentation.
• Grabbing a good bite at the pub to decompress.

Design process documentation

Design process documents, internally referred to as DPDs, serve as a point of reference of the decisions made to complete a feature. Future teams can use it to gather insights into decisions made, removing ambiguity about why certain things were built the way they are. Giving further insights into any technical challenges, constraints, research and usability testing results that shaped the decisions and solutions.

• Separate to our UX documentation and any visual design specs provided to developers.
• Includes goals, use-cases, competitor research, testing results, decisions and retrospectives, future considerations.
• Learnings section also allows the designer or designers working on the feature to look back on and reflect what could be done differently in the future for a more efficient process.

Facilitating usability testing

There's only so much data to be gathered from competitor research. To back more complex decisions, usability testing is a great way to get insights into how functional our intended solution really is. However, despite the importance, not every project and feature will allow resources for testing.

Usability testing is a large topic, this section is a brief summary of my approach. I often reference Nielsen Norman Group articles and studies to gain further insights for best practices: Usability Testing 101 and Why You Only Need to Test with 5 Users.

Resourcing

Usability testing can be a resource heavy task, we took the opportunity to combine the testing with 2 other ongoing features. Since all of the work took place on the same page as scheduling, it made sense for us to write the testing protocol so it lets us validate 2 other features in one go.

Testing protocol

Unfortunately I no longer have access to the final script we ran our testers through, however here’s a baseline we drafted prior:

Insights

After synthesising the results using affinity mapping we gathered the following results:

• 2 out of 5 users didn’t initially understand the requirement to set a timeframe for the recurring schedule.
• 1 out of 5 users didn’t find the terminology “same day” “next day” immediately clear.
• All users completed setting a recurring schedule in the end.

Digesting results

Despite most of our participants successfully completing the recurring schedule, we saw room for improvement in the following areas:

• Improved copy to accompany each part of recurring schedule, providing context to the user.
• Improved hierarchy to reduce user error.

Iterating based on testing results

To address some of the concerns spotted in testing and reduce user error. We went ahead with re-arrangement of the section. Improving hierarchy by placing the recurrence fields first followed by setting of the timeframe the schedule will run for. This change brings the recurrence fields to focus first, where previously the user may have filled out the timeframe first and potentially ignored the recurrence fields resulting in an error. This would also create a visual distinction between the one-off and recurring schedule.

Outcomes

The addition of recurring schedule allowed clients to maintain a cleaner UI by reducing the need to duplicate experiences for each schedule, in turn simplifying their workflow.

Revised layout after testing

• Improved hierarchy
• Additional copy providing further context of each section.
• Revised visual design on field components to reduce excess height.

New scheduling in-situ

Between a toy and CAD

I wanted to map out a home properly: where the walls really are, whether the sofa fits, how a second furniture arrangement would feel. The room planners I tried were quick but loose with measurements, and CAD packages were precise but slow to set up for something this personal.

So I designed the tool I wanted. Precise like a CAD sketch, where every wall can be typed to the centimetre, but quick enough to try an idea in a few minutes, and visual enough to show someone else.

Three modes, one plan

The 3D view fills the screen and everything else floats over it. The work moves through three modes, each with its own colour so it's always clear where you are.

From a room to a whole house

• Floors and stairs. Basements, half floors and landings, with straight, L, U and spiral staircases that cut their own hole in the floor above.
• Layouts. Keep several arrangements of the same rooms side by side and switch between them.
• The Workshop. Sketch a piece of furniture of your own, then place it like anything in the catalogue.
• Share links. The whole plan is compressed into the link itself, so it can be sent without an account or a server.
• Blender export. One click gives a .glb with everything named, grouped and in metres, ready to render.

Conventions before features

With this many tools, the risk is that each one behaves a little differently. Early on I wrote down the interaction rules: how the pointer, keys, snapping, dimensions and selection work. Every new feature had to behave like its nearest existing neighbour, and whenever I corrected something in testing, the correction went into those rules too.

The same thinking went into touch. On tablets and phones the tools rearrange, gestures replace the mouse, and a short tour on first launch explains how to move around.

Designing in the real material

I designed Floorplanner then built it with Claude Code. I established the direction, the interaction design and the details; Claude wrote most of the code, and I tested every change in the browser and sent back what felt wrong. It let me work like a designer with a developer at my side, in the real product instead of a prototype.