Domain, data, or UI modeling?

Creating  UI mockups with Balsamiq Mockups

From “Domain Modeling or Data Modeling“:

Users do not care “objects”. They care UI, and the fact that the data on the UI are saved in databases. So, by definition, UI and the key data are the “business language”; objects are not.

I have seen the value of domain driven design, but my style lends itself mostly to UI modeling using mockups. This is probably a result of my upbringing: I’m not a trained computer programmer!

For me, user interface mockups are the most effective way to communicate concepts and start building an application. Normal business people (that is, everyone except computer programmers!) respond to a visual and interactive UI in a different way than an abstract object/data/domain model. UI mockups can be easily understood by any user, which improves feedback.


Stop the email!

Some days I get over a hundred emails. Often, 90% of those are a waste of my time, and that is after excluding junk mail and related marketing mumbo-jumbo. Why so much email fluff, not-quite-spam-spam? It’s because people don’t consider the human cost of sending an email.

The Email Cost Algorithm

To understand the productivity cost of an email, we need to consider the factors that go in to an email, and how they correlate to time.

First, some facts and assumptions regarding email reading speed.

Second, some facts and assumptions about email writing speed.

Third, we’ll present some ancillary facts.

You can take your best guess as to how much time email takes up based on all that information. My back-of-the-envelope guess is that the average worker will spend about 30 minutes a day composing email, and 30 minutes a day reading email.

That being said, how do you avoid wasting people’s time with email? By knowing when you should and should not send an email.

You should always send an email when:

  • It is after hours, there is no other way to get in touch with someone, and you must make sure they received information from you at a given time. (Example: A client wants to know that their server is back online. You bring it online at 4AM. Send them an email, unless they explicitly told you to call them and wake them up.)
  • You need a record of your correspondence or need to maintain an audit trail that can be used to prove (or disprove) facts in the future.

You should sometimes send an email when:

  • You need to send a file or files to one or more people. Before sending, consider other solutions, such as YouSendIt, ShareFile, or 2Large2Email, to send your files.
  • You are sending information to an large number of recipients and have no more efficient way to communicate to them. (Example: Your company has no intranet and you need to distribute a new HR policy. A better solution than email is to hire a web development company to build your intranet, then post the HR policy on the intranet.)

You should never send an email when:

  • Typing the email takes longer than picking up the phone, dialing a phone number, waiting for someone to answer, and saying what you need to say.
  • You are sending an email to people who don’t need to read it. If a recipient isn’t expected to provide feedback to your email, and the recipient doesn’t have a need to know the information contained in your email, they don’t need to receive it. In other words: carefully review every recipient in the To: and Cc: fields; if they don’t need to know, don’t waste their time.

Remember — if it isn’t important, don’t waste someone’s time with it; and if there’s a faster way to do it, do it the faster way.

Quote: How to manage a client’s expectations

How to manage a client’s expectations:

It’s not about bending over backwards for the client. It’s about making the client think your bending over backwards when you’re not bending at all.

Not sure if I heard that from someone else or made it up myself, but I’m sure I learned it from someone much smarter than me!