Hello cd community, our team over the summer came together and figured out one of the biggest things holding us back is our design process. So we decided to scrap the old process and replace it with a new process. The pic below will show you a diagram of this new process:
!
Off the top of my head I came up with this:
What is a problem? Who defines these problems that will be solved?
How long does each stage last? Designers would love to spend 3 months on a design that needs to be done in a couple of weeks.
Not to sure what research problem means. Is it research past solutions? Or make sure you know everything about the problem? Both?
Whatâs the difference between the two matrices (maybe Iâm just being dumb)
Why prototype after CADing? Is there a preliminary prototyping stage? Why not?
Why not determine prototyping variables before making the prototype?
âDetermine new variables to testâŚâ seems like the last step in the circle but that doesnât make sense. Are you re-doing your matrix or where are these new variables coming from?
You make it seem that the design circle should continue forever. There is certainly a time limit, so I wouldnât suggest writing âor fails to obtain a variable and failsâ because that implies keep going forever. Might just be me, though.
When do people make an accurate CAD? It sounds like youâre making multiple âdesignsâ and the CAD is âbasicâ, but how basic? Before you send off to manufacturing, it needs to accurate, not a rough CAD. Also, for âdesigns will be used in final robotâ, are you using multiple designs for the same problem? Maybe you should specify that these are for different systems.
I would hesitate to think that after manufacturing itâs âdoneâ; why not analyze issues that come up? Re-cycle to mitigate them?
Is this being tracked anywhere so you can go back and reference it later? (ie write it down; maybe this comment is irrelevant to the main topic)
2cents: I still have miles to go in term of designing, Iâm sure older people will correct me where I messed up above.
Also, I admire that you guys set out to fix out the issues you found and set a process out. I would, however, wonder whatâs enforcing a designer to follow this.
Good luck with designing!
Oh, last note: maybe you donât care but the ribbons and the font size choices make it hard to read. The 3d element both wastes screenspace and distracts the reader. And the small black font on green background isnât super easy to read. 
Glad to see teams putting in the work to improve. A few suggestions:
Good luck!
A general tip about data visualization: as much as possible, your visual information should be meaningful.
Those ribbon designs are really distracting - make sure youâre picking the node representations in your flowchart intentionally, so that they mean something.
Plenty of good comments for you to resolve in the 4 posts so far so Iâll try to help a little and not confuse with these somewhat redundant comments.
I assume your motivation is better to design a robot to play the game starting early January. Given that, you can be more specific about your âDefine problem.â Maybe you already do a good job of that so list the steps you have successfully taken in the past.
Possible examples are in the order that we do them are read the game manual, evaluate scoring opportunities (and secondarily, defending), set priorities on the parts of the game to play, ideate mechanisms with sketches that accomplish all the tasks, build and test prototypes. Send to CAD design the best ideas for the priority mechanisms.
You can describe who you expect to do these tasks - split into small groups, individual study, group as a whole, volunteers - for each process step.
I have mentioned in other posts that we try to build fast, rudimentary prototypes for everything that at least one student is willing to try to build. If an idea doesnât get any takers to build a prototype, then that idea dies.
All this happens pretty fast and if my assumption that this is early January, you can right now put down dates, time limitations, schedules, etcâŚ
Another aspect of defining the problem can be who are the stakeholders of process steps. You might (or might not) say the owner is the team and the game drives the design but that thought wears off pretty fast and in my mind the team efforts are directed to satisfying the âDriver/Operator.â Too often I see especially software programmers making unilateral decisions despite the fact they arenât the ones with the pressure of only 2 min 15 sec to score big and win the blue banner. (I know, I know, scouting, pit maintenance, solid construction and a lot more are needed to win but maybe you understand my concern that the Driver/Operator is sometimes neglected.)
You probably are aware that there are thousands of Design Process charts on the Internet. Just the brainstorming line (which is actually one of hundreds of ideation processes has thousands of Internet references.
example: Stage 3 in the Design Thinking Process: Ideate | Interaction Design Foundation (IxDF)
Thank you for the comments, will keep them in mind.
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.
