Best User Interface Ever

I've just found the best user interface that has ever existed. It's a single button that does exactly what you want it do when you press it, there are just a few catches:

* You have to be a toddler
* It only works for radio controlled toys
* You have to want the toy to run around, and not particularly care where it goes.

Thankfully, this is for toddlers - who never care where a toy goes as long as it keeps going, so this is perfect!

What makes it so perfect is that the simplicity of the interface ensures that the toy basically never gets stuck in corners or under things. It transparently enforces a pattern of movement that gets you out of nearly anywhere!



So, how does it work? Well the toy only has two states

A) Going forward
B) Reversing in a clockwise circle.

If you hold down the button you go forward, once you let it go the toy reverses backwards. As a toddler this means that as long as I hold the button down (While yelling with joy) the toy goes forward, as soon as I get disappointed because it hits a wall, or wedges in a corner it reverses itself out.

In the worst situation if its really stuck I get angry because it's stuck and start pressing and then releasing the button (Which is what toddlers do by instinct) then I've done a three point turn and am out of trouble.

Best. Interface. Ever.

This interface is:
1) Appropriate to the user
2) Does what it needs to
3) Encourages the correct behavior in error situations
4) Doesn't get in the way of the experience

If I ever design a UI half as good as this for an IT system I will have done well.

This is the iPod shuffle of children's toys.

Even the device itself is simple, you can see below how the axle is housed in an arc so as long as its going forward it's straight but reversing immediately swings it around.

What sort of "consultancy" are you?

The word "consultancy" gets thrown around a lot and covers some very different organisations and value propositions. These range from just a few people sharing business-cards to true though to McKinsey.

1. Body Shop
At this stage you are just an outsourced agency to find contractors for clients. There are no real relationships between people on client sites it's just an volume game. The value proposition is just out-sourcing your interviewing and trawling through resumes.

2. Bunch-o-Mates / I know a guy..
At this stage one or two key senior people work as contractors out on client site, and bring in their friends and ex-colleagues to the same site. There's no real sales function it's all done through one-on-one relationships. The value proposition is a pre-assembled team of high-quality people.

3. Ad-Hoc Delivery / Hands & Feet
Once your bunch-of-mates hits a certain level of sophistication you can start to out-right own delivery of certain functional projects using whatever methods and IP is already used by the client. Commercially this is when serious profit and risk start to occur. Most organisation that delivery like this rely on one or two "heroes" (normally the owner) to actually deliver and manage client relationships.

4. Repeatable Delivery
Once you've gone through a few delivery cycles you actually start to know a thing or two about what you're doing. At this point you have the methods, IP, and embedded practices to actually reliably repeat delivery of similar solutions. At this point the founder starts to be less involved in the day-to-day and can probably start calling yourself a consultancy with a straight face.

5. Domain Expert
Knowing how to do it internally is great - but being able to pass that knowledge onto other is even better. In the Sydney market PlanIT for testing and Object Consulting for system modelling embody this trend well. Once you have a strong reputation you become sought out first for smaller consulting gigs to improve practice at clients, then as a plain old trainer.

6. Trusted Adviser
At this stage when you say no to your client they stop and listen and your ideas are incorporated into the heart of your clients strategy and execution. You're a trusted source of option and options in your domain or beyond. Congratulations. You don't need to be McKinsey, even if you're just a trusted adviser of a specific domain like data warehouses or mail-rooms that's a great achievement.

(Got some ideas from here while goggling good examples of trusted advisers)
http://onstartups.com/tabid/3339/bid/1699/Startups-Are-You-A-Trusted-Adviser-Or-A-Responsive-Assistant.aspx

Reports for people not databases

Collecting reporting requirements needn't be a boring experience. Too often we try and specify lots of functional detail about the report that doesn't really help instead of concentrating on what's most important. That's why I use user stories to document the reporting stakeholder requirements as well. Just use the following form:

• As a report consumer
  
• I want to know the answer to some questions
  
• So that I can make some decision and take some action
  

The crucial piece of information is how people are going to use the report, what value it adds, and what will be done as a result of the information it contains.

This is the basis of your design, if you get this right the form design flows naturally, if you get it wrong no amount of detail in the report specification is going to save you.

Your reporting requirements shouldn't be relegated to some technical back-water. Theses reports are often the widest public interface to your application, and often the view that the most senior users of your application will see.

If you're willing to put in the effort to separate problem elicitation from solution definition for your functionality, you should be willing to do the same for your reporting.

P.S. Getting your logical model right is an absolutely necessary pre-requisite to the functional design. If you don't get that right your're bound to fail.