Information architecture

Did you map out all the concepts, objects, structures, their properties, action they can perform or receive, and the relationships them? Have you share this modeling with your engineers? Does your design reflect the information architecture?

Stock

Did you seek how the design will impact the existing product? List the key user journeys impacted by the problem.

Real data

Did you fill your design with data from the real world? See if the data exists, and what kind of values it actually takes. Make sure the design works with 0 data or a lot of it.

Error cases

All possible error cases must be handled explicitly. What happens if the user makes a mistake? …

Talking to users is one of the highest-leverage activities an organisation can invest in, but is also difficult to get right.

This is a one-stop-shop introduction to the fundamental principles behind good user research.

Why it’s so important to get research right

You are not the user

We often assume, without realising it, that everyone thinks like we think and likes what we like. Generalising based on our own experience is actually a cognitive bias called the availability bias.

Designers and business leaders must fight this bias by interacting as much as possible with users.

People don’t tell the truth

But there is a catch. Talking to users does not automatically yield useful insights, and very often can lead in the wrong direction. Users don’t purposely lie to us, but things people say are different from things people actually do. …

“I feel great ! I have a fantastic team working with me now. […] It’s all because I have a team of A players.”

This is my summary of Who: The A method for recruiting by Geoff Smart and Randy Street.

The “A” method for recruiting

• Make a scorecard for the position
• Source candidates
• Select a candidate
• Sell the job to them

1. Scorecard

The scorecard is what you seek: the mission, the outcome and critical competencies.

The mission: An executive summary of the job purpose. = why you need to hire for this role. Example: “Double revenue over 3 years by signing large contracts with industrial customers. …

Domain-Driven Design is an approach to software development based on making your software deeply reflect a real-world system or process.

“Domain” in Domain-Driven Design officially refers to a “sphere of knowledge and activity around which the application logic revolves”. In other words, the “Domain” is what is commonly referred to as “business logic” in the software world.

In Domain-Driven Design, business logic is considered to be the heart of the software.

You’ll find in this article an introduction to Domain-Driven Design that mostly follows what is explained in Eric Evans’ book. …

At Inato, all our web apps are contained in one monorepo (front-end apps, APIs, …). We use yarn workspaces to manage all of these packages.

To host and run our apps, we use Heroku.

The standard Heroku setup only works for the 1-app-1-repo use case.

So, here is a quick guide on how to host and run multiple apps from multiple yarn workspaces contained in a single Git repository on Heroku.

Disclaimer: this guide assumes a basic knowledge of Heroku (See Getting Started).

Let’s say you have a single Git repository containing multiple applications in yarn workspaces like so:

.
├── package.json
├── packages
│   ├── web-client
│   │   └── package.json
│   └── api
│       └── package.json
└── scripts
    └── heroku.build …