Back to the Basic
For a start I chosen general description of each processes. Understanding of the project approach and point where we have to make decision with UCD or Agile. Requirements – as a main building component for any project was a start our understanding. Design plane a using techniques based on Object Oriented Methodology such as OOP and OOD. Then I’ve move their focus to implementation and problematic of testing and evaluate your solution. And finally benefits of UCD which is in the centre of this three circles.
What do we know
We know how to start. We research, we define, we design and we present. If we a re lucky enough we start building with sign visuals which always change. Model of the dependency is important if you don’t finish first part properly never push your self to move in to another part. You might save day or to but on the end you’ll spend triple time to fix all bugs you haven’t though through.
We moved to the Development, Deploying and Extensions where everyone can saw himself to have same problem as we have. Plane for the UCD I have introduce without any special features but for me work almost 7 years. I established myself as a User Experience based Designer. (This model will be described in separate post.) Development and testing looks more circular where you as a developer still going back and forward evaluate and test. This bring our focus to the TDD – test driven development and benefits of this practice.
What we don’t know
Our knowledge has to be wider and broader than client has. We have to understand not only technology but also design principles, content dependency and flow, product hierarchy and even market needs. We have to research, user tests and use case studies with similar problematic to find out what they trying to solve and why?
Waterfall is linear process and has a two primary section – design and development but as we see on the graph we have more to think of. We have almost 25% time for research and site audit case study, technology research. Than time for planning and initial design. In Agile I have found on things more useful than on UCD where scrums gave you better understanding of dependency which sometime we don’t have in UCD. If your company or studio is mostly driven by waterfall and you are applying Agile – you can imagine that you’ll have small UCD’s in side one scrum. Of course with one big difference the big picture will be seen in first integration – which many designer can not understand.
Overlap – of these two method will give you more flexibility. Obviously more stress on the beginning but more relax process and execution of all elements in whole application.
In many projects I have been through in the past I’ve realize that many problems become from luck of communication. So my last point and advice was refere to One Place, One Solution, One Approach and One Language.
One Place - No matter which channel or communication portal you choose but stick to that don’t change it in the process. Don’t end up with two or even three different communication channels. Within mid-size project (min 5 people – designers, developers, architect, Ix Designer) you can end up wit over 50 emails / updates a day and from three different sources will three times more. Stick to one you prefer - you building you choosing the platform!
One Solution - is obviously about Complexity, Risk, Expertise, Time and Rules under which you will deliver. Complexity of the project is a main things, you ave to divide in to a logic part which depend on each other. To minimize the risk for the client make sure that everyone even last person in the process really understand what is happening. Misunderstanding is most problematic part especially across language barriers which obviously you don’t have to face it. But if so keep this in mind. Expertise is not only for you – collaborate with developers, designers, marketing department and even colleagues from your field what is the best solution. This will buy you a time – to prepare other things for the project.
One Approach - As I already mentioned Role Delegation and Hierarchy in the team give you strong bone which you can relied on. This will force your colleague to collaborate more because their dependency become more important in this project approach. And finally Responsibility – where you just give one task and receive 100% solution on your enquiry.
One Language - As I have already mentioned language barriers can be problems. But now it’s not about yours mother or secound language. I’m talking about project language – Naming convention for files and folders even for the layers if necessary. This brings total control over all in one breath. No one wonder what is the latest version and where is it stored. Make a description for the client and for you developer so both will understand where their tasks start and finish.
- Design Quotes - http://quotesondesign.com
- WAI - http://www.w3.org/WAI/redesign/ucd
- flow - http://www.flowinteractive.com/design – Jan Srutek MSc
- Buzzle - http://www.buzzle.com/articles/waterfall-model/
- Peter Morville - http://www.semanticstudios.com/
- Jesse James Garrett - http://www.jjg.net/elements/
- boxes and arrows - http://www.boxesandarrows.com/view/bringing-user
- Jason Clark - http://www.yellowfields.co.uk
- The Experience Economy - http://en.wikipedia.org/wiki/The_Experience_Economy
- Buzzle - http://www.buzzle.com/articles/waterfall-model-vs-agile.html
- Waterfall vs agile methodology - http://agileintro.wordpress.com/2008/01/04/waterfall-vs-agile-methodology/
- searchsoftwarequality.techtarget.com - http://searchsoftwarequality.techtarget.com/sDefinition/0,,sid92_gci519580,00.html
Thanks to @matcheck and his post ppps-seminar-ucd-in-agile where you can see some reactions. I’ll try to refer to each of this point if you want to. If you have any question just shout! Thanks all of you for coming and definitely see you next time.