Last week our whole company got together. We try to do this a few times a year. We fly everyone in and all spend a few days together in Chicago. We share what we’re working on, we talk, we debate, we review, we get some work done, and we have some fun.

Usually we reserve one of the nights to all go out to dinner together, but this time we decided to host some of our Chicago-based customers at a party at our office instead. We invited about 50 customers – some new, some old – and all hung out for a few hours. We met, exchanged ideas, fielded feature requests, and just got to know each other. Everyone had a great time. Thanks to everyone who came.

We put together a little video to share.

Special thanks to Steve Dale from Gyro, Jimmy Spencer Jr. from Love Without Agenda, Ray Hightower from Wisdom Group, Ben Greiner from Forget Computers, and Michael Carney from MWC Accounting for taking some extra time to be interviewed on camera.

Today we’re introducing LinkedIn profiles in Highrise. You can now add LinkedIn URLs to your contacts to see their profiles in Highrise instantly. You’ll have easy access to all the specialties and qualifications listed in their LinkedIn profiles.

How to set it up

It’s simple: Just go to a contact, click the “Edit” link in the top right corner, then scroll down to the “Social media” section on the edit screen. Enter the person’s public LinkedIn profile URL and click save. Then you’ll see a “LinkedIn” tab at the top of their contact page. Click that link and you’ll have access to their LinkedIn profile.

To make the most of this feature you’ll need to have an account on LinkedIn. Highrise uses your LinkedIn account to grab the latest profile each time you view one of your contacts. This ensures the profile information you see is always up to date.

Integration with LinkedIn has been a popular customer request since we launched Highrise. We’re pleased to make it a reality today and we hope it makes Highrise more useful to you everyday.

Last month the folks from PeepCode visited our office and asked to record my design process. Geoffrey told me not to prepare anything. He said he’d show up with a sample problem and simply record whatever I did with it. The result is two 75-minute videos (Part One, Part Two) that show my thought process step-by-step, starting with paper sketches and then moving on to HTML/CSS.

The hard thing about demonstrating design is the sample problem. The problem should be simple enough that the details don’t bog down the audience, but complicated enough that you run into real-life conflicts and constraints.

Fortunately Geoffrey picked a really good sample domain. He asked me to design a UI for picking the top five finishers out of 200 participants in a pro bicycling race. The task was rich and interesting enough that we spent the first 75 minutes purely sketching and analyzing the approach.

The first video, Part One, covers the sketching process. A lot of good material came out of this section, including:

• How to tackle a UI problem by dividing it into tasks that each have a beginning, middle and end
• How to use sketching as a response to uncertainty, and when to stop sketching and move on to HTML
• How to focus on the most natural solution so that people will intuitively grasp a design
• How to focus your design process on conflicts and friction points, attacking them one by one until the design works

This video also gave me a chance to explain the UI design process through an analogy to software testing. Kent Beck’s Test-Driven Development had a huge influence on me, and I’ve always had trouble explaining the connection. In both videos I continually refer to setting up “tests” — specific things in the design that aren’t working or aren’t resolved — and then design against those tests until they “pass” (that is, until the problem goes away). This loose analogy articulates that tricky and hard-to-pin-down process where a designer continually moves their focus among pieces of a problem and along the way settles conflicts step-by-step in a constructive sequence.

I think the process will be interesting to both designers and coders. Designers can compare the process to their own, while coders can use the analogies to software testing to see design as an extension of concepts they already know.

In the second video, Part Two, I take the sketches and ideas from the first session and build them out in HTML and CSS. Along the way I dip in and out of Photoshop, explaining the time and place for each tool.

Part Two especially focuses on getting quick results in the browser. I sketch out dom elements, give them classes to communicate their purpose, and gradually decorate them with inline styles until the design comes together in the browser.

I would prefer videos like this to be free. But Geoffrey had the idea to begin with and his PeepCode team did all the hard work. I just showed up one Friday morning for a couple hours of design practice. So if the material is useful to you I hope you’ll support their effort and buy the videos at $12/each.

Here are the links:

1. PeepCode Play by Play: Ryan Singer Part One
2. PeepCode Play by Play: Ryan Singer Part Two

There’s also a 10 minute preview on the Part One page.

I hope they’re useful!

Our support team works hard every day to make our customers happy, and we’re always proud to show how great a job they do.

In addition to making customers happy, our fantastic team also answers questions fast. Across the last 500 new cases we’ve received during our normal hours, we’ve responded to 97% in less than hour, with the average case answered in 14 minutes and solved in 25 minutes.

Our team has been steadily improving at this too. Over the last few months, we’ve steadily cut down response times, all while maintaining or improving customer happiness.

Congratulations to Michael, Ann, Kristin, Merissa, Joan, and Chase!

I’ve been thinking more about how I review a design – both my own and someone else’s. So over the past couple days I’ve been writing down every question I’ve been asking when I look at a design-in-progress. Some of these I say out loud, some just go through my head, some are in person, others are posted to Basecamp or Campfire.

These are in no particular order, and I don’t ask all of them every time.

• What does it say?
• What does it mean?
• Is what it says and what it means the same thing?
• Do we want that?
• Why do we need to say that here?
• If you stopped reading here, what’s the message?
• What’s the take away after 8 seconds?
• How does this make you feel?
• What’s down below?
• How else can we say this?
• What’s memorable about this?
• What’s that for?
• Who needs to know that?
• Who needs to see that?
• How does that change behavior?
• What’s the payoff?
• What does someone know now that they didn’t know before?
• How does that work?
• Why is that worth a click?
• Is that worth scrolling?
• What’s the simpler version of this?
• Are we assuming too much?
• Why that order?
• Why would this make them choose that?
• What does a more polished version of this look like?
• Why would someone leave at this point?
• What’s missing?
• Why are we saying this twice?
• Is it worth pulling attention away from that?
• Does that make it clearer?
• What’s the obvious next step?
• How would someone know that?
• Would it matter if someone missed that?
• Does that make it easier or harder?
• Would this be better as a sentence or a picture?
• Where’s the verb?
• Why is that there?
• What matters here?
• What would happen if we got rid of that?
• Why isn’t that clear?
• Why is this better?
• How can we make this more obvious?
• What happens when this expands?
• If we got rid of this, does that still work?
• Is it obvious what happens next?
• What just happened?
• Where’s the idea?
• What problem is that solving?
• How does this change someone’s mind?
• What makes this a must have?

“Can you ask Sam about that? Stacker is his domain”, “I’d rather let Josh look at the router, he wrote it”, “Jon is better versed in associations, send it to him”.

The natural progression of programs is towards the territorial. When a programmer has weaved an intricate web of considerable complexity, others are loathe to enter his lair and he is loathe for them to do so.

This is despite the fact that we all agree that it’s bad for programs to become territorial. When only one or a few people know how to work on something, you get bottlenecks where progress is stunted until the master is ready. You risk the hit-by-a-bus factor where nobody knows how the system works if the master leaves. You ensure the annoyance of stakeholders who can’t understand why another minion can’t fix his urgent problem.

But this problem can’t be solved with a slogan. You can proclaim that “we shouldn’t have territorial parts of our program” until you turn blue, but nothing is going to change until you accept the cost of avoidance.

The first step of acceptance is to recognize that sending someone fresh in to fix a single issue in a complex part of the code is expensive. It’s going to take Pratik five to ten times the effort to fix a single issue in Stacker that it’s going to take Sam. And the odds are that even that is not enough to appreciate the internal coherency of the system, which means that the fix is likely to be a butcher’s job, and Sam will have to rewrite it afterwards anyway.

To broaden the base of knowledge, you’re going to have to let someone else not only spend considerable effort getting up to speed. Then you’re going to have them deal with more than just a quick fix. Let them deal with a raft of issues and let them spend the time of the original creator to learn it all.

To do all that, they can’t do anything else at the same time. That feature you want do is now going to be pushed a few days or a a week out. Until you’re ready to delay things you really want done, it’s fruitless to bemoan that parts of the code base territorial.