Select Page

Homes Content Collection MVP and Beyond

PROJECT
Role: Lead UX Designer (with one associate)
Deliverables: Hi-Fi Mockups, Prototype
Design System: Existing
Device: Desktop Web Only

CHALLENGE
We needed an application designed in one sprint that would facilitate the production and management of rich content by a massive amount of creative professionals at scale for over 300,000 neighborhoods, parks, schools, and condos across America.

We were handed 3 sprints and a business flow diagram by the CIO. We were to stand up an application that would enable more than 2,000 contractors to generate images, descriptions, scripts, voice-overs, and videos.

Development was given 2 of the 3 sprints, and every developer on our floor was pulled from their projects (~50 devs). Design was given one sprint and I received an associate designer to help with the initial push (she would roll off after release).

ACTION
This was a sprawling high speed project. For the MVP, nailing down business requirements for something that had no existing users and that no one had done before, proved to be mostly a shot in the dark.

There was an example video made for kickoff, and we talked with the creators of the video to get an idea of how their process worked, but we knew it would probably look very different at scale, so we had little to go from…and even less time.

We decided we were going to have to make our best guesses with what we had and course correct as necessary. Design time bled into development time, so developers were working from shifting designs – an intense experience for everyone involved.

At a high level, the application would operate as a place to house the content and facilitate workflow, allowing roles to hand off to one another.

After the release, the product manager and I continued to support the product, keeping close contact with users, plugging holes, and doing our best to fix the experience as things changed.

We listened to our users’ challenges carefully, and proposed thoughtful solutions, but the maintenance team for this project was small, and often there were too many competing priorities to actually be able to deliver on the pain points we were hearing.

Ultimately, the people and process elements were vastly simplified, which also simplified the application, allowing us to redesign and rebuild a better 2.0.

RESULT
Despite many many challenges at the start and many difficult lessons, this project was ultimately a success. Homes.com had most of the initial content pages they needed by the launch of their Super Bowl commercials in 2024 and the application won an award for most innovative at RVA Tech.

Content Projects: Aligning Language

The overarching goal was to provide content for every Neighborhood, School, Park, and Condo in America. For each of these, there would need to be a written description, beautiful photos, and an engaging video with narration.

As more management features became necessary after launch, I quickly realized the need for a more controlled vocabulary, so that peoples’ language and the system language could align.

For example, the use of “neighborhoods” was confusing because it referred to both a single unit of content and multiple units of content, so after talking to users, we settled on “Project” to refer to the group of objects that needed content.

There were a few of these alignments that needed to happen. Some of the terms will be used throughout this case study.

So instead of:

Neighborhood

– Neighborhood (1)
– Parks (2)
– Schools (3)
– Condos (3)

It became:

Project

– Neighborhood (1)
– Parks (2)
– Schools (3)
– Condos (3)

The 3 Major User Groups

Contributors
Composed of mostly contractors, but some employees as well, contributors are specialized roles with specialized needs.

Overall they needed to:

• See their assignments and tasks
• Add their content to the system (high feature variation among roles)
• Hand off to other contributors
• Send work backward in the process for collaborative editing

Managers
Different types of managers needed slightly different things.

But overall they needed to be able to:

• See their assignments and tasks
• See their team’s assignments and tasks
• Monitor their team’s performance
• Grade contributor work
• Understand contributor availability to assign work
• Configure teams
• Add/Edit/Delete Entities
• Add/Edit content themselves
• Pay contractors

Upper Management
Needed to be able to monitor progress, report, and observe.

Upper management needed:

• Full transparency into the project at both a macro and micro level
• Full editing capabilities (God mode)

To be clear: we did not know all of these needs when we built MVP. Many of these needs surfaced after launch.

Roles, Teams, Tasks, and Handoffs

The original conception of this business process was that contributors would work in tight knit cross-functional teams, focusing on a set of content projects and completing all entities within those projects.

Individual roles would, of course, have their own departmental reporting structures.

We were given a business flow diagram and asked to build software to it. I don’t have the diagram, but here is a table version of the roles and the teams.

Role Tasks Hands To Type Department
Content Manager

Oversee projects, manage resources

Content Writer

Employees

Content
Content Writer

Researches locations, writes scripts, descriptions, and shot lists

Editor & Photographer

Contractors

Content
Editor

Reviews, edits, approves, written content

Photographer & Voice Over

Contractors

Content
Photographer

Collects media assets based on shot list, contributes to shot list

Photography Manager

Contractors & Employees Media
Photography Manager

Reviews, grades, curates media

Video Editor

Employees

Media
Voice Over Artist

Records audio of script

Video Editor

Contractors

Media
Video Editor

Assembles video

QA

Contractors & Employees

Media
Quality Assurance

Reviews, Approves, and Publishes

Employees

QA

So the application needed to facilitate each of these tasks (and many more sub-tasks) as well as allow users to navigate their projects and pass their work back and forth.

This meant that everyone would be working from the same dashboard, but with different permissions based on role, and handing off would essentially just add to the teammate’s queue that was next in line.

Assignment Queue
In the assignment queue, contributors could see what tasks needed to be completed, and how many more were coming. Clicking into one would open up the details screen.
Assignment Details
The assignment details screen allowed users to see all of the information gathered about an entity, its status, and what content was attached to it. Contributors would use this screen to input their content and then pass it to the next contributor in the line.

MVP Release

Miraculously the product was delivered on time and (mostly) according to spec; an amazing feat in itself, given the level of complexity and short timeline.

We only had a small group of newly promoted content managers to work with, and they had no idea what to expect with their new jobs. I had shown designs to them before sending to development and they seemed to understand the basic interface. However, without having started their brand new job or knowing much about it, the feedback was limited.

In beta testing with the content managers, we assigned each of them a role (photographer, voice over artist, etc) and had them sit in a room and pass assignments around. It was a little confusing for them at first, but they got the hang of it. We knew we would have some work to do after release.

The MVP did what it was intended to do: it enabled the employees and contractors we had already hired to get started on their massive task ahead. But there was still a lot to be desired, and after release, our development resources were cut to a single small team.

Research Methods After Release

After initial release, we relied on several methods to keep our fingers on the pulse.

Shadowing
Several of our contributors were on-site at the office, so all we needed to do was go find them and ask to watch. We could also get indirect feedback from managers on issues that their teams were having.

Interviews
For contributors and contractors that weren’t on-site we set up ad-hoc interviews to gather pain points and see how things were working.

Help Desk
The PMs also worked the help desk for this application, so that provided a lot of insight.

Log Rocket Meetings
I set up a bi-weekly meeting with the PMs and the tech lead to watch Log Rocket videos for 30 minutes.

The Exponential Complexity of using Contractors

In the rush to market, one of the biggest challenges was simply finding enough human talent to develop the massive amount of content needed to meet the very aggressive deadline.

It was decided early on that we would have to use contractors to do this. However, this created many more problems, putting an extraordinary weight on managers and actually slowed the project down.

Recruiting
Recruiters were incentivized by the hire and had difficulty matching contractors to locations. As a result, many contractors were hired that were too far from any work sites.

Onboarding
Onboarding contractors was kind of an afterthought. Some videos were thrown together at the last minute, but many contractors still didn’t understand what was expected of them or how to operate.

Communication
Legally, we were told, contractors had to be separated from employee systems. This meant no company email, no company chat. This also meant our application would be separate from the main application that employees were using and iFramed into their experience.

Accountability
There was little trust for the contractors and because of this, there were many checks put in place and they were given no agency, which put a lot of responsibility on managers and forced us to put walls around roles in the form of permissions i.e. a content writer could only edit the content they were assigned.

Irregular Availability
Because contractors were operating outside the confines of the company, they were essentially allowed to set their own hours and schedules. This became a cat-hearding problem for managers and required us to come up with many new features on-the-fly within the application (see mocks below).

Payment
Payment had to be housed in a separate application and was a very manual process, leading to human errors. Contractor pay was also complicated by a sliding scale of quality and number of completions, which lead to disputes and misunderstandings.

Bueller?

To help managers with their availability challenges, I provided some people solutions to help them make better informed decisions. We added a “Project Manager” tab to help managers better allocate resources, though scope was limited. The goal was to see which resources had availability, and which were overloaded and spread people out more evenly.

Project Manager: Projects
The Projects tab showed managers which assignments needed resources. From here, managers could assign roles to empty projects. 

Project Manager: People
The people tab allowed managers to see who had availability and who was overloaded, enabling them to even out contributor workloads and see availability.

The My Projects Tab
This chart gives users a peek into the progress of all assignments within a project. As tasks get completed, the chart becomes more and more green. Managers could also quickly see where there were unassigned roles (yellow) and if there were reworks or tasks overdue.

A Quick Win

Although no one actually said anything explicitly, it was becoming clear from watching people, and the complaints we were getting, and from navigating the data ourselves: we needed to provide a more transparent overview into the status of any given entity.

Users could search through the pile of projects and entities, but it was difficult to get a gauge on where they stood.

So I devised a color coded chart and showed it to a group of content managers. It took them a second, but they understood it without explanation, and once they did, they “LOVED” it. These are the things that give me joy in my work.

After its release, this became a game changer and continues to be the most used feature.

Hard Realities

Ultimately, it was discovered that the creative process was not as linear as previously conceptualized, but (low and behold) extremely messy, and the many walls that were created to accommodate contractors were inhibiting collaboration. CoStar tries to maintain an open data policy among its employees, allowing anyone to change anything, as long as there’s a record of the change.

I designed a table to track changes (according to other places this table existed) and then contractors were let go shortly thereafter.

Audit Table
In the Web Enterprise system, 360’s were pages that allowed users to see everything about a data object – in this case, a Neighborhood 360.

This is a fairly standard “audit” table, used for tracking changes. However, the nature of some of the content objects for Homes was very different.

For example, a photographer might go into the attachment manager screen and make 35 changes before exiting. This needed to be shown differently than we were accustomed to, so we had to devise solutions.

In the example here, we’re viewing changes to the script, which is just text.

Text Diffs
In discussions with development, showing diffs in text was actually very easy to execute, so I borrowed some standards from around the web and incorporated them into a modal for users to view.

This was a very well received stop-gap for writers and editors that were passing things back and forth. They could now easily see changes that the other had made.

The ultimate goal was to allow for commenting and track-changes in the text field itself, but that was a feature further down the line.

2.0: Rise of the Phoenix

After contractors were either let go or converted to employees, the doors were opened for starting over with our application. I had more understanding, more to work with, and more creative freedom.

So I started to redesign the application and build buy-in. I handed these new concepts off to the designer that I worked with before I left, and she took them to delivery. All reports after release have been very positive.

Making People Real
With the shift to employees, we could tap our HR database and bring in photos and stats of team resources. This was actually a new concept for research applications as a whole, and was very well received. 

Additionally, I was able to leverage an existing component to provide quick data about a contributor’s “portfolio” (work load).

Maps!
We had been pushing hard for maps from the start, but they were always deprioritized in favor of more pressing features. This is the birds-eye, showing progress across the country, and allowing users to drill down.
Attachment Manager 2.0
We were able to clean up a lot of the UI in attachment manager, and add a few smaller features that made a big difference in the experience.
Contributor Portfolio
We were able to leverage the portfolio concept used in other places throughout the research organization. Contributors would now own a handful of cities and all of the projects inside.

More Maps!
Showing contributors on a map, what entities were ready for their input and which weren’t was a HUGE boost for comprehension and efficiency. 

Results

I kept contacts with people on my team and the consensus was that the reorg and the new designs had really helped things get moving and the teams were making very fast and steady progress.

The application eventually won an award at RVA Tech for “Technology Innovator Private Sector – Large Cap”.

As of this writing, much of the neighborhood content has been released to the Homes.com consumer facing site. Looking at the page, it’s easy to take for granted the sheer number of people, specializations, effort, and technology that go into bringing this sort of rich media and content to life behind the scenes.

Bellevue neighborhood from homes.come:  Bellevue

Post-Mortem: People, Process, Technology at Scale

Letting the contractors go was unfortunate, but it did simplify things for the project immensely.

From a people perspective, using employees meant more trust, more agency, more stability, and less management.

From a process perspective, it meant fewer checks, easier collaboration, less grading, and no payment.

From a technology perspective, it meant we could cut many features and open up the application to make it more flexible and intuitive. And it meant we could integrate some features into existing applications – for example, photographers could access all of their photography objectives, Homes and photo shoots and research, in one place, and it also allowed us to do more with the management side of the application.

At the heart of the problems experienced on this project was a scale challenge, which led to a people challenge, which lead to a process challenge, and ultimately a technology problem.

The immediate need for a vast amount of human talent to create all the content within a year prompted the decision to use contractors, which inflated the process, which created sprawling and unwieldy technology, especially with a small product team to support. Beyond the rapidly inflating need for features, there were also many many data issues that we were trying to work out mid-stride, at full scale.

With 20/20 hindsight, different approaches become more apparent. Here is how I would have preferred to approach this:

Scale Gradually
Starting small, with 2-3 test sites across the country, allows for experimentation and observation. This would do several critically important things:

• Avoid assumptions and solutions that don’t work
• Understand the problems that do exist
• Observe the best solutions for those problems
• Gain a realistic understanding of pace, which can then be extrapolated

Starting small creates a test lab where teams on the ground can understand their own challenges and create their own solutions, allowing the product teams and upper management to observe and understand the real problems and get to the best solutions before scaling up.

Start with an analogue process
Building complex technology in the dark made it very difficult to change at speed.

It was common for many research teams to work from spreadsheets, and I believe this project could have started with spreadsheets, cloud folders, and Google Docs. Being able to observe the manual process allows the product team to more easily identify user needs and efficiencies that can then be translated into a more confident feature list so that the MVP is closer to the mark.

Map end-to-end experience before building
I believe slowing down to think through the end-to-end experience for the 3 major user groups, not only would have allowed us to avoid some pitfalls, but would have allowed us to identify areas that would need more attention, saving a lot of time and money in the long run.

Adjust Deadline Expectations (for realism)
Easier said than done when there is literally a billion dollars riding on a project. However, the content pages for Homes were one small (but critical) piece of the puzzle, and adjusting expectations for this one feature with the promise of slower but more steady and higher quality results, should be an argument that could be made to even the most humorless of investors.

Setting more realistic expectations for delivery from the start (based on observation) is almost always easier than ratcheting back expectations later.