The more things change . . .forget that, Thermo rocks!

I am in a place and time in my career where I can look back to what I have done and look forward to what I might be doing. The pendulum has swung from main frame (thin client) to client-server (robust client) back to internet (thin client again) and back again to desktop (robust client).

I remember how great Visual Basic (in the client-server days) was in visualizing interface real time and quickly getting feedback. When I started working in the Internet in 97-98, the tools were a real step backwards from a UI standpoint.

In the last year or so, using Adobe Flex, we once again are at the level we were back in the early 90's. Now I am not talking about the uber-techno folks or the graphically inclined designers. I talking about the people like me. We know a bit technically but are more visual requirement type people who are not color blind (but in my case just have bad taste ;-).

Now, I thought things would be somewhat the same, then I saw the Thermo preview at the Max conference, it really blew me away. This tool will change the face of UI creation / prototyping. We have a new ball-game.

I can take an idea, which is presented visually and make it a prototype in less than an hour. WOW. This will allow for some very quick validation for all types of prototyping (Concept, Design and Production).

I can't wait to get my hands on it.

A process by any other name

There are so many different development methodologies out there. I have worked with 3 steps and 4 phases and 8 cycles and 33 flavors. This does not include agile and user-centric methodologies. The names are changed to be unique and meaningful to those using the methodology and confuse those of us that need to work with more than 1.

When I was at EDS, I had to map the EDS 8 step System Life Cycle with the GM 4 phase System Development Process. They mostly matched up, but it took 6 months to get agreement.

I boil everything down to 3 buckets when laying out a project. Why are we doing this. What are we trying to do. How will it get accomplished. Another way to look at it is Think - Plan - Do. "Think" has been and could be called Phase 0, Discovery, Strategy, Concept or a Project Brief. "Plan" is answering the whats and developing "enough" detail to move on. "Do" is implementing the solution.

I will go into more detail for each of these in the coming days.

Are incremental and iterative the same?

Do sometimes we get confused with the terms Incremental and Iterative? They are not interchangeable although sometimes they are used that way.

Incremental is when we add an additional piece of function to an application without necessarily changing the already existing code.

Iterative is when we create a new version of an existing application that includes feedback or requirement changes from the previous version or iteration.

Why does this matter? Some development methodologies call themselves iterative when they are really incremental. This can be confusing, especially when your are also doing prototypes.

Prototype - What is in a name?

When we say prototype, are we saying visualization? Most of the time the answer is yes. I think there are 3 types of prototypes at 3 different places within a process.

1. Interactive Concept - Reality = 0%

• To show proof of concept
• Lots of ideas, need to visualize to see what works
• Very thin and quick to create
• Sales tool to sell an idea
• Early concept phase
  

2. Design Validation - Reality = 50%

• To allow user feedback
• Many ideas narrowed to one or a few
• End of concept or start of design phase

3. Pre-production - Reality = 99%

• Technical foundation leading into implementation
• Maybe an evolution of an early prototype, maybe not
• End of design phase before implementation

Leaving MS to change the world

I read a book that is really making me think. It was by John Woods and is called "Leaving Microsoft to change the world".

A former Microsoft executive used his entrepreneurial skills and built a non-profit that changed the world. His organization, Room to Read, built 5000+ libraries, schools and computer labs and gave scholarships to thousands of girls.

They way he built the organization and developed the financial support was very innovative. I also liked the focus and process he developed.

Take a peek, what do you think?

Use Cases for Process

What if we took a use-case approach to defining our design and dev processes? Would that give us a different perspective of how we would like to work?

Sometimes a use-case needs to be documented in text. Other times a workflow does the best. And in still other cases, would a prototype be more appropriate? When something is very well understood, do you need to textually define it or can you just build it?

A nomenclature (meta data) for a use case seems also to be a needed thing. Some are very finite others are at a high level. Some are self contaned (can be completed in one-sitting) others are extended across time and multiple steps.

Use-cases should be able to be used for products as well as software. Anything requiring user-interaction, could use use-cases as a tool.

Xd for process

When we think about eXperience Design, we often are thinking about an application and how a user interacts with it. How would it look if we take Xd methodogies and applied them at the process level?

One of the most successful examples that comes to mind is iPod - iTunes - iTunes Store. The experience is fully realized when you bring all three together. Each on its own has been executed well but would each be as successful without the others?