Chapter two
One deal. One place to keep it together.
The circle was the transaction itself. The people involved could be brought into it with the roles and access they needed. The work belonged to that deal, instead of being scattered across whatever system each person happened to use.
That sounds straightforward until you try to build it. Who can see a particular document? What happens when someone leaves? What should a person see when a task changes hands? Every answer affects the next person who opens the app.
I pictured the person arriving in the middle of the work. They would not have heard the earlier calls or know which version of a document had been replaced. A useful app should help that person catch up. Designing for them meant thinking beyond the first screen and asking what the information would mean later, to someone who was not there.
The more carefully we worked through those questions, the clearer the purpose became. I wanted someone to open Circle and understand what needed attention, what had been done, and where to find the record.
One deal, one circle
The record needed to outlast the conversation.
A conversation ends. The consequences of it may not. A decision made on Tuesday can matter weeks later, when somebody else asks why a job was handled a certain way. A record is useful only if it is still there when that question arrives.
Circle brought notes, contacts, documents, and transcripts into the same transaction as the work they described. The aim was to keep a decision connected to its context, so a person could follow the story instead of guessing at it.
Keeping a record is also a way of reducing the burden on people’s memories. Someone should be able to take a break, hand over a task, or move to another transaction without becoming the only place an important answer exists. That was part of the care behind Circle. I wanted the information to remain useful without depending on one person always being available.
I could see the value of that. I could also see how much had to work underneath it. The screen might look simple, but the responsibility was not. We were asking people to trust the app with details they could not afford to lose.
Inside the product
A simple screen can hide difficult decisions.
The original app had to recognize the relationship between people and work. A task belonged to a transaction. A message concerned particular people. A record might need to remain available after someone’s role changed.
Making those relationships dependable required choices that a person using the app should rarely need to think about. The complexity did not vanish because we kept it off the screen. Someone still had to work through it.
A task list can be drawn quickly. A task list that behaves sensibly when people and circumstances change takes more thought. That distinction runs through a great deal of software. I was learning it in the details of Circle: the value of a feature was partly in what happened when the straightforward version of the situation stopped being the one in front of us.
That helped explain why the build took so long. We were trying to make complicated work feel manageable. Every shortcut had to be judged against the moment when somebody would depend on it.