Winning by Design: The Methods of Gordon Murray A Research Paper by Nigel Cross & Anita Clayburn Cross A case study of the working methods of one particularly successful designer in a highly competitive design domain - Formula One racing car design. Gordon Murray was chief designer for the very successful Brabham and McLaren racing car teams in the 1970s and 1980s. His record of success is characterised by innovative breakthroughs, often arising as sudden illuminations, based on considering the task from first principles and from a systemic viewpoint. His working methods are highly personal, and include intensive use of drawings. Personality factors and team management abilities also appear to be relevant. There are some evident similarities with some other successful, innovative designers You need to make the step forwardDrawing the bitsLike designing things for the first timeWonder PlotsI never have engineers that aren't designers+7 More design
Co-Evolution of Problem and Solution Spaces in Creative Design An Essay by Nigel Cross & Kees Dorst www.researchgate.net Between the two spaces What the prototype tells youSolution to evaluation and back againIn terms which must be alteredPrimitive design
Planning doesn't make for better software A Fragment by Robin Rendle www.robinrendle.com My own time in a Silicon Valley startup has proved this much to be true; planning doesn’t make for better software. In fact today our design systems team doesn’t have sprints, we don’t have tickets or a daily standup. Each day we come to work, figure out what’s the most important thing that we could be doing, and then we—gasp!—actually do it. Watching so many other teams slowly flail about whilst they plan for quarter 3.2 of subplan A, whilst our team produces more work in a week than they all do combined in a quarter has been shocking to me. After four years of working in a large startup, I know what I always assumed was true: you don’t need a plan to make a beautiful thing. You really don’t. In fact, there’s a point where overplanning can be a signal of inexperience and fear and bullshit. The scrum board and the sprints and the inane meetings each and every day are not how you build another Super Mario 64. Instead all you have to do is hire smart people, trust them to do their best work, and then get the hell out of their way. Why Software is Slow and Shitty planningsoftwareagile