It’s been roughly 15 years since I made an entity–relationship model, so it is with great surprise that I sat in a meeting the other day and thought to myself “This project needs an ER model before we can do anything else.” I almost asked out loud, “WHO SAID THAT!?” But once I got over the initial shock I realized that my subconscious isn’t completely full of crap (this time).

But let’s back up. I’m working on a project to combine a variety of different back-end services into a single product. As we were talking about it and the discussion shifted to design, I realized that before we could create user journeys and get started on the interaction design we first needed to understand the relationships between the different entities in those services. I worried that without that model, we’d get ourselves tangled up really quickly.

So I brushed up on my theory1 and got to it. First, the obligatory definition:

[An] entity–relationship model (ER model) is a data model for describing the data or information aspects of a business domain or its process requirements, in an abstract way that lends itself to ultimately being implemented in a database such as a relational database. The main components of ER models are entities (things) and the relationships that can exist among them.

This is a tool that’s primarily used as the first step in relational database design. But I found it really useful for us to define the constraints within which we could create user flows. Let me explain with an example. Here’s a simplified version of the ER model we came up with for this project (using Crow’s foot notation):

Each color represents a different back-end service. Here’s a subset of what the diagram tells us:

• A team can have multiple tasks, but each task can only be assigned to one team.
• A task can have multiple files associated with it, but each file can belong to only one task (or team).
• A person can be part of multiple teams, and a team is made of multiple people.
• There is a 1:1 relationship between teams, tasks, files, and the conversations about those entities.
• Outside of those relationships, a person can be part of multiple conversations, and a conversation can consist of multiple people.

If all this sounds a little bit boring, I hear you, but here’s the power of this diagram: it ensures that whatever UI we come up with serves the underlying entity relationships, and not the other way around. This is huge. For example, if we started with the UI we might say that users can attach files to a task or project within the product’s main interface. But since a 1:1 relationship exists between Conversation and File, it means we can also attach a file to a task by dropping it into the Conversation view of that task. The relationships help us to come up with the most useful and robust UI.

What essentially happens if you start UI design with an ER model is that you create the boundaries of what’s “allowed” in the UI. It pushes you to think up useful ideas without the danger of coming up with something that wouldn’t work in the final implementation.

I don’t think ER models should be the starting point of every project. But in certain specific cases where many disparate products or services need to come together it’s proved to be really useful.

And now, on to journey mapping…

---

1. Ok fine, I read the Wikipedia article. ↩

Kate Heddleston makes some great points in The Null Process:

When people say they don’t want process, what they’re really saying is they don’t want formalized process. There is really no such thing as “no process.” A process is simply the steps it takes to complete a task, so if a task is completed then by definition a process was used. Without formalized process everyone does things their own way, and there is no documentation for how problems are solved. This informal, undocumented process is the “null process,” and, if used incorrectly, the null process can have major implications for a company.

This reminds me of two things. The first is Rebekah Cox’s definition of Product Design:

Design is a set of decisions about a product. It’s not an interface or an aesthetic, it’s not a brand or a color. Design is the actual decisions.

What this implies is that everything you do in product design has a consequence. So just “letting things happen” is also a decision. It’s just a pretty bad one. Maybe that should be called “null design.” I don’t know, I’m not good at naming things1.

The second is Michael Lopp’s The Process Myth. The whole thing is great, but this quote in particular has always stuck in my mind:

Engineers don’t hate process. They hate process that can’t defend itself.

Also this advice:

Healthy process is awesome if it not only documents what we care about, but is willing to defend itself. It is required to stand up to scrutiny and when a process fails to do so, it must change.

For more reading on what it takes to build good processes (because let’s be honest, what else are you going to do on a Friday night?), I recommend Adam Wuerl’s Avoiding Process Hell and Jeff Gothelf’s Applying Product Thinking to Process Improvement.

---

1. Just look at my URL. Seriously, what was I thinking. ↩

Shaun McCormick describes Why the way we look at technical debt is wrong:

Technical debt is ok, and often a solid product strategy. The importance is getting to market. When launching a new system or feature, focus your effort and time on areas of the product that need to be agile, and move quickly through areas that don’t. Later, if the product proves that it can drive revenue, you can revisit those areas and improve if they need to scale.

This is an excellent sentiment, and I agree 100% in theory. The problem is that in most organizations, “later” = “never.” Or as Jeff Gothelf puts it, the biggest lie in corporate america is Phase 2.

That’s why I really like Henrik Kniberg’s concept of a “technical debt ceiling.” Read his post Good and Bad Technical Debt (and how TDD helps) for the whole explanation, but here’s a diagram that explains his point:

Source: Henrik Kniberg

This forces teams to pay attention to technical debt, and make a conscious effort to reduce it when it becomes a problem.

An interesting counter-argument to the #noestimates movement—and a call for reasonable software development estimates—on the Clever PM blog1. From In Defense of Estimates:

From a business perspective, some level of estimation is absolutely required, so that judgment calls can be made as to priorities of execution and communications within the company and to customers. We need to have some level of understanding of whether something is “bigger than an elephant or smaller than a breadbox” so that we can deploy other parts of the organization appropriately. “It takes as long as it takes” is not useful for tactical or strategic planning within any organization.

---

1. It’s kind of hard for me to link to this. First, there’s no byline, and I’d love to quote the author by name. Also, wow, that stock image… ↩

Marty Cagan continues his excellent product autonomy series by discussing what happens when teams get large enough to split up their code bases. In Autonomy vs. Ownership he describes his preferred way of dealing with the situation where a team needs a change in a different codebase to get one of their features implemented:

The alternative model is informally known as the “open source” model although to be clear this is not about open sourcing your code, it’s just called that because this is how much of the open source community operates. In this model, if the drivers team needs a change to the riders team’s code, then they could either wait for the riders team to do it, or they can actually make the change themselves, and then request that the riders team review the change, and include it if they’re okay with it (known as a “pull request”). This means that you are telling the software management system that you’ve made a change to the software, but the owner of that software needs to review the changes before they are actually approved and incorporated.

Judy Wajcman’s Who’s to blame for the digital time deficit? starts off like many similar articles as she ponders the role smart phones play in making us feel time-starved. But then she takes an unexpected and well-reasoned turn:

If technology is going to contribute to a better world, people must think about the world in which they want to live. Put simply, it means thinking about social problems first and then thinking of technological solutions, rather than inventing technologies and trying to find problems they might solve.

We can’t do this while the people who design our technology and decide what is made are so unrepresentative of society. The most powerful companies in the world today—such as Microsoft, Apple and Google—are basically engineering companies and, whether in the US or Japan, they employ few women, minorities or people over 40. […] Such skewed organisational demographics inevitably influence the kind of technology produced.

And later on:

If we want technology to bring us a better future, we must contest the imperative of speed and democratise engineering. We must bring more imagination to the field of technological innovation. Most of all, we must ask bigger questions about what kind of society we want. Technology will follow, as it usually does.

Charles Fishman’s They Write the Right Stuff is an incredible profile of the engineers who write software for NASA’s space shuttle missions:

How do they write the right stuff?

The answer is, it’s the process. The group’s most important creation is not the perfect software they write — it’s the process they invented that writes the perfect software.

It’s the process that allows them to live normal lives, to set deadlines they actually meet, to stay on budget, to deliver software that does exactly what it promises. It’s the process that defines what these coders in the flat plains of southeast suburban Houston know that everyone else in the software world is still groping for. It’s the process that offers a template for any creative enterprise that’s looking for a method to produce consistent—and consistently improving—quality.

The article goes on to explore the four propositions that underly everything this team does. Also see if you can spot what’s different about their working hours…

Jessica McKellar gives some fantastic career, management, and leadership advice in This Is What Impactful Engineering Leadership Looks Like. The interview goes into detail on three main areas:

“When engineering management is done right, you’re focusing on three big things,” she says. “You’re directly supporting the people on your team; you’re managing execution and coordination across teams; and you’re stepping back to observe and evolve the broader organization and its processes as it grows.” 

Even though the interview is focused primarily on engineering teams, it’s applicable to all types of leadership and management. Highly recommended.

Rune Madsen wrote a really interesting post on how our design methods need to change when we work in software (as opposed to print). He explains in the post On meta-design and algorithmic design systems:

So what is meta-design? In a traditional design practice, the designer works directly on a design product. Be it a logo, website, or a set of posters, the designer is the instrument to produce the final artifact. A meta-designer works to distill this instrumentation into a design system, often written in software, that can create the final artifact. Instead of drawing it manually, she is programming the system to draw it. These systems can then be used within different contexts to generate a range of design products without much effort.

I’ll add my vote for the need to spend much more effort on design systems (like Atomic Design) upfront, to standardize (and eventually speed up) later development.