Discussions with a good friend this last week made me realise that I’d never put my thoughts down on how students should be building their applications before. Thanks friend, your prodding is greatly appreciated. Sure, I’d been thinking about it and determined what was needed from the software development process, but since moving more into the service design and design thinking camp, I’d not coalesced these ideas together. As always with these things, this is just a snapshot of where my thoughts are now. As I get a better understanding of this all myself, I’m sure my ideas will change. In any case, it is useful to document the starting point.
I’ll roll this idea out with the MSc students on group projects over the coming summer and then iterate it for other group work next academic year. These students have already done some of these things in isolation as part of other exercises, but other parts will be new to them. Where possible, I’ll pull in materials from elsewhere and use things they can run on their own. However, some parts will need to be facilited by myself or other suitable staff members. These group projects are always done with an external client across a variety of domains.
The process starts at the top and goes around clockwise with the red labels of ‘discover, define, develop and deliver’. This follows the British Design Council ‘double diamond‘ where discover and develop are divergent phases, and define and deliver are conceived as convegent ones. Putting this into a wheel is based on a DNA Wheel diagram from Sarah Drummond in her Embedding Design presentation.
The process also overlaps with the creative problem solving (CPS) stages used by Basadur, and thus also suggest phases and activities for each of the stages. While that breaks everything into eight phases of the circle, we can see them mapping onto these same four phases without too much trouble.
The orange labels suggest activities for each of the phases. I assume that each group will use all of these in the phase in co-creative work with the client. After fact finding and understanding the issues involved with the client, then they will brainstorm and ideate possible solutions. One or two of these will be rapidly prototyped according to whichever will provide the ‘biggest bang for the buck’, or some other logic about a return on the time/effort invested. The best of these ideas will be carried forward into the next phase where a more detailed prototype will be developed and refined based on user feedback. Accepted and validated ideas from the prototype will be moved into the deployed version that is released.
The blue labels suggest specific activities that will implement the orange activities. You can assume many more of these, and these are here only as typical versions of the activities I expect to use with the students. During the discovery phase this will include empathy maps and personas based on interviews. CPS can be used inbetween the discover nd define phase, while StrategicPlay sessions using Lego Serious Play can be used in the define phase. Needless to say many of the ideas in GameStorming could also be used here too.
The green labels are ways to help learn the blue labelled activities. They are there to provide another aspect of the process.
I see the Plan, Do, Check, Act (PDCA) from Deming, and the Build, Measure, Learn from the Lean Startup cycles sitting between teh ‘define’ and ‘develop’ cycles as ideas flow back and forth between them. Successful, ‘validated’ ideas move onwards to the ‘deliver’ phase.
The next step for me is to flesh this out some more with specific activities for the students in each phase along with more detailed notes and references for them. I’ll put in more references here too, for the rest of you too. In the meantime, please leave any comments about this you may have.
