With today's ever advancing technologies—better tools, frameworks, libraries— software/web development is becoming increasingly faster in many regards. Yet in large companies, the processes for designing, developing and deploying software/web products remains cumbersome. To a great extent, the processes have remained the same for nearly a decade, and are very slow. On the other hand, smaller companies (startups) are able to go from inception to deployment in very little time. They are able to iterate and experiment with new features sometimes on a daily basis. Can large companies learn from small company processes, and vice versa? Kalani Kordus and Karl Adam will juxtapose their large company (yahoo!), large team experience with their small company (smudgeproof), small team adventure. Their current design/development process—a mashup of traditional and progressive techniques—is akin to musical improvisation, Dirty Jobs and UFC cage fighting.

1. Kalani Kordus Karl Adam
Designer & CCO Engineer & CTO
@kalkor @thekarladam
Interaction Eleven • Feb 9-12, 2011 • Boulder, CO

2. DESIGN
ENGINEERING
QUALITY ASSURANCE

3. DESIGN
ENGINEERING
We will use Yahoo! Messenger for
iPhone and Symposium as case studies
to juxtapose a large company (Macro)
QUALITY ASSURANCE
software development process with our
(Micro) software development process.
These projects were similar in scope.
Yet, we were able to design and develop
Symposium at a much faster rate.

4. DESIGN
ENGINEERING
QUALITY ASSURANCE
The Builders

5. DESIGN
ENGINEERING
QUALITY ASSURANCE
Each builder reports to a manager who must approve at different
stages of the process. They are similar to valves in a plumbing system;
regulating the flow of things. Most of management are not builders
anymore because their time is spent having formal meetings with
other managers and executives.

6. PRODUCT DESIGN
RESEARCH
MARKETING ENGINEERING INTERACTION DESIGN
VISUAL DESIGN
PROTOTYPING
ENGINEERING
QUALITY ASSURANCE
PROJECT MANAGEMENT
MARKETING
PRODUCT
QUALITY ASSURANCE
Product Managers are invited to all meetings. Marketing attends all
milestone meetings; both act as additional valves to the process.
Roles tend to be very specialized in large companies. In contrast, small
companies are forced to wear more hats out of necessity.

7. PROCESS
DESIGN ENGINEERING
PRD
Alpha Beta
/Triage /Triage
IDEATE ARCHITECTURE IMPLEMENT
SKETCH IMPLEMENT TEST
WIREFRAME TEST ANALYZE
MOCKUPS ANALYZE
SPECIFICATIONS
= MILESTONES

8. PROCESS
ENGINEERING
Beta GM Deploy
/Triage /Triage
PLEMENT TEST TEST
TEST FIX BUGS
NALYZE
BEERS!
= MILESTONES

9. REALITY
DESIGN ENGINEERING
PRD
Alpha Beta GM Deploy
/Triage /Triage /Triage
IDEATE ARCHITECTURE IMPLEMENT TEST TEST
SKETCH IMPLEMENT TEST FIX BUGS
WIREFRAME TEST ANALYZE
MOCKUPS ANALYZE
SPECIFICATIONS
If something goes wrong, it requires going back through this rigid process to fix it. The farther an issue
goes back in the process, the more valves it has to go through again. This process is very formal, and
usually involves many meetings and stakeholder/management approvals to get the flow going again.

10. vs
TRAFFIC LIGHTS ROUNDABOUTS
http://www.ted.com/talks/gary_lauder_s_new_traffic_sign_take_turns.html

11. CONVERT
PRD
Alpha Beta GM Deploy
/Triage /Triage /Triage
CONVERT CONVERT CONVERT CONVERT
PRD
Alpha Beta GM Deploy
/Triage /Triage /Triage
This process could be improved by converting most of the traffic lights to
roundabouts; metaphorically speaking. Less meetings, formalities and
CONVERT interruptions. This would improve the flow, and free up management to
participate again as builders. Meetings would be minimal and informal
because management would once again have a deeper understanding of
Managers Builders how it all works on a technical level, resulting in a faster process.
RECOMMENDATION

12. PRODUCT
This role is crucial in the macro. They decide what gets built in
what order, and are in charge of the overall strategy. This role is
CONVERT often over staffed and confused with project management. Having
too many will surely slow down the process. Much like the starship
enterprise, a product has the best chance of being nimble and
Product Management One Captain insightful if there is just one captain. Like a CEO to a startup. They
should curate the right team with the right dynamic, keep the ship
straight and get out of the way.
Product managers tend to have backgrounds in business (MBA),
but amazingly do not have much –if any– experience with product
design.
Marty Cagan’s Inspired (How to Create Products Customers Love)
explains what to look for in candidates when filling this role.
RECOMMENDATION

13. PROCESS
Our process is one huge roundabout. Design and Engineering are constantly influencing each
other throughout our process. From the earliest ideation sessions, to the last line of code.

15. Concept to Creation, and everything in between. We flow like water. A constant continuum.

16. We begin by riffing on potential features during our initial brain dump. Over a period of time, the
whiteboard sketches start to slowly gain more fidelity. Once there is a consensus on the core
functions, the design moves toward full fidelity with pixel perfect mockups and animated
examples of behavior.

17. SOFTWARE ARCHITECTURE
During this time the app logic is built. In the case of symposium, the server side backend as well.

18. SIGGRAPH 2010
When the final mockups are agreed upon, the front end development begins. Values (shadows,
margins, sizes, text size, etc) and sliced PNGs are extracted from the PSD files.

19. INTERACTION ELEVEN
For the IxDA11 app, I (designer) was able to tweak the existing code to position items, change
color values and swap images to match the IxDA11 brand. By wearing another hat, I was able to
free up time for Karl (engineer) to work on more complex engineering tasks.

20. We often start our process in a linear fashion, but quickly find ourselves bouncing back and forth
between roles. An idea can spark a series of code tests to validate if something is possible.

21. While conducting a competitive analysis, a marketing idea might come to mind.

22. Minor QA issues can circulate for days –even weeks– in a macro environment, because of their
rigid formal process. If we run in to a QA issue, it is usually investigated, discussed and resolved
within minutes.

23. WEAR MORE HATS FEWER FORMALITIES
BE LIKE WATER
Encourage adaptability by wearing more hats. Get dirty. Learn what your teammates really do
by shadowing them for a day or two, or week. Meet your engineer or designer halfway; get a little
more familiar with their tools. Teach each other.
Design and engineering should be involved from day one in the ideation process. It keeps
engineering informed early on of what is expected of them later on, and it informs designers of
technological possibilities. Yet, collaboration does not mean “Design by Democracy”. Rather,
allow ideas to flow through the process –linear or not– and let your opinions regulate the rate.
Better software can be made faster if we have fewer formalities. Fewer captains, fewer
meetings, means more work force to actually build your product. Captains, stay out of the way.

24. Links
contact us:
@thekarladam info@smudgeproof.net
TED (traffic stops):
http://www.ted.com/talks/
gary_lauder_s_new_traffic_sign_take_turns.html
@kalkor
Inspired (Book):
http://www.amazon.com/Inspired-Create-
Products-Customers-Love/dp/0981690408
Bruce Lee Interview:
http://vimeo.com/3841165
Gratitude feedback for this session:
http://speakerrate.com/talks/5393-macro-vs-micro