Building simple, usable interfaces, architectures and products

I've recently finished reading a fantastic book: Simple and Usable. It's best read as a physical book, due to the stylish, magazine layout of text and full-page pictures. It's easy to read, but thought provoking. Concrete steps describe how to improve a user interface. These steps are easy to understand, but will no doubt require discipline to apply correctly.

Although each page offers a tasty morsel to digest, one page (76), entitled Solutions, not processes, jumped out at me. It asked the question: is there another way to solve this problem? I had recently read the very same words, in this architecture check-list, and they were then echoed again by Michael Dubakov's insightful article on Product Owners as a SPOF.

So often we rush to produce a solution, without considering the alternatives. Our team is currently trying to scale out and speed up in a big way, so we're focussing hard on optimising cycle-time. Despite the diversity of these articles, they all provide a clear reminder to not rush the creative process that leads to the best solutions. Don't rush it, but still optimise it - that's the challenge.

If you're a skilled User Interface Specialist that would like to be part of this challenge, please get in touch - we'd love you to join our team!

Leadership advice from Bear Grylls - Facing the Frozen Ocean

For more on the book visit Amazon. Picked up a copy from my local library as it was the only title by Bear Grylls they had. Having heard a bit about this chap I wanted to learn more and was blown away by this book.

As well as being a gripping read, it contains sound advice on building and leading a team. The problem Bear set out to solve was the crossing of the North Atlantic in an open boat (a RHIB). Points of note were:

• The team he assembled had the required mix of expertise, but instead of seeking out the very best in each field, Bear looked for people who were passionate about achieving his goal and excellent team-players.

• Bear took a pure leadership / management role in solving the problem: he left the team use their own skills to solve problems to the best of their ability. He "merely" made strategic decisions and more importantly served the team as a servant-leader whenever possible.
  

QCon 2007 - References to follow up on

Various resources that I haven't got round to looking at yet, but are worth doing sooner...

• Behind closed doors - people management
• Don't make me think - user interface design
• Maverick - business management
• How buildings learn - architecture
• thinktecture.com - resouces for WCF
• fitnesse.org - web based acceptance test framework