Looking beyond feature requests at a deep tech startup

I worked as a Frontend Engineer at SI Analytics, a deep tech startup building a satellite imagery analysis product, from April 2022 to December 2024. Alongside frontend delivery, I took part in UX education and product research. My formal role remained frontend engineering; I had no separate product mandate. This work grew from questions about the product I was helping to build.

Seeing how product constraints shaped requests

For roughly the first year, I concentrated on learning the domain, understanding the codebase, and delivering requested features. The platform detected and counted objects in satellite imagery, and analysts reviewed and corrected the results.

Most customer requests added something to an existing feature. After observing this for about a year, I began to notice how existing constraints shaped those requests. Customers were finding more convenient ways to work within limits that the requested changes would leave in place.

One example was project configuration. Technical limitations prevented the map from displaying all satellite imagery at once. Analysis was also organized around projects, each configured for selected object types. Customers asked to copy a project’s configuration into a new project so they could select other object types and analyze the same area again.

That request made sense within the workflow. I also wondered whether GPU capacity left idle overnight could support additional analyses, allowing the system to suggest other findings in the same area without requiring another project first. This was an idea I wanted to investigate. It made me question what opportunities we were missing when we treated the existing workflow as fixed.

Making research reusable for product decisions

Another obstacle was how we kept the information needed for those decisions. User interviews took place, but their findings were not consistently organized and maintained as design research assets. I wanted to carry out research while documenting its process, so the team would have both reusable material and a way to investigate later questions.

I initiated and ran a three-month UX learning program for development leads, frontend engineers, designers, and QA engineers. About ten people attended an average session, and six completed the full program. We combined HCI principles with research practice on active product questions. I also organized Notion templates for quantitative and qualitative research and for managing the resulting design assets.

Across this work, we produced user journey maps, mood boards, personas, affinity diagrams, and records from focus-group interviews. These materials were later used in planning the following year’s work with existing customers: they helped us develop follow-up questions and explain the reasoning behind design proposals.

There was also a change in everyday collaboration. Details omitted during design had often surfaced during QA, becoming a recurring source of friction. UX discussions began to happen during design review and development as well. I did not measure a business outcome from the program.

Narrowing an interactive-report hypothesis

One study shows how research changed the scope of an idea. We initially explored a map-centered interface for reviewing geospatial intelligence alongside open-source and human intelligence. The assumption was that it could help decision-makers inspect and combine information that did not all arrive in a form suitable for a map.

I led the study with a data engineer, a technical support engineer, and a designer. Three experienced satellite imagery analysts joined a focus group, and two intermediate decision-makers participated in individual interviews. We could not recruit final decision-makers, so the study did not directly represent the people the proposed dashboard was ultimately intended to support.

The participants’ workflows differed enough that we could not justify one universal analysis pipeline. A customizable pipeline remained too broad an answer to guide an interface. We narrowed the work to shared needs: finding information and distinguishing and managing the supporting material used to form a line of reasoning.

We translated those findings into a prototype and completed an internal review. This gave us a more specific hypothesis to investigate, but validation had not moved beyond the organization, and the absence of final decision-makers remained a limitation.

Other ways of documenting product knowledge

GEOINT research and patent work were related ways to explore product questions. At the GEOINT 2023 Symposium in St. Louis, held May 21–24, I attended in a UX Specialist capacity representing the product team. The team prepared questions that published material could not answer, and I visited other booths and documented the findings. Seeing vendors treat customization as part of their product made me reconsider our preference for fitting different customer needs into one product.

Later in 2023, I proposed a four-month UX patent project. My manager allocated time for a designer, a technical support engineer, a data engineer, and a backend engineer to participate. We mapped more than 30 commonly used user flows and considered opportunities against customer feedback, research findings, and business direction. I taught participants how to prepare invention proposals and reviewed their work, so documenting product knowledge would not depend on me writing every proposal.

The group documented 15 ideas. Six patent specifications went through internal invention review and review by patent counsel. Filing was deferred for confidentiality and business reasons.

A contribution alongside frontend delivery

Building the frontend put me close to the workflows that shaped customer requests. My design-research background gave me another way to investigate the questions they raised, with time allocated by my manager and expertise contributed by colleagues.

The contribution I value here is the research material and process we could return to when discussing the product. A journey map, interview record, or documented proposal gave us something concrete to revisit when deciding what to ask next and how to explain a design choice.