This week, my project team made significant headway towards integrating our disparate apps or services into the main website. And for these interfaces, where separate pieces meet, we had to suss out a lot of complex logic and nuances. For myself, my two main goals were to provide a smooth user experience and to prevent errors that “broke” the site.

One of the trickier aspects of figuring out the user experience for these integrations was defining the features that we wanted to implement. While we had the initial user flows and mock-ups from the project’s outset, the devil is in the details, and we had to figure out how much we wanted to do vs. how little we could get away with (for a minimum viable product).

There is, apparently, a lot of gray in between the minimum we can do and all the fancy bells and whistles we each could imagine for any given user flow. For example, for buying a plant, we could support a “running cart” with the possibility of choosing any combination of plants from the marketplace, regardless of who the seller is, and regardless of the plant handling: whether the plant is for shipping only, pickup, or both. A la Ebay. Or, we could change the structure of the website so that we would be able to filter plants by the seller and support a running cart that only allows plants from one seller at one time, like DoorDash (this option was unanimously voted down). Or, we could just have a quick checkout for each plant, but allow the customer to buy up to the maximum quantity of the plant being offered.

These were the types of discussions that came up this week as we examined the pros and cons of each approach as well as how we each envisioned a specific flow to look like. Ultimately, the guiding principle that we applied was to scope according to resource availability: the time we had left to work on these features (a “sprint”), the estimation of how much time it would take (after working a few weeks with Django, we are getting a little better at estimating how long it takes to implement certain functionalities), and the level effort it would take to implement a feature a certain way (would it be worth it, or would it take a lot of effort that yielded little gain).

The spoken refrains for this past week were “if there were more time”, and “in the real world”, and “for this project”. I think these are all important aspects to think about: the available resources, the intended usage, and the context of the finished product. These are some of the most rewarding conversations I’ve had, working on a technical group project. I appreciate my group members’ thoughtfulness, the strategic mindset, willingness to help each other, and the bias towards action rather than prolonged rumination.

Integrations, especially, come with a lot of hidden time sinks around every corner, and the time we need to devote to testing, code review, and debugging is growing with each new pull request. As we realize this, as a team, we are really doing well with paring down our list of features, adding those we can’t do to our nice-to-haves/stretch goals/backlog, and scoping just enough to get us to the next state of “completeness”.

We also make it a point to not skimp on the UX. Just because a feature is not as “rich” as it could be, without the bells and whistles, doesn’t mean that the user experience needs to suffer. We strive to tackle any “clunkiness” (this word came up a lot this week) so that the UX is smooth.

Whether it is the user flows for these feature integrations, or the conversations had for the design decisions, I think that integrating standalone services together is an exercise in relationship management. It is rewarding and challenging to consider what each team member wants and how much we can each give towards the end goals. Integration is also about the relationship the end user will have with the user interface: how they will navigate through the site and what they might expect, whether we have met those expectations, or if we can help guide those expectations through design.

My final thought might be a stretch for some, but I’ve nevertheless waxed philosophical on integrations: Once we are not alone, there is a relationship; and with that relationship, there is dialogue as well as give and take. It’s been really eye-opening how this can be true on so many levels, whether it is for integrating software, or for working together in a group project.