In a recent post, we talked about what the perfect developer work culture might look like. Professors at Texas State University decided to put this into action, pulling together computer science and graphic design students together to work in a collaborative environment. In the professional world, computer profesionsals and designers work together constantly, but in college, they are separated – which definitely doesn’t do them any favors when prepping for the real world. They end up sometimes not knowing how to communicate, which can lead to missed opportunities. The inspiration for this partnership was past work experience on the parts of both lead professors and the work produced in their own designer/developer partnerships. In this article, we’ll look at a few of the projects that inspired this student collaboration.
One of the projects that inspired this collaboration was “Lucky Shoes”, a game developed by one of the professors in this collaboration experiment. He worked on a team with both designers and developers to make the game a reality. They were able to help each other out in very intuitive ways, simply because they were coming at the problem from completely different perspectives that actually made sense when put together. It worked out to be an excellent partnership.
Punch It Out
However, there’s always the other side of the collaboration coin. An award-winning app called Punch It Out was created, meant to help users remodel their homes and make lists that would immediately be sent off to the contractor. The problem was that the developer didn’t understand what graphic designers really did for a living, and didn’t understand the core factors of the user experience that the app was shooting for. There was a real disconnect in how each player on the team viewed their role.
It ended up being a tiff over roles: the developers thought that the graphic designers were there just to make things pretty, and the designers thought the developers were just a bunch of code-heads. Neither side was correct, obviously. Everyone needs to be involved in the decision making process; they need to learn where the other side is coming from in order to work together.
Children with cancer have a lot on their plate, but doctors need them to keep track of their pain levels in order for them to be managed effectively. Obviously, this is a tall order for a lot of kids. To make this process go a bit more smoothly, an iPhone app called Pain Squad was created, basically, pain monitoring software for kids with cancer. This game puts a fun spin on something that is not so fun by assigning game aspects to it: kids can earn badges, move up levels, get points, and make something that is really annoying and difficult somewhat fun.
This app impacted doctor’s ability to treat these kids in an incredibly positive way. This app was the result of a collaborative project between designers and developers.
Does collaboration always work?
One of the main reasons why these two departments got together was to expose students to additional aspects of the other discipline, help students understand real world collaboration, how designers and developers work together, and utilize each other’s skill sets where they fall short. In a perfect world this is how all projects and departments would work, right? But collaboration isn’t always appropriate or workable. Many people hate “team” projects, mostly because they have memories of doing them in junior high when they had to carry the entire load.
What do you think – when does collaboration between disparate teams, such as designers and developers, make sense? Doesn’t make sense? Do you think that the experiment conducted by these professors is a realistic one? Share your thoughts in the comments.
Intel's compilers may or may not optimize to the same degree for non-Intel microprocessors for optimizations that are not unique to Intel microprocessors. These optimizations include SSE2, SSE3, and SSSE3 instruction sets and other optimizations. Intel does not guarantee the availability, functionality, or effectiveness of any optimization on microprocessors not manufactured by Intel. Microprocessor-dependent optimizations in this product are intended for use with Intel microprocessors. Certain optimizations not specific to Intel microarchitecture are reserved for Intel microprocessors. Please refer to the applicable product User and Reference Guides for more information regarding the specific instruction sets covered by this notice.
Notice revision #20110804