Saturday, October 31, 2009

Breakthrough on turning ideas into splash pages

I had an amazing day, yesterday. Met with another entrepreneur to work on a new project. For the first time in my life I was an active contributor on the creative side of the process. He had many creative ideas for this product which is geared toward the Indian matrimonial process. I was able to listen and synthesize graphic images to test the different ideas.

I cranked out logos, logos with gradients, different colors, sizes, letters kerned. Then we looked for imagery around Indian weddings. Grabbed examples and synthesized images to go on the splash screen. We ended up here:



Still not finished, but the experience of being able to finally work productively with graphical tools such as Photoshop and Fireworks was exquisite. The breakthrough book for me was, Layers: The Complete Guide to Photoshop's Most Powerful Feature .

I tried to take a chapter a day and work through the examples using the images he shows in the book. It is small (a great attribute in my opion) and instead of trying to describe every feature he sets out to build useful workflows for the majority of work.

It also requires some CSS knowledge to lay out the images on the page which I had built up over the last year. The feeling of cranking directly on what the user sees is great. Combine that with the ability to code the backend and test rapidly using splash screens, I think I am getting close to having a toolset for trying multiple ideas over the next year or so until I find one that sticks.

Sunday, October 18, 2009

Managing queues can make a big difference for product creation

I read a book called The Principles of Product Development Flow. I do not recommend this book for the casual reader. It is filled with math and graphs, but the ideas are pretty interesting and very applicable to startup entrepreneurs.

My first question when I am reading about something new is, how can I apply this to give myself an advantage in whatever I am working on? So I called up a friend of mine that is working on delivering web sites to small and medium businesses.

I launched into the central idea: how long it takes you to get individual projects finished and out the door determines how quickly you see the economic benefits. The studies and math show that the closer you get to 100% utilization of each developer, the longer each item waits in that developer's queue being blocked by other projects.

When the project depends on different people, then queue size can really slow down getting anything finished. Unfinished work doesn't make you or anyone else money. In web startups many people are involved in developing a new idea or feature: creative art, layout, browser code, server code, and database work to name a few. If each person that needs to work on the idea is scheduled to be busy 100% of the time, then total time to finish any single project goes up dramatically.

The counter intuitive answer is to have more idle time. That way when the high priority work comes through it gets done immediately by each worker. Being busy all the time equals not having time to push through critical items in a timely manner. Also choosing wisely the work with the highest economic payoff or greatest risk reduction has a huge impact. The group has to understand this or they won't work on the most important projects leaving projects waiting.

Another key idea is what the author called cadence. This means if there is some part of the project that requires a group decision, having a regularly scheduled meeting that is automatic makes the overall progress faster, as you don't have to wait for everyone to schedule infrequent meetings. This sets a tempo for getting work done. Otherwise more features get crammed onto a release which things makes the release recede into the distance. This is also counter intuitive, as you would think regular meetings would slow down things. This is one reason daily releases can work, as they set a regular tempo for pushing out work.

So my friend and I started discussing these ideas. Immediately he started rethinking his business. He had been focused on having 100% of his hours booked. This led to lots of projects that are not totally finished, which means he can't get paid. Now he is approaching clients with a new proposition. Blocking off a definite time frame to start and finish the work for a better rate. He gets better cash flow and the client gets the project finished so they can realize the economic effect. He is even thinking of charging more if the client slows down the turnaround thus gumming up his project completion time.

He has been doing this for 2 weeks and starting to see happier clients who want to do more business with him and a fatter bank account. It is unusual when you find a book that seems written for huge companies and realize that it also applies at the startup scale.

Monday, October 5, 2009

How an engineer started learning more about design

I had someone ask me what path I have been following while learning design. Like any engineer I started by breaking down the problem into components so I could tackle them individually.

1.) Where to start: first problem was the classic chicken and egg issue of tool versus techniques. I didn't know any design / graphics tools because I wouldn't know what to do with them. Then I didn't bother learning any design principles because I couldn't implement anything without a tool.

2.) Tools: I decided to start with Adobe Fireworks / Photoshop. Feel free to substitute your own tool here. I read through a basic book on how to use these tools. I tried not to get too hung up on specifics, but focused on learning enough so that I didn't freeze when opening either of them up.

3.) Design Basics: a couple of books by Robin Williams (not the comedian): The Non-Designer's Design Book and Design Workshop. What is great about these books is that they focus on basics, such as, alignment and contrast. Just by becoming more conscious of 5 or 6 principles, I saw an immediate improvement in my work.

4.) Typography: The Designers Type Book (also by Robin Williams), Mac OS X Fonts, Mac is not a Typewriter. Again substitute an equivalent for the PC if that is your platform.

5.) Color: Guide to Communicating in Color and Color Design Workbook. These just explain basics about how color communicates with users.

6.) Layout with: Making and Breaking the Grid.

7.) Usability (which is different than design), such as, Designing Web Usability and Don't Make Me Think.

8.) Interfaces: Designing Interfaces and Designing Web Interfaces.

They key is to set a pace and not get discouraged. It is all about getting better than you currently are and developing a vocabulary so you can communicate with designers better. I know find that I have a much better idea of what the design process is and am less frustrated when working with top notch designers.