Start-Up Panel

From CS160 Spring 2014
Jump to: navigation, search


Getting Real. Read Chapters 4: Priorities; 6: Process; 9: Interface Design.

Reading Responses

Andrew Fang - 4/19/2014 20:15:02

There are many aspects of the 37signals philosophy that matches what we learn in 160 including ignoring the details early on, and working in iterations. Both teach us to first brainstorm, then build paper mockups as a low-fi mockup, then use tools like HTML (or balsamiq) for a mid-fi mockup, all before starting to code the actual product. Both have a philosophy to find a targeted audience, to build an app for a specific group of people, rather than try to please everyone. Both direct us to improve the application using user tests in the real world. One thing that is slightly different is that 37signals says to not deal with scalability issues until its a problem, but the professor in lecture mentioned thinking about these scaling problems and trying to integrate them as we build our systems. The 37signals philosophy tells us to make decisions for the users by not including man preferences, and to make decisions knowing that they can be wrong. This is useful when we want to build and iterate on our design multiple times, and let the tests determine what was good and what wasn’t. I feel like the philosophies taught by 37systems is very similar to those taught in class, but 37systems has details specifically for web applications.

Daniel Haas - 4/21/2014 17:26:37

The 37signals design philosophy lines up with that of CS160 in a number of ways. For example, both focus on big-picture design before fixing minor details by building low-fidelity prototypes. Additionally, both emphasize the importance of improving the effectiveness of a product by targeting specific user groups. For example, 37signals made the decision to only target their "Campaign Monitor" product at web designers, which helped them refine their strategy and feature set accordingly.

However, there are important differences in the two philosophies. 37signals seems to be a bit more focused on defining an initial vision and sticking to it, whereas in CS160 we emphasized the importance of rapid iteration and the use of techniques like contextual inquiry to incorporate user feedback into the design of the product. In addition, though both strategies approve of the use of low-fidelity approaches, 37signals emphasizes the importance of getting to running software as quickly as possible. In CS160, we built a number of prototypes (paper, slideware, mockups, etc.) before actually designing functional software.

The 37signals approach is targeted at people trying get to a webapp as fast as possible without compromising quality. It seems like it would be preferable in design situations where budget is the most limiting factor--less money spent on contextual inquiry, and a viable product created faster so as to begin recruiting users.

Charles Park - 4/21/2014 16:41:02

The 37signals philosophy is similar to that of the design process taught in CS160 in that both of them follow an iterative pattern. Both processes starts out by a low-fidelity design and getting feedback in order to further develop or redesign the product. The difference may be in how the iteration takes place. The 37signals philosophy focuses on building a working prototype as quickly as possible while the CS160 design process puts more emphasis on flexibility and multiple reviews and edits of the mockup before building a working prototype. The 37signals process seems more preferable for re-iterations if not ad-ons to pre-existing products. Or perhaps a design that is done by an experienced veteran. While in process of creating something that is completely unique or new, the CS 160 process seems much more effective.

Myra Haqqi - 4/21/2014 19:56:23

With regards to priorities of the app, 37signals shares some similarities but also differs in some aspects with the design process taught in CS 160. For example, the 37signals philosophy begins by posing the question of what the general overview and vision of the application is. In CS160, we first focused on the target user group, the problem to be solved, and the sound-input incorporation into our application. While 37signals bolsters the notion of a concise vision, we were initially asked to write out an explanation for our app in our first group brain storm assignment.

Both processes are similar in that initially, there is a focus on the big picture rather than the details early on. In 37signals, emphasizes the importance of primarily ignoring details, and adding more details later rather than sooner. Similarly, in CS160, we first came up with the general concept of our apps, without pinpointing on the exact design and interface decisions.

Furthermore, both 37signals and CS160 disregarded problems that we are not currently facing. 37signals proclaims to make decisions about problems at the time needed, for there will be more information available to make an informed and efficient decision. CS160 followed a similar guideline in the beginning of the semester, when we were told to simply expand upon our ideas for our app without concerning ourselves too much about the challenges we may face later. However, CS160 did differ slightly, in that we were later told to keep feasibility of the app in mind. We were told to think about and understand how feasible our app would be to implement, which did not allow us to completely disregard problems that were not posed at the time.

Both 37signals and CS160 also focus on the significance of the users: 37signals proclaims that the customers of the application need to fit with the app. This is similar to our CS160 design process, in which we had to determine the target user group for applications. For example, the target user group of an application meant to improve the experience of purchasing BART tickets would be users who travel on the BART frequently. Both processes include the necessity to understand that the application should be catered to this specific target user group, rather than trying to please all people.

Also, 37signals mentions that the concern for scaling an application that is very popular should be handled later, when faced with that issue. In CS160, the design process we were taught did not really address scaling of applications.

Finally, the 37signals philosophy claims that making opinionated software is essential. Rather than trying to make software flexible to appeal to all, 37signals fits with the intended specified customers who want to use the application and agree with its design decisions. In CS160, we received feedback from our target users to improve upon our application.

The process of 37signals and CS160 also shared some similarities and differences. 37signals begins by claiming that it is useful to have an application up and running soon, in order to be able to do something useful and get meaningful feedback to improve the app. CS160 also somewhat followed this principle, as we first created low-fidelity prototypes, and then later we progressed through prototypes until we implemented a working prototype in Android.

Both 37signals and CS160 are very similar in the concept of working in iterations. Specifically, 37signals claims that receiving actual feedback helps designers improve their application. Furthermore, in CS160, we learned that it is very important to iterate. We learned the important design cycle of: design, prototype, evaluate, and repeat this process cycle repeatedly.

The process that 37signals claims is best is to first brainstorm to come up with ideas, then complete paper sketches, then create HTML screens to represent the application prototype, and then finally implement the application in code. This differs in the design process covered in CS160: we brainstormed and created sketches while brainstorming. We then also created additional sketches once narrowing down our idea. We then did not design our application prototype in HTML; rather, we used the Balsamiq tool to create low-fidelity prototypes of our apps. Then, we began to implement our application in code.

37signals claims that preferences should be avoided. Instead of creating many options for users to choose from, simply make some decisions for them. This is similar to the design process we learned in CS160, which also taught us that the more choices a user is faced with, the more time it takes them. In addition, the 37signals philosophy mentions the ability to change decisions made later. Therefore, it is not worth getting too caught up in some decision, and it is ultimately better to make a choice and then move on. This is due to the fact that the designer always possesses the ability to go back and change the decision. In CS160, we were taught also that we can change our design throughout the design process of an application.

37signals includes the importance of testing one’s application with real people. This is similar to CS160, in which we learned to test an application with actual target users. 37signals, however, suggests releasing beta features to certain people. In the CS160 design process, we did not test certain beta features with specific people; rather, we tested the same prototype with our target users.

37signals also bolsters the notion that minimizing time goals into smaller pieces in order to divide and conquer problems. In CS160, we also learned in the design process to break apart the project into smaller bits and iterate through the process.

In terms of interface design, CS160 and 37signals philosophies are similar in that they both include designing the interface before implementing the app with programming. For example, 37signals claims that first creating simple prototypes and designs is much better than beginning with programming first. Similarly, in CS160, the design process we were taught also emphasized the significance of creating prototypes and interface designs before programming the implementation of the working app.

An example of another difference between 37signals and CS160 is that 37signals claims that designing from the core center of the interface, and then working outward is better. However, in CS160, we were not taught this epicenter design concept in the design process. 37signals also divides the types of screens into regular, blank, and error. This differs from the CS160 design philosophy, which did not include these separate distinctions for each screen.

37signals also differs from CS160 in its idea of the importance of context over consistency. It claims that when it makes sense to design an application in a certain way, it is better to be inconsistent in this scenario, and to differ in the designs of screens. However, 37signals compares with CS160 in its emphasis on defensive designing. Specifically, 37signals focuses on the importance of making sure the interface takes into account when things go wrong, as this leaves a lasting impact on the user. Similarly, CS160 also emphasized the importance for designing defensively in its inclusion of the design principle of error-correction, which helps the user when there are errors in the program. The idea of the blank state, however, is unique to the 37signals philosophy. It bolsters the significance of designing a blank state stage, which is very important in the role of the first impression on the user, which is known to have a lasting effect. Some suggestions of what to include in the blank state include tutorials and help blurbs. In CS160, this was not a necessary part of the design cycle.

Furthermore, 37signals emphasizes the importance of words in an interface. Specifically, it mentions the principle that “copywriting is interface design” because it is important to consider how to word information in an interface. This was not focused on as much in CS160. Another distinction between 37signals and CS160 is that 37signals mentions the idea of incorporating admin screens into the one single interface. In CS160, admin screens was not a major feature in the design process.

The 37signals process is preferable to the one taught in CS160 when an application makes more sense to be designed in such a way that is not consistent. For example, when it is necessary for some pages to include a certain button, while this would not be useful in some screens, then 37signals claims to be inconsistent in this scenario in terms of the context.

Another example in which 37signals is a preferable method of design process is when there are many words needed for instructions or explanations. This is because 37signals elevates the importance of the use of words in an interface.

Furthermore, 37signals may be preferred over the CS160 design process when there exists the need for admin screens in an application. For example, when an application needs to have screens in order to control certain aspects of an app, then the 37signals possesses the concept of incorporating these admin functions into the public-facing interface because it improves the experience for admins.

Jeffrey Butterfield - 4/21/2014 18:42:33

37signals encourages an appmaker to specify a clear "one-point vision" for the application being developed. This differs with CS160's talk of a "divergence of ideas", the part of a brainstorming session where the brainstormers are encouraged to come up with ideas based on the rule "aim for quantity, hope for quality." However, there is also the refining/converging stage of the brainstorming process that strives for the same focused, specific idea that 37signals demands. Both convey the importance of iterations. 37signals is enthusiastic about not wasting time getting every detail right but instead focusing on getting a working rough prototype working as quick as possible in order to inspire enthusiasm in your engineering team. CS160 also encourages not getting bogged down in details outside the scope of your iteration early on, but CS160 is a little more focused on the design and prototyping processes. The language of the 37signals readings emphasizes expediency, and while they do spend a little bit of time talking about the importance of testing, they bash the professional usability testing that CS160 has argued is a very important part of the evaluation process. Both philosophies preach the importance of thinking of the target user when designing an app, instead of trying to please a general population of non-specific users.

The 37signals process might be preferable to the CS160 process if there are a lot of time-sensitive tasks with deadlines that are non-negotiable. This is to be expected in real-world situations, so some of the less vital (but still very useful) design steps discussed in CS160 can be skipped or shortened. However, once too many shortcuts are taken on brainstorming, prototyping, implementation, and testing, the app undoubtedly begins to suffer. If brainstorming is cut short for the purpose of finding a quick focus, an important and ingenious idea might never have time to come to the surface. If prototyping is rushed in favor of spending time on programming, time might be wasted on implementing interface with flaws that might have been apparent in a paper prototype. Finally, sometimes real-world testing is not always realistic, and formal usability testing can be a quick and convenient addition to a developer's testing strategy.

Ziran Shang - 4/22/2014 18:02:52

The 37signals philosophy is similar to the CS160 design process because both are iterative processes. Both processes involve focusing on a core group of users, and both processes follow a design, prototype, evaluate cycle. Both processes involve designing using sketches first. Like we learned in CS160, 37signals advocates designing the app with some of the 10 usability heuristics in mind. However, 37signals focuses more on context over consistency. Another difference is that 37signals believes that making a high fidelity prototype is critical, and also that direct testing should be done with real users, rather than any of the other methods for usability testing mentioned in CS160.

I think the 37signals process is preferable and more relevant to web design, especially since they advocate making full HTML prototypes and then adding functionality. This can be much easier to do with web programming, whereas making high fidelity prototypes in for other apps can be more time consuming. Also, 37signals believes in including beta features in releases of the application as a way of user testing. This may be preferable to having controlled usability studies and tests, but is more practical on a web platform where bug fixes and changes can be rolled out without making the users download a new version of the app.

Zack Mayeda - 4/22/2014 21:01:15

The 37signals philosophy is the same in that it encourages frequent iteration. Both processes suggest a iteration of brainstorming, building, and using/testing. They also suggest getting feedback on a product/prototype before it even has all of its features, similar to what we did for our class projects. Another point in which the processes mirror each other is that they both suggest drawing out interfaces at the very start, either hand drawn or digital mockups.

The two processes differ in that 37signals suggests testing products on real users even when they're incomplete. Even though our apps are not intended to be real products in the app marketplace, the 160 design process only includes tests on selected users in a well controlled environment. The 37signals also suggests designing for empty, normal, and error states, something that 160 didn't touch on or emphasize. Additionally, 37signals highly emphasized copywriting choices which wasn't highlighted in 160.

The 37signals process would probably be preferable if a product needed to be developed quickly for a startup-type company. The process quickly gets a product running and depends on frequent iterations to make a great product.

Sangeetha Alagappan - 4/22/2014 22:00:54

The 37signals philosophy matches the design process in CS160 in a number of ways. They believe in working in iterations with continuous revisions as has been taught to us in CS160. They prioritise bugs and work on more pressing tasks first as we have in CS160 using the Nielsen severity rating of 0-4. 37Signals also strongly believes in working from large to small scale - that is, working on the big picture and ignoring details in the early stages, as we have in CS160. They also believe in finding a core market and pinning down the focus of their application so that their design process is focused which is a similar to the design process in CS160 where we focus on a narrow user group. 37Signals also defines their interface before they start programming which is a process we also follow in CS160. Like CS160, 37Signals believes in starting off with brainstorming and low fidelity prototypes using materials like paper, transitioning into an interactive prototype before fully fleshing out the application and worrying about scaling the application only much later once the application is well settled.

However, their philosophy also differs from CS160’s design process. They don’t have many meetings and try to eliminate paperwork. They believe in keeping up a quick momentum and getting the application off the ground not long after it is conceived. They believe in beta testing and are not in favour of usability testing (that CS160 prefers), describing it as stiff and not as thorough and diverse as launching a product in its infant stages to a wide variety of users. They believe in favouring context over consistency which CS160 doesn’t always advocate (Consistency and standards is one of the ten heuristics). They also believe in a Hollywood launch - a teaser, premiere and a show - making the launch of an application a process of different stages unlike CS160’s one final launch philosophy. 37Signals holds that it is important not to get bogged down by details and takes it upon themselves to take care of little details instead of asking their users to. They also are unafraid to take a stance with their application while in CS160 we didn’t actively make opinionated software. They believe in quick launches and even put out products (Basecamp!) even though they were not complete and implement less pressing tasks after a product launch. Another interesting idea is that 37Signals designs three state solutions (regular, blank and error) to handle a variety of user states.

The 37signals process is preferable to the one taught in CS160 in start-up companies, small teams and fast-paced work environments that need to meet tight deadlines. While it is an interesting, high energy approach to the design process, it might not be applicable to applications being designed for a large audience or those that deal with sensitive information. A lot of their principles are promising and would be beneficial to incorporate into the CS160 design process (like using a three state solution, using beta-testing and progressive launch stages).

Michelle Nguyen - 4/22/2014 23:39:48

The 37signals philosophy shares many similarities with the design process taught in CS160. For instance, 37signals says to first think of a big, general idea to drive the product design. In CS160, we were also taught to have a broad main goal for our application. This prevented us from limiting ourselves to a certain design and allows more novel ideas. Another similarity is that both philosophies stress not focusing on details first, such as alignment and font size. Those details will limit the time you have for the more important aspects of the design. Also, the 37signals philosophy stresses having a very specific target user group, because, just as we have learned in CS160, we can not create a good application by catering to every single possible user's needs. Another similarity is that both principles teach us to work in iterations and use paper prototypes and mockups. 37signals also encourages testing with users, which CS160 has greatly stressed through the course. Also, 37signals teaches us to start with the interface design, then add in the programming after, which we have also learned. Another similarity is the idea to keep error prevention in mind when designing our product.

However, the 37signals philosophy also has many differences with the design process taught in CS160. A huge distinction is that the 37signals philosophy states that your number one focus is to have a running application, and the sooner the better. CS160 has taught us that the running application is one of the least important parts of the design process, and many design decisions can be evaluated through interviewing users and testing prototypes before even creating the running product. Also, although 37signals encourages testing your product with people, they mention it is best to use beta testing on specific users and that people don't perform naturally when they know they are observed. This is significantly different from many of the usability tests we have learned in CS160, such as the recent pilot usability test. Often in this class, we have directly observed and interacted with the user. Another difference is that the 37signals philosophy calls for favoring context over consistency, which we know contradicts with one of Nielsen's heuristics that we have learned.

The 37signals process seems preferable if you want to release your application for use as soon as possible. For instance, they stress having a running application as soon as possible without mentioning testing the mockups and prototypes with users along the way. When testing was mentioned, it was in terms of having users test beta features along with the normal features they already have. Thus, their design process before initial release seems much shorter than the design process we have learned about in CS160, where we may go through many iterations of the design cycle before releasing the product. Also, the 37signals philosophy mentions dealing with problems only when they arise (such as scalability) which is a good philosophy to follow if the initial release of your application is not perfect and can be updated quickly. Thus, by following this philosophy, your initial release does not have to be the completely refined.

Nicholas Dueber - 4/23/2014 1:03:09

The design approaches of both CS160 and 37signals are very similar. They both start out by thinking of an idea, then they both want to narrow it down to fit a niche market. This makes it so there is a specific target group where a specific goal can be met rather than trying to solve everybody's problems. Then both philosophies include making what you want the user interface to look like and how the user is going to interact with it. At this point the philosophies diverge. In CS160 were encouraged to test out our low fidelity prototypes, and in the 37signals philosophies we were encouraged to try and start programming at this point.

The difference are clearly in the test and iteration phase of the design process for CS160 whereas 37 signal moves on to development at an earlier phase. The 37signals philosophy is more appropriate when you are on a tight schedule. It could also be used if you are just a freelancer, this means that the project is being specified for you and you don't need to worry about finding a market, you just need to deliver a product. The CS160 approach seems to be a more holistic approach, this means that we are considerate of every aspect of the development from field research to design functionality. This is best if your schedule is more flexible and research is on going.

Munim Ali - 4/23/2014 1:40:11

The 37signals philosophy and the design philosophy taught in CS160, are similar in that both philosophies emphasize iteration. Both 160 and 37signals include uninhibited brainstorming in the design process - an emphasis on coming up with ideas rather then being caught up in refining during this phase. Sketches are featured in both philosophies too, albeit CS160 seems to emphasize it more than 37 signals.

Both, of these philosophies of design however vastly differ in their essence - 160 seems to focus on a meticulous and long-drawn design process, while 37signals is more about getting the job done fast. 37signals for a large part considers mock ups and sketching as a waste of time/resources and puts emphasis on software, 160 however seems to value these very things a lot more - using prototypes and mock ups as building blocks for the final design.

The design process adhered to by 37signals is preferable to that taught in 160 in a commercial environment (especially startups) where time and resources are precious and a long drawn out design process could be too costly. Also, feasibility concerns are addressed a lot sooner with 37signals emphasis on coming up with software fast rather than in 160 where these issues are addressed pretty late in the design process.

Rico Ardisyah - 4/23/2014 7:35:29

The similarity between 37signals and CS160 is the iteration process. 37signals process follows design, prototype and evaluate cycle closely. Hence, both of the design requires ideation before start to code. The difference between the two processes is the emphasis on prototyping. While CS160 considers prototyping is important, 37signals set low emphasis on prototyping for a straight to coding. This process is preferable when we want the first working version soon.For some cases, client wants to demo the working version first. Hence, this process is preferable to CS160 design process.

Sol Park - 4/23/2014 3:23:38

The 37signals' philosophy generally matches the design process taught in CS 160. Both of them focuses on "iteration". Design takes multiple iterations to be considered as completed. That's why 37signals emphasize on the importance of iteration (ignore details early on, scale later, rinse and repeat, etc). This is also true for design process in CS 160 since we go through multiple iterations of our project. We refactored our design multiple times based on the targeted users' feedback. Both 37signals and CS 160's design processes require validation of the initial hypothesis. Hence, designing involves conducting several testings to validate the hypothesis. If it doesn't validate the hypothesis, we make some changes to improve the design. Through such iterative process, the goal of both 37signals and CS 160's design processes is to create a product that best satisfies users' needs. Therefore, 37singals' approach and CS 160's design process are equally important in product design.

Tien Chang - 4/23/2014 8:17:38

37signals philosophy is relatively similar to the design process taught in CS160 in that it states that having a vision and hiring the right customers are essential to a successful start-up. This is similar to CS160's design state of keeping your focus and defining your target users principles. 37signals also mentions a "rinse and repeat" philosophy, similar to the CS160's design cycle of iterations. 37signals goes into depth about brainstorming through low-fidelity means (sketching) and testing with real users, which we spent a large portion of CS160 learning and applying.

Differences I noted include 37signals' advice to "get something real up and running quickly" (Priorities) and CS160's process of continuous improvement through prototypes and evaluations. Also, 37signals advise to begin interface design from the core of the page and outward, while in CS160, we learned about multiple interface designs (rule of thirds, golden ratio, etc).

37signals may be preferable to the design process taught in CS160 to professional designers who are able to move at the quicker pace 37signals seems to imply. CS160's design process is great for students (like us) who are just beginning to delve into the design world.

Tien Chang - 4/23/2014 8:21:53

37signals philosophy is relatively similar to the design process taught in CS160 in that it states that having a vision and hiring the right customers are essential to a successful start-up. This is similar to CS160's design state of keeping your focus and defining your target users principles. 37signals also mentions a "rinse and repeat" philosophy, similar to the CS160's design cycle of iterations. 37signals goes into depth about brainstorming through low-fidelity means (sketching) and testing with real users, which we spent a large portion of CS160 learning and applying.

Differences I noted include 37signals' advice to "get something real up and running quickly" (Priorities) and CS160's process of continuous improvement through prototypes and evaluations. Also, 37signals advise to begin interface design from the core of the page and outward, while in CS160, we learned about multiple interface designs (rule of thirds, golden ratio, etc).

37signals may be preferable to the design process taught in CS160 to professional designers who are able to move at the quicker pace 37signals seems to imply. CS160's design process is great for students (like us) who are just beginning to delve into the design world.

Anju Thomas - 4/23/2014 9:45:56

How does the 37signals philosophy match the design process taught in CS160? How does it differ? When is the 37signals process preferable to the one taught in CS160?

The 37 signals philosophy matches the design taught in CS160 in many ways, however there are also some differences in the beginning stages of the design process. For instance the CS160 course has given more emphasis in planning out the beginning design process by first brainstorming, making prototypes, performing a contextual inquiry and task analysis, evaluation and then iterating until the final product has been designed.

Unlike the CSS160 approach, the 37signals approach presents a different philosophy where they advice people to “race to the running software” and try to get the product out fast. The 37 signals philosophy encourages users to race to finishing the main functionality and deal with other problems after. This philosophy might be more useful if for the real world where time plays an efficient role in product development. This is more practical than the CS160 theory in the real world due to the importance of not wasting too much time and resources. However, I prefer the CS160 theory otherwise, due its more focused approach in improving the design according to user preference and taste.

Despite the differences the two share some similarities as well. For instance, the 37 signals philosophy suggests to first think of an idea before beginning the application implementation process. Encouraging the idea of brainstorming, this closely relates to the CS160 idea of brainstorming, where the designers were first encouraged to think of as many ideas as possible in large quantities which would later effectively help them narrow it down to a single idea. Both state the importance of first coming up with a good idea before paying attention to the main details of the application. The CS160 course also focused on the brainstorming , sketches to coding theory of the 37 philosophy theory as we learned how to make sketches and storyboards. Emphasizing the use of story boards in the beginning phases of design and testing, the CS160 course emphasized a similar idea to 37 signals philosophy. The two also discuss the process of iteration as discussed in the 37 philosophy’s “rinse and repeat method” and its role in application development.

Similarly the 37 signals philosophies also suggested the “Test in the wild” which described a similar idea to the CS160’s testing process with users. Though the 37 philosophy does not give it as much emphasis on user testing as the CS 160 course it does include the idea. I especially like the CS160’s emphasis on user testing, as it might be harder to change the functionality of the application once the user races to getting the software out and running. So I feel like this step should be given more emphasis on the 37 signals philosophy’s page, as it is an important factor that influences the beginning stage of design.

The two also describe the importance of designing of an interface. For instance, both state the importance of creating a simple interface to allow users to manipulate and navigate through the application with more ease. By encouraging the designer to focus on the start screen the 37 philosophy describes the importance of the interface design to the importance of user satisfaction. Though the primary difference is that the 37 signals philosophy states the importance of designing an interface before diving into the deails of functionality, while the CS160 course also mentions the importance of improving the application gradually to fit the user’s main needs and functionality for the application.

Overall, I prefer the CS160 theory more than the 37 signals philosophy due to its more focused and specific approach in the beginning stages of the design process and its emphasis on including user participation and testing. As the users are a main factor in determining an application’s success, I feel that the CS160 course appropriately emphasizes and accounts this factor in the beginning stages of design. Though the 37 philosophy might be a more practical way of designing an application in the real world the more relaxed stance taken by CS160 in the designing effectively communicates the importance of carefully designing an application rather than rushing to get its core functionality down.

Gregory Quan - 4/23/2014 10:51:24

The 37signals process is similar in a lot of ways to the methods taught in this course. Some techniques both methods have in common include designing from large to small, getting something running first, not sweating the details until later, having a simple mission statement, working in iterations, and testing in a real environment.

The 37signals process emphasizes context over consistency. Some of the principles taught in CS160 emphasize giving users a consistent look and feel: keeping the same colors, fonts, and layouts throughout an application, using the stock Android icons, imitating other apps that perform similar tasks due to familiarity, etc. The 37signals process differs from this approach slightly by emphasizing that it is okay to be inconsistent when it makes sense to do so: “Do you need a global search bar everywhere? Do you need the same exact footer on each page? The answer: ‘It depends.’” It may make sense to follow the 37signals method in certain situations, such as when trying to shrink a desktop website interface down to a mobile phone screen, but it is important to carefully consider possible confusion that could be created by being inconsistent.

Christina Guo - 4/23/2014 10:57:27

The philosophies are similar in that they both involve multiple iterations in order to refine the product. They also both advocate starting from lo fi prototypes such as sketching to hi fi prototypes such as html pages before coding the app. In addition, they both advocate keeping the app easy to use and minimalistic. In CS160, we discussed the idea that having too many buttons and options takes a user longer to act. Similarly, the 37signals philosophy teaches us to limit the number of preferences available to the user. However, they differ in that the 37signals advocates testing the app in the wild by real users whereas the design process in CS160 is more focused on formal usability tests with defined tasks.

The 37signals process may be preferable to the one taught in CS160 once the app is up and running. When you have a lot of users, testing through beta features will get more user data quicker than setting up a series of formal usability tests. The CS160 version may be better before the app is released or in starting stages, when there isn't a lot of real users. But once the app becomes more widely used, different types of testing may become more appropriate.

Steven WU - 4/23/2014 11:14:50

Because 37signals follows the iterative design process, it can be said that CS160 and 37signals follow the same design principles, but some choices in the tools and the timeline does vary. The first similarity that I took note of were was to shrink your time to break it into individual chunks. 37signals states to rethink of a 12 week project as 12 weeklong projects. This is the same idea that CS160 follows; there are weekly check-ins on the semester project so that teams can break the design project into modular chunks. Another thing that stood out similarly was the focus on working on the interface first as well as the epicenter design. CS160 and 37signals stress the importance on how the key functionality will work without considering the details. Another point from 37signals that resonated well with this course was the idea of context over consistency. I've actually realized this firsthand when I was tasked to design the layout of our application as it was recommended to change the background image of our application to better let the user know that they have reached a different page. Initially our team had incorporated the same image as the background of every unique page. We realized that providing context that the user is on a different page is better than consistently keeping the same image displayed on the screen. Finally copywriting is the last component in both design processes, where the aesthetics come into play, which is largely true in our classroom setting, as we didn't cover visual design of a product until later in the semester.

Just as there were plenty of similarities; 37signals had different motives in their design process from CS160. One of topics that particular stood out was the concept that it's a problem when it's a problem. I felt that when it came to concept generation and the group brainstorm, 160 teams were working to solve every problem they could think of with sound as input. Something else that was different was to make opinionated software. Although this is similar to the Homer Simpson's car invention discussed in class, where Homer develops a car that meets the needs of everyone, 37signals ties other motives to this idea. They want software with an attitude. 37signals makes it clear that they want to drop all insignificant factors from 90% their target customers, but they also want the software to convey its own personality in the software marketplace. Previous this reading, I hadn't considered how attitude could be incorporated to an application's design. Another difference in was to produce mock-ups directly in HTML and CSS, although we use Balsamiq to overcome the learning curve of having students pick up another technology, I find it much more useful in industry to know these tools. But the same idea between 37signals and CS160 are shared as these two design process both value that the implementation comes later. Something entirely new that was mentioned was that there should not be two versions of a product: a release version and a beta version. I suppose this is where CS160 gets right because the course never discussed about releasing a beta product, as we are working on an iterative design that is easily adaptable to the end users' needs. Although this is more for the edge cases of a product, 37signals mentions the importance of the three state solution that the designers should consider: regular, blank and error states. I suppose the closest thing to this 37signals design principle that was covered in the CS160 course work was the high level content covered in the heuristic evaluations.

I think one that CS160 can use in its coursework is to "race to running software". Instead of trying to develop a mobile application on android, develop a web application so that team members are more familiar with web technologies and they can directly race to running software and skip over the learning curve from the three individual programming projects that get the students feet wet with android. To do this, the students will develop real things at a faster rate and these real things lead to real reactions earlier on in the semester and that's how the team members will get on the truth of their product. Then, the users can pick up the html and the css skills that they would need to become UI/UX Designers in industry as it is expected for these employees to know web development as well as the adobe creative suite, which I believe this course falls short on when it comes to learning visual design. The students could also implement 37signals' idea to include admin functionality to an application, but most of the time these features are better used on something on a desktop set up.

Derrick Mar - 4/23/2014 11:53:06

37singals also talks about sketching and prototyping first before programming. It also recommends and iterative process similiar to the design process of design, prototype, and evaluate. However, it does not go into much details about the different stages (or even mentions them at all) like we did in class.

One of the biggest differences about 37signals is that it doesn't talk about testing and interviewing users (at least in the 3 sections I read) and evaluating the design with others. In CS160, this was a large portion of class. We're still interviewing people now with our hi-fi prototype.

I think 37signals will be prefereable when you already identified the problem and are sure that the idea has been validated. Since it disregards user testing, I think 37signals is more about speed and getting something up and iterating from there rather than getting a lot of information from users first. I also think it's focused on web applications. Where changing an idea is not as hard as commiting to a product on hardware.

What I liked: For the interactive design section, I liked how it gives insightful recommendations such as limiting preferences to users and being congnizant of not only the design of words, but what the words actually mean.

Aayush Dawra - 4/23/2014 11:54:16

The 37signals philosophy largely overlaps with the 160 design philosophy. For instance, the importance of evaluation in the 'design-prototype-evaluate' loop of 160 is mirrored in the 37signals philosophy where the importance of iteration and evaluation is highlighted. Another similarity would be that both the philosophies support the creation of prototypes and mockups, before actually implementing the real interface, saving time and getting feedback at every stage of the design process.

Although the philosophies largely match up with each, a key difference is that the 37signals philosophy talks about testing the application with real users in a real world scenario and terms it 'Test in the Wild', which is a more narrow take on 160's feedback methods that encompass Low-fidelity Prototype, Pilot User Study, Wizard of Oz techniques etc. Whether the former is more useful than the latter or vice versa, depends largely on the situation and larger goals of the application itself. For applications that intend to have a commercial aspect, 'Test in the Wild' strategies may be more useful than Low-fidelity Prototypes since it gives feedback on the real application itself rather than low-fi mockups and hence is a quicker method. The Prototype-Design-Evaluate essentially aims to improve the application using baby steps, taking feedback from the user at every stage and although it is more time consuming than 'Test in the Wild', it may be good for some applications as well. It also reduces the chances of an unfinished product being launched since the user feedback is the driving force behind the changes made at each stage.

Juan Pablo Hurtado - 4/23/2014 12:23:25

The part that says, "From Idea to Implementation - Go from brainstorm to sketches to HTML to coding", clearly matches with what we have done during the course this semester. Is literally how we have proceed on our project.

They obviously differ in the "The Three Musketeers - Use a team of three for version 1.0" aspect and also I feel that it differs in that the process taught in CS160 was more focused on task design and testing with users through all the process in a controlled way (managing the variables, testing the heuristics), CS160 is more experimentally than 37signals. 37signals instead encourage to test in the wild, to release something for start testing in a les controlled environment.

37signals way of testing looks like you will need less resources and you'll get more feedback (probably with less quality). So I think is preferable when the goal is more quantity feedback than quality feedback.

Jeffrey DeFond - 4/23/2014 12:00:54

The iterative aspect of the 37signals reminds me of the process taught in 160. However they have a somewhat different view of preferences then our class did, as well as definite focus on monetization. 160 has taken an approach to preferences that represents them as having pros and cons without saying that they are necessarily "lazy" like 37signals has. While they often are a poor idea, I didn't particularly like their dismissive attitude towards preferences. I personally like to know just what apps I have are doing and I want the ability to alter these things too the t (if I need/want to). I'm not saying put these preferences up front and overwhelm the standard user, but make these preferences accessible via some kind of "advanced settings menu." More concisely 37's dismissal of preferences is largely due to a desire to appeal to a non tech savy users (which is important). However I think 160 taught us a good middle ground, where preferences are something with a cost, but also with benefits to some users. I think 37's process works better for web apps, were the user isn't actually downloading the app. This is a very casual sphere. But once I download an app, I want to be able to control it to the Nth degree if I want too, but the defaults should make me not want to.

Christopher Echanique - 4/23/2014 12:26:40

37signals philosophy follows some of the design concepts taught in the CS160 course, particularly the process of designing, prototyping, and testing. The reading contains chapters in the design process that provide advice to the readers on what to focus on when designing a software application. The author emphasizes the importance of focusing on the big picture of the application and not sweating the details like very specific elements in the user interface, implementing a ton of user preferences, or making the application scalable. This follows the CS160 process of designing an initial prototype. We focused on three important tasks that we would like the user to achieve with our app and centered our design from these tasks without sweating the minor details or problems we may or may not encounter. This leaves the refinements to be discovered in the testing phase of the design processes. The author also mentions the benefits of low fidelity prototypes, stating that it is much simpler to design a sketch or HTML markup of an interface than it is to actually starting coding the algorithms that the app will support. This makes design iterations from less costly to change.

One of the main differences in the 37signals design process is their method of user testing. They advise against formal usability testing as this presents bias; users generally do not perform well in front of a camera and may try extra hard not to make mistakes, which is what the designers want. Instead they advise to “test in the wild” and have a select number of users use a released version with some beta version features to test. This process differs from CS160 in that this course focuses on formal user testing to get feedback. The 37signals process is preferable when a released working version of the app exists and beta features can be added for testing. However this approach will not work for the scope of this course as time and resources are too limited to get this “testing in the wild”-type feedback with a released version.

Sergio Macias - 4/23/2014 12:43:52

They are similar in that both teach to create quickly, get feedback, and re-design. A bit point that 37Signals made was that fact that you must “Rinse and Repeat” in order to have a successful interface, which is very similar to the “Design Cycle” taught in CS160. The small choices in the beginning do not matter as much because most likely you will have to change them anyways. Another main point that is shared between the teachings of the two is the fact that you should choose a main idea for your app from the beginning and continually focus on that single idea and see if new features/ideas help push the original idea, if not scrap it. One difference I saw was the fact that 37Signals sees words as a good signifier: “It's a rare exception where words don't accompany design.” On the other hand, CS160 says words used as a signifier are a crutch. If you need words to describe an item on the screen, then the screen does not properly signify the affordance of that item. The 37Signals seems to be more geared toward web development while CS160 is more general design practices with a focus on Android Development.

Emily Reinhold - 4/23/2014 13:04:31

37signals design philosophy actually matches the design process taught in CS160 quite well. Below are some of the similarities and differences between the design process we've learned, and the one presented by 37signals.


- 37signals encourages application developers to build something tangible early. In CS160, we produced a low-fi prototype for this purpose. - 37signals recommends that developers focus their efforts on potential customers, since the success of the application depends on customers having an enjoyable experience while using it. In CS160, we focus our efforts on target users (in my case, athletic event statisticians). - 37signals follows the "Rinse and repeat" (work in iterations) design process. In CS160, we are following the iterative design process (design, prototype, evaluate, repeat). - 37signals encourages starting with a Brainstorm, then supplementing with paper sketches. We did this during the second week of CS160, brainstorming ideas for a sound-based application to build and including small sketches to flush out the ideas. - 37signals stresses the importance of testing the app with real users. We have done this several times in our CS160 iterations. - 37signals recommends designing for error state. In CS160, we learned from Nielsen's Usability Heuristics that we ought to "Help users recognize, diagnose, and recover from errors".


- 37signals encourages developers to come up with a one sentence vision that explains the goal of the application. CS160 does not require that, though it may have been useful instead of having to explain our application and its use-case in every assignment. - 37signals suggests releasing beta features to a select few inside the application. Since we don't have users in CS160 yet, this is not possible. - 37signals endorses an epicenter design sequence, where the core part of the application is designed first. CS160 did not specify an order in which we ought to design our application pages. - 37signals notes the importance of designing for the blank state. CS160 did not mention this explicitly, but Brittany mentioned it during our design review. This is particularly important for applications that intend to be businesses and need to secure customers. - 37signals preaches "Context over Consistency", in that decisions about design should be made with respect to the context, not simply to be consistent with other standards. In CS160, Nielsen's Usability Heuristics taught us to be wary of "Consistency and Standards".

The 37signals design process is preferable to the design process taught in CS160 when the application's aim is to be profitable. If the application's intent is to grow in popularity and gain users, designing for the blank state, releasing beta features, and embodying a true vision as a company that users can relate to is extremely important. In CS160, our application is aiming to solve a problem using the use of sound input, but we aren't aiming to gain tons of users. Thus, it is less important for us to roll out features gradually, and embody a vision.

Seyedshahin Ashrafzadeh - 4/23/2014 14:00:47

37signals philosophy of design process is to come up with a big idea, ignore the details at the beginning, worry about the possible problems when they are, hire the right customers, scale later, and make opinionated software. Based on their philosophy, having a big idea and vision will guide the decisions that we make and will keep us on a consistent path. They argue that paying attention to the details at the beginning might prevent us from progressing. They argue that these details will reveal themselves as you are building your app. You will know what is missing and what needs to be improved as you build your app. And paying attention to details at the beginning will just hinder us from progressing. The next point that 37signals make is a little similar to the previous one. We should not waste time on the problems that have not occurred yet. We should not overbuild. We need to increase hardware and system software as necessary. The next idea is to focus on a specific target group and scale our app whenever it is hitting its limits. At the end 37signals believes that we should not build an app which tries to satisfy everyone because it is very hard to do that. But they believe that our app should take a side and focus on the vision of that particular target group. Comparing this philosophy to the design process in CS160, I thiink that 37signals is also trying to follow the design and prototype phases somewhat. But the evaluation part is not very clear in their philosophy. Similar to cs160 method, they also believe that they should focus on a specific target group and design specific apps for that particular group. Also, they do not pay attention to the details at the beginning. This resembles the low fidelity prototype phase of our process. They start with some low-fidelity prototype and they iterate on it. They do not begin by making the whole app (high fidelity). However, it was not very clear from their philosophy that they evaluate their prototypes. It seems like that they try to have a product as soon as possible and worry about the details later. I think that 37signals philosophy is good when the group is under time pressure and they have to have a product out very soon. Then they can iterate on their product and make it better. I think this is because in industry it is important to have the first product among your competitors. As they say, "Running software is the best way to build momentum." They first brainstorm, prototype in paper, then HTML screen, and then code it. Then they release beta version and test their app with real world data, not as a formal usability testing. This is because they think if you stand by someone's shoulder, they are either careful to not make mistakes or don't perform well because they are in front of another person.

Max Dougherty - 4/23/2014 13:32:46

The 37signals philosophy tends to follow the classic Design, Prototype, Evaluate cycle taught in CS160 relatively closely. 37signals therefore also stresses the importance of iterative product creation to ensure a steady stream of feedback from the user base. This similarity is further extended to the identification of the important tasks. The “stories” mentioned in 37signals closely resemble the user stories we used in CS160. A major difference between the CS160 and 37signals comes from the way in which the user’s desired features are incorporated. 37signals, attempts to include only features which are necessary for functionality, while CS160 puts more power in the hand of the user and attempts to incorporate all of their desires. In this way, 37signals gives a greater control to the designer and allows them to use their experience to make decisions without consulting the user. Although problems may arise when tested with users, this reduced communication allows for a lower turn-over rate of iterations. The result is often a product with more directed purpose. While not as flexible, the product is likely a more effective product for its scope, as opposed to a more generalizable solution. In my opinion, the 37signals approach is preferable when the user is not entirely aware of their specifications and can only provide a vague series of specifications. In these cases, it can be more productive to give a higher degree of freedom to the designer to make design decisions in a way which is abstracted from the user.

Bryan Sieber - 4/23/2014 13:37:14

Both the 37signals and the cs160 design processes are similar in the fact that they use multiple iterations with a designing process followed by a coding process. 37signals focuses on building and testing multiple functioning versions of the product, but testing is less formal. 37signals also has a clear vision in mind for the product as they continue with ongoing development. In cs160 there was more of a focus on the ideating strategies and observation techniques, with the goal in mind of finding out what the users truly are doing and what would make their experience better. I think the 37signals process is preferably to the cs160 process when there is a time crunch, such as startups. The cs160 process is better for larger companies that are in less of an immediate threat to competition, so that they have time to more accurately create a better solution for the users.

Brenton Dano - 4/23/2014 13:44:22

The 37sig philosophy of Rinse and Repeat matches the iterative design cycle taught in CS160. Also, the "get something up and running quickly" reminded me of our high-fidelity prototype. I think we might have spent too much time on the low-fidelity prototype when we should have coded first. It was only until recently did our group start solving a lot of critical problems in design and this happened because we are pushing code to our Github and collaboratively solving problems.

In the "From Idea to implementation" section of the reading, 37sig talks about the brainstorm phase which involves sketching and not rejecting crazy ideas, and then they say they use HTML to do the lo-fi mockups and then code it to have the necessary functionality. This is pretty similar to what we learned in CS160.

The "Test in the Wild" section reminded me of the User tests our group has been doing over the past few days for the Pilot Usability study.

37sig idea of "Epicenter Design" wasn't really emphasized that much in CS160. It actually reminds me of the sketching we learned except in software engineering. Focus on getting the things the app can't live without done first and then focus on the details. This is actually what our group did for our project. We focused on the main screens first and then are doing the details later.

The "Three State Solution" is a new idea that I learned from the reading that wasn't talked about in CS160. The blank screen state is something that our group had to deal with while designing our app because it looked sort of plain before the user entered in lines from their script.

I think the 37sig process is preferable to the one taught in CS160 if you are wanting to a start up in the real world. To get money from VCs you are going to want to have a robust MVP early on that you can iterate on. The ebook talked a lot about getting code first to increase moral so it mentioned things that we are not necessarily going to focus on in an academic setting. I think if I ever wanted to create a startup I would have all my employees read the 37sig book from cover to cover. I really enjoyed this reading! :)

Diana Lu - 4/23/2014 14:06:53

The 37signals philosophy actually matches a lot of the design process that is taught in CS160. They prioritize having an understanding of the focus of the application and its target audience before setting out on developing the app. The development process also has some similarities, as they start with lo-fi prototypes and work their way up to hi-fi working prototypes. However, there are also some differences. For example, 37signals says that interface decisions should be made with clarity, and a developer should choose. This process seems to be less flexible to the more iterative one that we've been taught to follow in CS160. I think that overall 37signals has a much more rigid design structure to developing applications, while the process followed in CS160 is typically more relaxed and open to change. 37signals design process may be preferable to the CS160 when it comes to real world application development, which may have to adhere to strict schedules and budget. I believe that the 37signals philosophy is more tailored to this.

Sijia Li - 4/23/2014 14:09:21

1. How does the 37signals philosophy match the design process taught in CS160?

In short, the 37 signals matches the design process taught in CS 160 for the most part.

For example:

  • (1) A focused mission statement (From Chapter 4, "What is the big idea" section): Explicitly define the one-point vision for your app. Both CS 160 and 37signals point out that it is critical to have a clearly-defined mission statement at the very first stage before any step.
  • (2) Targeted user group (From Chapter 4, "Hire the right custom" section): Find the core market for your application and focus solely on them. Both CS 160 and 37 signals emphasize that focusing on a particular targeted user group, instead of targeting general public, is very important for the developers to keep the application focus on the mission statement.
  • (3) Design-Prototype Iteration (from Chapter 6, " Rinse and Repeat" section): Work in iterations. Both CS 160 and 37signals all emphasize the importance of repeated iterations. In CS 160, the loop goes like "design -> prototype -> evaluation".
  • (4) Brainstorm (from Chapter 6, "From Idea to Implementation" section) Go from brainstorm to sketches to HTML to coding. 37signals also puts a big weight on Brainstorm. It suggests the initial UI design process should go like "Brainstorm -> Sketches -> HTML -> Coding". In CS 160, we also started the whole group project from Brainstorms and then use Balsamiq to make mock-up interfaces and then write HTML for Android applications. So, in CS 160, the process is like "Brainstorm -> Balsamiq mock-up interfaces -> Android HTML files -> coding".
  • (5) Implement UI first (from Chapter 9, "Interface First" section): Design the interface before you start programming. The 37 signals' reasoning is that programming is the heaviest component of building an app, meaning it's the most expensive and hardest to change. Instead, we should start by designing first. In CS 160, this is exactly we did. We made low-fidelity prototype first before we started to write HTML files and Java files.

2. How does it differ?

The biggest difference I noticed is that 37signals put a huge weight on repeated real-world tests. In other words, 37signals does not really appreciate formal usability testing, because 37 signals believes that "formal usability testing is too stiff and lab settings don't reflect reality" (Chapter 6, "Test in the wild" section).

In Chapter 6 "Test in the wild" section, 37signals emphasizes that there's no substitute for real people using your app in real ways. Get real data. Get real feedback. 37signals also points out that if you stand over someone's shoulder, you'll get some idea of what's working or not but people generally don't perform well in front of a camera. When someone else is watching, people are especially careful not to make mistakes — yet mistakes are exactly what you're looking for.

3. When is the 37signals process preferable to the one taught in CS160?

I believe that for startups the 37signals process is preferable to the on e taught in CS 160, because startups need to have the (beta version) product come out as soon as possible. It is totally fine if the beta version has some errors or not-so -good designs. Startups can continuously work on improving their beta version product once they have one beta version product ready to release.

For startups, the build process is more like "design -> implement -> get feedbacks -> redesign -> implement -> get feedbacks ...", which mainly focuses on the implementation part since the product is the core.

Sijia Li - 4/23/2014 14:11:17

1. How does the 37signals philosophy match the design process taught in CS160?

In short, the 37 signals matches the design process taught in CS 160 for the most part.

For example:

  • (1) A focused mission statement (From Chapter 4, "What is the big idea" section): Explicitly define the one-point vision for your app. Both CS 160 and 37signals point out that it is critical to have a clearly-defined mission statement at the very first stage before any step.
  • (2) Targeted user group (From Chapter 4, "Hire the right custom" section): Find the core market for your application and focus solely on them. Both CS 160 and 37 signals emphasize that focusing on a particular targeted user group, instead of targeting general public, is very important for the developers to keep the application focus on the mission statement.
  • (3) Design-Prototype Iteration (from Chapter 6, " Rinse and Repeat" section): Work in iterations. Both CS 160 and 37signals all emphasize the importance of repeated iterations. In CS 160, the loop goes like "design -> prototype -> evaluation".
  • (4) Brainstorm (from Chapter 6, "From Idea to Implementation" section) Go from brainstorm to sketches to HTML to coding. 37signals also puts a big weight on Brainstorm. It suggests the initial UI design process should go like "Brainstorm -> Sketches -> HTML -> Coding". In CS 160, we also started the whole group project from Brainstorms and then use Balsamiq to make mock-up interfaces and then write HTML for Android applications. So, in CS 160, the process is like "Brainstorm -> Balsamiq mock-up interfaces -> Android HTML files -> coding".
  • (5) Implement UI first (from Chapter 9, "Interface First" section): Design the interface before you start programming. The 37 signals' reasoning is that programming is the heaviest component of building an app, meaning it's the most expensive and hardest to change. Instead, we should start by designing first. In CS 160, this is exactly we did. We made low-fidelity prototype first before we started to write HTML files and Java files.

2. How does it differ?

The biggest difference I noticed is that 37signals put a huge weight on repeated real-world tests. In other words, 37signals does not really appreciate formal usability testing, because 37 signals believes that "formal usability testing is too stiff and lab settings don't reflect reality" (Chapter 6, "Test in the wild" section).

In Chapter 6 "Test in the wild" section, 37signals emphasizes that there's no substitute for real people using your app in real ways. Get real data. Get real feedback. 37signals also points out that if you stand over someone's shoulder, you'll get some idea of what's working or not but people generally don't perform well in front of a camera. When someone else is watching, people are especially careful not to make mistakes — yet mistakes are exactly what you're looking for.

3. When is the 37signals process preferable to the one taught in CS160?

I believe that for startups the 37signals process is preferable to the on e taught in CS 160, because startups need to have the (beta version) product come out as soon as possible. It is totally fine if the beta version has some errors or not-so -good designs. Startups can continuously work on improving their beta version product once they have one beta version product ready to release.

For startups, the build process is more like "design -> implement -> get feedbacks -> redesign -> implement -> get feedbacks ...", which mainly focuses on the implementation part since the product is the core.

Haley Rowland - 4/23/2014 14:15:17

The 37signals philosophy aligns with the process taught in CS160 in many ways. For example, 37signals' chapter "Priorities" focuses on picking the right customers, and in 160, that idea is reflected in choosing a very targeted user group. This idea is again reflected in 37signals' "Test in the Wild", which is what we've done through Contextual Inquiry and Pilot Testing. The "worrying about the details later" idea mentioned in 37signals reflects 160's design process through sketches, then balsamiq mockups, then prototypes. Also, the "Race to Running Software" approach was echoed in using hard-coded or wizard of oz techniques when prototyping to just get a sense of how the app would work. Iterative design cycles were also emphasized in both approaches.

I like 37signals' notion of deciding the little details so the customers don't have to- I think in 160 we rely heavily on target users to inform our decisions, and sometimes it may be an executive decision the designers should make. Another part of 37signals' process I thought could be incorporated into the 160 design process is "defensive design" and considering "regular, blank, and error states".

Alexander Chen - 4/23/2014 14:21:42

CS160 and the 37signal's philosophy align for the majority of the articles that were reviewed for this assignment.

For example, during the brainstorming process to develop our application's main goal, we were told to ignore the details at this point and to, simply, shoot for quantity over quality. We would have time to refine our ideas laters.

Later, we determined our target users using personas and the list of considerations: "what tasks do the users perform now, what are time constraints with the interactions, etc." This helped us understand what kind of interface we would have to build, what kind of jargon to use, and helps us focus on pleasing this user group. 37signals calls this "hiring the right customers" and "making opinionated software".

Later in the process, we went through a low fidelity mockup and test process, followed by an interactive prototype and pilot usability test. In this process, we focused on design before the software implementation, we worked in iterations, we tested our application in the wild.

There are some differences in between the two philosophies as well. While we had many iterations of the design, we didn't have quite as many iterations to focus on the final product. We didn't go over only having one interface for settings and the main app activities. We didn't go over regular, blank, and error states.

When there is more than 14 weeks to the software development process, we could probably utilize the 37signals process. With the time constraints, CS160 had to make a tradeoff and focus on the prototyping and inquiry processes. This was fair because other courses, such as CS169 go over iterative software development process in detail.

Sang Ho Lee - 4/23/2014 14:23:10

The 37signals philosophy is more similar to the design process taught in CS160 than different. Both philosophies begin the design process by brainstorming ideas and emphasize focusing a core feature marketed towards a narrow audience, keeping in mind that the product should not and will not please everyone. Both design processes emphasize low-fidelity prototyping early on, because coding is difficult and walls you in. Of course, design iteration takes the highest priority. It serves to bring existing interface elements to a higher level of fidelity and usability, and also introduces additional features into the UI. There is also an emphasis on "interface-first" design in both philosophies. Both design processes also focus on real-world testing. As we did low-fidelity testing and pilot user test, 37signals also recommends pushing unpolished products out to limited user bases to test out the features. The two philosophies differ a bit when it comes to the coding process. While the 37signals philosophy recommends breaking apart coding into small components to emphasize continuous, productive coding sessions, CS160 failed to provide as much guidance on how to break up the coding work time-wise. Instead we were given a general timeline on finishing up coding functionality, which may lead to procrastination and inefficiency. 37signals also discusses the "blank-slate" state of an app. This was an interesting (and valid) argument on designing for the blank-slate which every user may encounter with a data-centric app. CS160 did not mention the blank-slate possibility within our apps, which may have been helpful when initially making our mock-ups.

The 37signals process is more preferable when working in a bootstrapped start up environment. It emphasizes small-scale, working code and offers pushing our products that may be only 80-90% finished without a separate beta version for increased real-world user testing. While this may be excusable in a startup context, this kind of head-first approach may not be most appropriate in with more established, larger companies where users expect the highest standard of usability and content from their products. Because startups usually start with 0 users and build up from there, scalability may not be an issue initially, but companies with existing user bases must take scalability and user satisfaction very early on.

Dalton Stout - 4/23/2014 14:29:53

I noticed several practices discussed in the mini-essays that seemed to align with philosophies taught in CS160:

  • In the Priorities section 37signals says that at the start of a project it is a good idea to ignore the details and focus on the big picture. This is similar the 160 philosophy of low-fidelity prototypes, using sketching to create mock ups of your app.
  • At the start of 160 after our brainstorm, we were told to chose a project that had a very specific target user group. This is similar to the 37signals philosophy that you should 'Hire The Right Customer" and focus solely to them, don't try to please everyone.
  • The Rinse and Repeat section has almost exactly the same description as agile programming. It suggests many iterations with constant improvement and rapid software launches.
  • Signals encourages readers to Brainstorm and use paper sketches to articulate and model our ideas. We spent a lot of time on this in the first half of the semester when we were create low-fi mock ups.
  • Finally, in 160 we have tested our app in real world situations at 3 various stages of development. This is the advice that is given in the Test in Real World Situations section.


  • The language that is used in the Have Opinionated Software did not seem to match the priorities taught in 160. They seemed to encourage developers to have an edge, and be unapologetic (even inflexible) with their app vision. This does not seem to align with the 160 interview techniques and constant revisions to features after feedback.
  • The Context Over Consistency section also seemed to stand out compared to the 160 teachings. The essay seemed more wonton about maintained consistency standards. In some of the readings and in lecture we were taught that changing consistency/convention (e.g. using OK on to enter some forms but SUBMIT to enter others.) should be avoided so as not to confuse the user.

From the few differences I have gleaned I would say that the 37signals process is preferable for producing edgier, younger products. Context Over Consistency would not phase younger users who are familiar with the interfaces and use apps rapidly. the recommendation to Have Opinionated Software could backfire unless your 'vision' is really quite good. Sometimes to have clear, consistent design is better than having an edge, though sometimes it's not.

Maya Rosecrance - 4/23/2014 15:00:42

For the most part the design processes match up. Both emphasize prioritizing quick iterations and getting a semi-working product quickly so that testing can be done. They also both address the time it takes for users to make decisions and emphasize the value of user testing. There are several differences however. In class we often had to define what app we were making but we didn't have to distill it down to a one point vision for our app. Also 37signals does not specifically use the design-prototype-evaluate cycle and while they mention that brainstorming, prototyping and evaluation is critical and it must be repeated, it isn't presented as a three step cycle to be repeated over and over. The three state process is perhaps preferable to the method taught at Berkeley because it addresses three common states that developers and designers should think about and helps frame the app from the point of view of a user.

Namkyu Chang - 4/23/2014 15:04:58

How does the 37signals philosophy match the design process taught in CS160?

37signals philosophy in the design process is as follows: brainstorm, make paper sketches, create HTML screens, code. As well, recall the design process taught in CS160: design, prototype, evaluate. The two are similar in that both processes encourage initially sitting down to think through the ideas through paper sketches/brainstorming/designing. In addition, they both encourage creating a prototype (HTML or other prototyping tools) to test out some of the features and methods that came out of the previous phase.

How does it differ?

However, there are some key differences between the two processes: 37signals doesn’t really mention an evaluation phase, and explicitly states that HTML and CSS should be used instead of other possibilities (like balsamiq). In this sense, the method taught in CS 160 can be applied to broader categories of products and not just limited to software (e.g. IDEO is designing a new shopping cart. How would they do this through HTML and CSS?).

When is the 37signals process preferable to the one taught in CS160?

37signals process is preferable to the one taught in CS160 if the product we are trying to create is a web product, and is relatively simple. This way, the missing component in the 37signals’ philosophy, evaluation, is not necessary to make the perfect product. As well, it would have to be a software web since we need to do everything in HTML and CSS to prototype.

Chris Schechter - 4/23/2014 15:06:23

The 37signals philosophy is similar to the CS160 design process in its focused early stages--much like we are taught in CS160 to start with lo-fi mockups and focus on critical tasks, 37signals advises to ignore details early on and work out problems only as they arise. However, they also explain in the section "make opinionated software" that you may ignore some customer feedback to preserve the vision of the product, which is contrary to how we learned of the importance of user feedback in this class.

The entire "Process" section is very similar to what we learned in class as well. 37signals advocates rapid prototyping and an iterative process, and details how to go from brainstorming to mockups to prototypes to user testing. I thought their idea that giving the user options is just a "way to avoid making tough decisions" was interesting, as they seem to imply that the developer often knows what's best. I think this is often a good idea--when working with some software, the amount of options and sheer multitude of ways you can accomplish a single task only make it more confusing and detract from user friendliness. Still, taking too many options away can make an app much less useful too.

I like 37signals' interface design principles. They are all things we have learned about at some point throughout the class, mostly having to do with focusing on critical tasks and keeping everything as simple as humanly possible. One point that stood out to me was the "context over consistency" section, which is something I often overlook in my own designs. They make a good point that you should always design your interface to best represent the information you wish to convey, even if that means breaking a different design rule once in a while.

Justin Chan - 4/23/2014 15:08:10

For one, the 37signals philosophy is all about constant iterations, which heavily mirrors the design cycle we were taught in class. Both methods involve rapid cycles of launching a product, evaluating it, and making tweaks on the fly. This approach segues into another similarity between the two methods -- focusing on the big picture. The goal of both these 2 methods is to scale down the requirements into big, actionable, achievable tasks. Intricate details are not given a relatively high priority because those can always often be tweak later -- the important issue here is getting those big ideas out. In CS 160, one example of this can be manifested in low-fi prototypes. As discussed in lecture, the purpose of lo-fi prototypes is to get a gist of how the product is going to work, not necessarily what the final designs are. This focus on functionality makes sure that the product is the best product it can be, while the more "aesthetic" portions of the app can always be done later. 37signals preaches the same philosophy -- paring down the app into those simple building blocks allows developers to focus on what actually matters. The proverbial "icing" on the cake, again, can always be done later. An app with a strong foundation, albeit with not the best aesthetics has good long-term prospects. One with the opposite attributes may have short-term benefits, but is setting itself up for long-term failure.

Where the two start to diverge is 37signals' insistence on keeping everything small. The 160 design process does not necessarily preclude scalability -- it is just a framework for the design process. Though it may be harder for 100 people to agree on an idea and push out an iteration as opposed to 10, the 160 framework is still applicable in both situations. A giant company such as Google can still employ the design methodology we learned in class. However, 37signals' insists on keeping everything as simple as possible -- less mass, less software, less features -- probably not Google's forte.

37signals process is preferable in a start-up environment, where there runs a very high risk of "wastefulness." The inherent lack of structure means that situations can go awry pretty quickly -- people can get bogged down in minutiae, the app direction can be steered off course, etc. Keeping everything pared down and everyone on the same track would be beneficial in these situations. For larger companies, "going small" is simply not an option.

Stephanie Ku - 4/23/2014 15:11:19

There are several differences and similarities between 37signals philosophy and the design process we were taught in CS160. Firstly, the 37signals philosophy emphasizes this concept of ‘rinse and repeat’, which is identical to our design process’s iterations. The idea is to constantly iterate and build on new ideas. Furthermore, the overall schema for 37signals is similar to our design cycle. 37signals is “Brainstorm – sketch – html screens – code”, this is similar to our traditional design cycle where we brainstorm, prototype, then build. Similarly, 37signals believes that decisions are temporary, so it is important to just make the call and move on. If users are unhappy with certain aspects, they will complain and we can then iterate on it. This is adjacent to our idea of fast iterations such that we can get fast feedback from customers. Finally, 37signals accentuates the importance of testing the application in real world usage. Our design process also emphasizes the need to do usability tests in a real world setting with real users. This is the best way to gain insight on a user’s feelings and ideas.

However, there are definitely differences between their philosophy and ours. Firstly, 37signals emphasizes “Race to running software”. Our traditional design cycle does not push developers to develop straight off the bat without prototyping or discussing beforehand. In addition, the 37signals philosophy tells us to avoid preference. They want us to decide the small details for the users and neglect the user’s preferences. This differs from our design cycle where we consistently iterate on the user’s preferences and thoughts. While they make a lot of the calls for the user, our design cycle is user-centric, meaning that we put the user’s preferences first. Lastly, 37signals wants you to ‘shrink your time’ whereas our design cycle wants much more discussion and planning.

Ultimately, the design process we learn in CS160 can be applied to almost any time of application/system we want to build. However, the 37signals philosophy is geared towards web applications. This means that many of their main process points, such as ‘race to running software’ is much more applicable to web applications. Therefore, the 37signals process is preferable to the one taught in CS160 when it comes to web applications. This is because web applications lack many of the limitations that come with building on other platforms, such as mobile. These limitations include pushing to the customer. Pushing to the web versus pushing to an app store is a much faster process. Thus, it is 37signals’ philosophy is arguably more applicable and preferable to ours in the context of webapps.

Jay Kong - 4/23/2014 15:22:05

The 37signals design philosophy is extremely similar to the design process taught in CS160, and even ME110. Although they didn't use the terms "design -> prototype -> evaluate", the core ideas remain the same. 37signals encourages low-fidelity prototyping by telling us to "design first before starting the programming". They advise us to brainstorm and prototype as soon as possible without worrying about the larger picture such as scaling. They also advise us to get real feedback by testing a working prototype with the correct users.

However, the process differs in when we should test with users. In the design process provided by CS160, we are encouraged to build extremely low fidelity prototypes (paper ones) and test it with the user. In the process suggested by 37signals, we should build a low fidelity working prototype and test it with the user. In other words, something like a paper prototype won't cut it, but rather, a prototype with actual working code (which is similar to our interactive prototype). In essence, the point in which we start getting user feedback differs.

The 37signals process is great for building a product with limited resources such as manpower and time. The process is geared toward building what we would call a minimum viable product, something customers would be interested in paying in. While as in CS160, we don't really have similar constraints. There is no pressure for us to build something that will sell.

Emily Sheng - 4/23/2014 15:26:04

The 37signals philosophy very closely matches the design process taught in CS160. Both processes emphasize designing rapidly with mockups in the beginning and not getting stuck on the small details. Another similar aspect is that both processes focus on the continuous process of narrowing down a very specific target user group. Designing general software for a broad group of people is never a good idea, because there are just too many types of users that the application has to keep in mind. The one aspect that the 37signals philosophy focuses on that CS160 does not as much is the testing of our application in the real world. We do go through a couple of prototype tests and usability tests, but ultimately are bounded by the availability of time and users to test on in CS160. In addition, the 37signals process recommends not doing formal usability testing with many observers watching (and instead mixing beta features with real features and releasing the app to certain people), because people would be more careful about not making mistakes. Although this method is different from how we performed usability tests in CS160, it is preferred as the results would be from a more natural setting.

Seth Anderson - 4/23/2014 15:30:29

The 37signals philosophy is similar to that of CS160 in that it does follow the same general steps of Design, Prototype and Evaluate, however the priorities assigned to each of these are different. The 37signals emphasizes most of it's time on the prototype, having a rushed software version out before many of the design kink are worked out. Every step of the process in fact is more focused on getting the software done and dealing with the consequences later.

The 37signals process would be more useful if it was used for software that needed to be rushed to market, maybe to prevent copycats or address some immediate need. The process allows software to be completed quickly and improvements to be made later rather than before the app is released.

Sol Han - 4/23/2014 15:35:53

The 37signals philosophy takes a very do-it-first approach to development. While it discusses pre-implementation processes such as brainstorming and sketching, it also encourages developers to not be overly concerned with unimportant or irrelevant parts, such as non-central features of the app or scalability issues. Instead, the 37signals philosophy emphasizes the importance of rapid iterations and experimentation to attract an initial user base, so that there is actual potential for the application to become popular and grow in the future. This requires taking a top-down approach, where the developers get a big picture of what problem they want to solve, and prioritize tasks by importance to accomplish that task.

The 37signals process shares many similarities to that taught in CS160. It follows the similar flow of the Design-Prototype-Evaluate discussed in class. 37signals's analogue of the CS160 Design process involves brainstorming and sketching of ideas, though these steps aren't all too thoroughly covered in the chapters assigned for this reading. The Prototype stage involves making prototypes, such as in HTML/CSS. User feedback is important for the Evaluate process, since the design cycle will involve many iterations.

Moreso than in CS160, however, the 37signals approach likes developers to make decisions. Being wishy-washy with factors such as user preferences hinders development because it causes developers to stray from the essence of the app and its main goal, instead causing them to focus on issues that may not be relevant except in the far future ("It's a Problem When It's a Problem"). Maintaining momentum is crucial; 37signals recommends methods such as chunking up the development timeline to set periodic deadlines ("Shrink Your Time"). Furthermore, 37signals does not put much of an emphasis on surveying the target audience during the design process, instead suggesting that the developers make design decisions and work with user feedback. The 37signals process is advantaged over the CS160 process in that it is more concentrated on getting a tangible product out, fast. Having these small but visible results can motivate developers. Also, the focus on making executive decisions quickly and efficiently can be useful in cases where developers are having trouble narrowing down their options and coming to an agreement about the direction of their app, a problem more likely to occur with the CS160 approach, which is largely concerned with gathering different perspectives from potential users.

Robin Sylvan - 4/23/2014 15:39:31

The 37signals philosophy matches the design process taught in CS160 in many ways. They focus on creating quick prototypes – even mentioning paper sketches in the design phase. They ask us to create a UI design before coding it, though they mention creating it in HTML as 37signals is based upon creating a web application. The book also mentioned that we do many iterations of a product, and work on creating very small tasks as milestones for larger projects. Their design principles are quite similar to the design, prototype, evaluate format of this class. At the same time, I believe that 37signals might exaggerate how lax one should be on good programming principles. They seem to focus very much on quantity and speed of coding over trying to ensure that your app follows good principles so it can scale when the time comes. I understand that their goal is to push product out as fast as possible, but I believe that CS courses in general at Berkeley put a greater focus on putting out quality code. While CS160 hasn't focused hugely on it, many classes at Berkeley do want us to ensure proper testing, while 37signals appears to gloss over it. Also, 37signals is focuses on testing out in the real world, instead of running user studies on earlier iterations of the application. In CS160 we have focused a lot more on completing and testing features with a subset users before they are released to the general public. The 37signals process may be preferable to processes taught in CS160 when working on a web application. Android applications do not enable fast, automatic bug fixes the way a web application does – an android user has to re-download the entire app upon bug fixes or updates, while a web user only needs to visit the site again. Also, 37signals focuses on being in close contact with their customers. While Android applications do have features for providing feedback and sometimes sending users emails, the company ↔ user feedback loop is more obscured. When building Android applications, one generally places a fully-featured application upon release, while building web applications provides opportunity for more agile development.

Andrew Chen - 4/23/2014 15:40:52

The 37signals philosophy matches the general flow, or three stages, of the design process taught in CS160. Similarities between the two include the concept of developing in iterations, usually short (weeklong) projects, the importance of brainstorming and focusing on big ideas at first rather than details that may matter later on down the road, and also the idea of narrowing the target user base. However, the 37signals philosophy is a lot more detailed in terms of describing the design process. It makes statements about how opinionated and customized software is better than neutral and customizable software. In addition, it differs from the CS160 design cycle in that it proposes the idea of releasing beta features with the real application so that users can use test these new features with real data and workflow. Also, it questions the accuracy of formal usability testing, pointing out the effects that direct observers have on the participants. The 37signals philosophy is preferable if the application targets a more specific user base, such as those in the corporate world. Much of this is due to the emphasis it places on the specificity in the application, whether it be provided features or target users, and also because of the idea of beta testing. Consumer applications have beta features too, but since their target user base is typically much more general, the specificity guidelines are less stringent.

Erik Bartlett - 4/23/2014 15:45:23

The design process proposed by 37signals is essentially the same as taught in class: Design, prototype, evaluate - with a few ideological differences. 37signals focuses on getting a more high fidelity prototype out, as opposed to the prototype/mockup/sketch version that we went over with class. Their testing philosophy, sprinkling in “beta” features with the regular app is also something different - where we generally test out a whole beta version by itself (this might just be because we were developing 1 application from scratch). It also seemed like basecamp suggests committing to an idea as soon as possible, “Decisions are temporary so make the call and move on.”

I feel like one example where it is preferable would be something like a hackathon - where you need to get out a product asap, so you have to work on making the application while you’re still unsure of all of your design ideas. That is the main advantage I see from this design process - the ability to have a working product very quickly. So having a very quick deadline is the main use case for this type of development.

Anthony Sutardja - 4/23/2014 15:48:22

"Working form large to small" is a lot like the prototype cycle. In the design process in CS160, we start with low-fidelity iterations of our product to flush out the major issues of functionality rather than design. In the 37signals article, they similarly address this by noting that you shouldn't focus on the tiny details, which may end up be for nothing if the functionality turned out to be flawed.

The 37signals article also suggests to "get something real up and running quick," which is basically the motto that the CS160 process has guided us through as well. This follows with the advice to work in iterations. In CS160, we followed the a design cycle that required us to do many iterations very quickly.

The 37signals article is also similar to our CS160 process of finding the target audience. The article calls this "hire the right customers," where the product shouldn't try to please veryone. In CS160, our process was to focus on a very particular user group. After finding this target group, the 37signals article also tells us that we should get real world usage with this group (just like we did in our class).

One way in which the design process was distinct from the one we learned in class was that they were building products for people on the web. In the article, they say to choose the little details so the customer doesn't have to. Although this process is not a method particularly mentioned in CS160, it is intuitive to make choices based on the interview proccesses that we went through in our class.

Shaina Krevat - 4/23/2014 15:57:35

Overall, the design process of 37signals is a relaxed, non-technical version of the design-prototype-evaluate process we’ve learned in cs160. They have advice that is very similar to what we’ve heard in cs160, like “Focusing on a Core Market,” which is comparable to the ideas of target users and personas as discussed in class. This philosophy also stresses iterations, much like we’ve been taught and experienced firsthand in cs160. The “From Idea to Implementation” strategy is also similar to the brainstorming and prototyping steps we’ve had. The only significant difference I found in the 37signals strategy is their “Race to Running Software”. For class, we spent a lot of time designing the UI of the software, creating prototypes, and testing ideas for the users before actually implementing them, but it seems this strategy stresses getting the product working and then worrying more about how to make it look.

While the strategies are very similar, the 37signals process is clearly geared for start-ups, where time and man-power is limited, and stresses getting the product out to general public as fast as possible and iterating based on that, as opposed to expensive user tests with a limited sample size.

Emon Motamedi - 4/23/2014 15:57:58

The 37signals philosophy has a number of similarities to the design process taught in CS160. For starters, 37signals really encourages designers to hone in on what their major purpose behind their application is and work from there, which is something that I feel CS160 does as well in having us focus on 3 tasks of our application. Within the actual design process of 37signals, even more similarities make themselves apparent. Like 37signals, CS160 taught us to sketch out all of our ideas first and then begin coding, to consistently iterate to improve our application, to test the application in real world situations, and to minimize the time taken by breaking down the different aspects of the application.

However, with these similarities, a number of differences make themselves apparent. It appears that 37signals puts of certain aspects of the creation process until they are absolutely necessary. This is seen in their motivation to ignore details at the start, to avoid problems that are not completely debilitating, to not worry about scale, to get software running as quickly as possible regardless of quality, to avoid giving customers preferences, and to make decisions with the intention of revisiting them later. These philosophies differ from that of CS160 as I feel that CS160 really encourages us to put time in contemplating and implementing a lot of the aforementioned factors that 37signals quickly brushes over. For this reason, 37signals process is probably preferable to the one taught in CS160 when an application needs to get implemented quickly and the high-level details are more crucial because of this need for quick creation.

Gavin Chu - 4/23/2014 16:09:27

The 37signals philosophy definitely captures some of the key design process taught in CS160, but it seems to cover everything very holistically. The 37signals philosophy basically suggests designers to rapidly produce a product with the minimal requirement. It constantly emphasizes building less and getting done what is needed now. It even mentions less testing (but more strategically, meaning only test when a problem occurs). This is different from the design process we go through in CS160 where we perform testing at set intervals of time.

One concept in line with CS160 is the importance of satisfying the users. The 37signals philosophy suggests making changes according to the users need. That means don't add extraneous features, such as preferences, until a lot of users find the need for them.

I think the 37signals philosophy is a very easy approach to design. It gets the job done with minimal resources and minimal cost. However, I can see how it can also be very problematic. The 37signals approach really focuses on the present. It looks for quick small fixes to adjust to the users need, but it has a poor foundation. Any major problem might require the designer to start all over, which can be very expensive and time consuming.

In CS160, we learned to carefully think through our design before actually implementing it, for example performing contextual inquiry. Although our method requires more time and effort, it considers the past and the future because we have a deeper understanding of how the app could grow and change.

The 37signals philosophy is really more of a "get rich and get out" approach to design. It ensures present success, which might be what some designers are looking for, but it'll probably be problematic in the long run. The 37signals philosophy is analogous to cramming for an exam. You get what you want quickly, but the success fades away.

Ryan Yu - 4/23/2014 16:12:40

The design process taught in CS160 essentially consists of three primary stages -- design, prototype, evaluate (and repeat). And in a way, the 37signals philosophy matches this general structure. The first nine of so chapters of the 37signals philosophy, [The Starting Line, Stay Lean, Priorities, Feature Selection, Process, Organization, Staffing, Interface Design] all have to do with the general design of the application, and the process of taking into consideration all of the features/aspects that might make an application/company successful in the long run. For instance, one of the entries in chapter 4 includes "What’s the big idea? Explicitly define the one-point vision for your app", which is one of the big design principles for CS160 -- looking at your target users, and determining what *their* needs are. Furthermore, the chapters [Code, Words, Pricing and Signup] pertain directly to the "prototype" stage in the CS160 design process. Finally, the evaluation stage corresponds to the chapters [Promotion, Support, Post-Launch]

However, the 37signals philosophy seems to focus a lot of the actual internal workings and strategies of the team rather than its attitudes and strategies towards the application's target users. For instance, there is a lot of mention of things such like "It Shouldn’t be a Chore Your passion — or lack of — will shine through", "The Three Musketeers -- Use a team of three for version 1.0 ", and "Meetings Are Toxic -- Don’t have meetings". In this sense, the 37signals philosophy has to do a lot with improving the overall efficiency and teamwork of the team. That's not to say that it doesn't also deal with the attitudes and strategies of the team towards their product, but one other primary focus is the internal working of the team itself.

In a way, this makes the 37signals process preferable to the one taught in CS160, as the former provides teams with the guidance and knowledge that is needed to greatly improve efficiency in devellping the application. Furthermore, overall, the 37signals process is simply just more detailed, and deals with things that the CS160 process does not touch upon, such as hiring and promotion of the product/application. In this sense, I would say that the 37signals process is preferable when the application that your team is making is planning to be released in a widespread scale; rather, it is more applicable and helpful if the team that is releasing the application has *true intentions* to attempt to release the product on a wide scale, as it offers guidance on every part of the release cycle.

Lauren Speers - 4/23/2014 16:13:58

Like the design process taught in CS160, the 37signals philosophy emphasizes the value of iteration. In chapter six, the authors encourage designers to work in iterations because “Iterations lead to liberation;” working in iterations allows designers the freedom to try out a variety of ideas because it is not necessary to get the design right on the first try. The 37signals philosophy also includes some ideas that were not necessarily taught in CS160 but nonetheless support the idea of designing in iterations, like the ideas of ignoring details at the start of the design process and worrying about scaling only after early iterations of the app have been successful. Furthermore, like the process taught in CS160, the 37signals philosophy encourages designers to think about their target users and select a core market, warning that trying to please everyone or trying to design software to be as flexible as possible will leave the app without any satisfied users.

Unlike CS160, the 37signals design philosophy places much more emphasis on quickly building a working version of the application, even before details have been finalized or important decisions have been made. The philosophy encourages designers to “Race to Running Software,” skipping details and taking shortcuts in order to have real running software, which will hopefully spark new ideas and aid communication between team members. The philosophy does not ignore the brainstorming and mock-up process, in fact they suggest one similar to that which we followed in CS160, but they instruct designers to work through this process either more quickly than we did in CS160 or at the same time as designers are building the first iteration of real software.

37signals philosophy would work well in a start-up environment. Large companies with a large customer base would have a more difficult time narrowing their customer focus, and they would not be able to design as quickly as 37signals suggests because they cannot risk deploying a less than satisfactory product to their customers. Start-ups, on the other hand, do not yet have customers relying on their products and can use that benefit to experiment and move as quickly as 37signals suggests. Furthermore, start-ups may not have the manpower to spend as much time as was suggested in CS160 on the prototyping and mock-up stages.

Kaleong Kong - 4/23/2014 16:32:20

I think both 37 signals philosophy and our class needs us to start making app with idea. They both emphasize on designing the app, then making a prototype and then test it out with user. Taking a iterative approach to improve the app. I think the difference between between 37 signals philosophy and our class is. Our class is teaching us to use a regular iterative approach. Yet, 37 signals approach is more like extreme programming. It emphasizes developer to make things real as soon as possible and tests it. This will make each iteration much shorter. I think 37 signals process is more preferable when you want your app to deploy to the market really quick, and the quality of the product is not the most concern to you. You concern more in getting feedback from users.

Vinit Nayak - 4/23/2014 16:33:26

Both of the 37signals philosophy and the CS160 design process reflect the importance of building something which is centered around the customer/end-user. There is heavy interaction with them throughout the process. Another similarity is also when they emphasize the need to provide some sort of design and interface before programming starts. One difference is that CS160 does not endorse not focusing on the details until the very end. The details do matter and must be taken into account to some degree early on.

Kaleong Kong - 4/23/2014 16:34:04

I think both 37 signals philosophy and our class needs us to start making app with idea. They both emphasize on designing the app, then making a prototype and then test it out with user. Taking a iterative approach to improve the app. I think the difference between between 37 signals philosophy and our class is that Our class is teaching us to use a regular iterative approach, but, 37 signals approach is more like extreme programming. It emphasizes developer to make things real as soon as possible and tests it. This will make each iteration much shorter. I think 37 signals process is more preferable when you want your app to deploy to the market really quick, and the quality of the product is not the most concern to you. You concern more in getting feedback from users.

Cory McDowell - 4/23/2014 16:36:01

37signal’s “do less” ideology is similar to the minimalist design process we have covered in CS160. 37signals says we should offer less features, options, preferences, and meetings. With minimalist design, we only put on a page the most essential UI elements. Everything else, we leave off. We only want to preserve the core functionality. If a competitor has lots of bells and whistles in their application, it most likely does not add much to the app’s core functionality, thus not really improving the product. Having less meetings and corporate structure is similar to the IDEO philosophies we learned early in the course. When people are equal and working together, they can form a greater product.

One thing that’s different from CS160 to 37signals is 37signal’s emphasis on passion. They want you to work on things you are passionate on and solve a problem you currently have. In CS160, we had a very guided structure on what problems we could solve, and how we had to use audio input to solve them.

37signal’s philosophy is great when you are starting your own company. You want to solve a problem you’re passionate about and if you work on something you love, it’s going to be a great product. CS160 is a lot like working at a large company, where they will give you an assignment and tell you the general way you should solve it, and it’s up to you to just get it done and deliver a successful implementation.

Ian Birnam - 4/23/2014 16:40:55

I think that the philosophies are very similar, in that the one taught in 160 is a general one, whereas 37signals is a more detailed, concrete philosophy. Both of them see the first stage as the design phase, and emphasize that rapid iteration through designs is important and encouraged over starting with the programming right away. Both also see the next step as prototyping, and then finally evaluation.

Where they differ is that 37signals prioritizes speed and being able to ship. Even if the idea isn't fully fleshed out yet, it's better to ship it out fast and then add in features later, even if they're essential (like Basecamp's billing system). They also just seemed to mix the 3 components of the 160 design cycle much more than 160 does.

I think 37signals cycle is preferable if you are under serious time constraints. Their cycle works for very rapid design and build phases, and a lot of the work is done it seems after the app has been published. Not saying that work normally doesn't happen after the app is published, but they seemed to highlight that it's ok to push something out even if its not fully realized.

Peter Wysinski - 4/23/2014 16:46:14

The 37signals philosophy matches the design process taught in CS160 since it recommends for one not to focus on details until later on. First one should focus on getting something out there and later focus on making small changes. Furthermore, 37signals encourages to, “find the core market for your application and focus solely on them.” Having a target set of users lets one develop an application that will be accepted in its niche and catered to satisfy an initial core group of users. Most importantly, 37signals urges to work in iterations — a concept that is very familiar to all CS160 student. It is important to understand that one will not get it right the first time and as the app grows and is tested with really users the developer can obtain useful feedback that can be used to improve subsequent iterations of the app. CS160 never teaches to design for error states — rather we should focus on preventing users from seeing the error. While this is good in theory it does not scale to production: when there are millions of users using the app at the same time, something is bound to go wrong occasionally. Furthermore, 37signals suggested we decide on the small details of an application so the user does not have to worry about them. From user interviews and what we learned in CS160, this turns out to not be the case — users like to feel in control and we should accommodate an optional, ‘advanced,’ interface for such power users.

Justin MacMillin - 4/23/2014 16:47:30

CS160 has taught us to follow this cycle: Design → Prototype → Evaluate. The Design aspect of 37signals is very similar to what has been taught in the class. 37signals encourages the flow of ideas and not worrying about details in the brainstorming phase. 160 encouraged our team to put up as many ideas as possible and go from there later. For this phase, quantity is important, nothing is ruled out. 37signals encourages brainstorming too by saying to ignore details early on, and scale later - yet another instance of worrying about bigger problems later. I think the best part of 37signals’s philosophy is “It’s a Problem When It’s a Problem.” This encourages the flow of ideas instead of people limiting themselves because of a potential problem. In my experience, most problems you think you will run into can be solved with the help of the team and more brainstorming about that specific problem. From here, we’ll move onto Prototype. 37signals, like 160, says that the team needs to make the decisions for the users, including the detailed ones. Without picking the details, its hard to test how users will react. Hypothetical tests do not work. 37signals also encourages to work in iterations, this is the same with 160. Development can be broken into many different design cycles, down to having multiple cycles per iteration. Each idea needs brainstorming, implementation, and testing whether its with users or just within the team. Finally, 37signals says to “Test in the Wild” which is exactly what 160 has encouraged us to do. It is best to test with random individuals to see exactly how a more diverse test group reacts to the app and its features. If the team picks only their friends, they are not likely to get a random sample for testing. Lastly, we’ll move onto the Evaluation stage. I thought it was interesting how 37signals thinks its best to look at something like a 12 week project as 12 one week project. This helps in keeping design cycle interactions and keeping evaluations at a reasonable size. Again, both 160 and 37signals both suggest to test out in the wild, so evaluations are similar.

Matthew Deng - 4/23/2014 16:56:16

The 37signals philosophy matches the design process learned in CS160 in many ways. Both focus on a main task that they wish to accomplish, and then build their way to that goal starting from the big picture and working down to smaller details. Also, both focus on a single specific target group, rather than trying to design something to satisfy everyone. Also, both are done in iterations, beginning with brainstorming, and then prototyping, and so on. In my opinion, the 37signals process is extremely similar to the one we learned about in CS160. There were minimal differences, and the ones most prominent to me were 37signals running their software as soon as possible, and including beta features as well as admin features all in one. I believe that this difference might come in handy when it is more acceptable for the project to have errors. If it is important that the project to be open to the public with full functionality, the design process we learned in class would be preferable.

Allison Leong - 4/23/2014 17:00:23

Similarities: The two philosophies (37signals and the design process taught in CS160) are similar in that they both stress that designers should design for a specific user group. In the chapter, “Hire the Right Customers”, the authors write that “if you please everyone, you please no one”. 37signals emphasizes this point further in the chapter titled, “Make Opinionated Software”, in which it is explained that software should prioritize vision over flexibility. The idea of “Rinse and Repeat”also echoes the iterative design process taught in CS160. The idea of prototyping in lo-fi in the beginning and hi-fi later on is also covered by the authors of the 37signals philosophy.

Differences: The lessons taught in CS160 seem to emphasize the idea that user feedback should dictate what changes are made and this differs from the chapter, “Avoid Preferences”, which tells designers to make decisions on the details so that users don’t have to. The reading also goes into more detail about time management (“Shrink Your Time”) than we have in class. The 37signals philosophy also advises designers to gloss over problems if they are not immediate.

The 37signals process is preferable to the one taught in CS160 when a project is starting up and the creative juices are flowing. Rather than getting caught up with the details, the 37signals process allows designers to run with their ideas and only come back later to change details or deal with scalability, etc. This may be beneficial for allowing ideas to flow freely so that the number of possibilities considered in the beginning is maximized. This way, designers won’t feel obliged to follow through on a particular idea just because they have already invested time in thinking about the small details.

Patrick Lin - 4/23/2014 17:01:30

The two design processes at the core are both iterations of designing, prototyping, and evaluating and related to the general Agile methodology. Both 37signals and CS160 agree that a product needs a narrow and well-defined target user group to succeed, and emphasize solidifying core features early on and worrying about smaller details first. 37signals does seem to propose spending less time planning however, arguing in the beginning of chapter 6 that getting the software running quickly is more important than creating more than one lo-fi prototypes like (no Balsamiq after sketching). Both processes still ultimately involve brainstorming, lo-fi and hi-fi (basic HTML/Android) prototypes, and product adjustments based on user feedback. Both also emphasize the importance of UI design in addition to the product's functionality. In the end, 37signals' method is geared toward quickly creating commercial web applications that likely involves managing customer data, possibly at an enterprise level. CS160 teaches much broader design concepts and puts more detail in the conceptualization and testing processes of design.

Chirag Mahapatra - 4/23/2014 17:03:06

The 37 signals philosophy is extremely similar to what we learnt in class. In the class we were encouraged to make a low fidelity mockup then a high fidelity mockup before actually starting to code. This process kept the emphasis on coding, Both the class and the article is focused on collecting valuable feedback from users rather than making assumptions. Another common factor is the emphasis on top down. In the class we moved from a very high level overview to the stage we are in now. Both have a high emphasis on iteration.

However, a key difference is that the 37 signals emphasizes a lot on getting the app ready and collecting user data from them using the app. Compared to this in the class we have collected a lot of user data before completing the app. Another difference is in deciding for the user. In the class we have been encouraged to ask the user when in doubt. However 37 signals advocates that we decide for the user and not tie him up with busy work.

The 37 signals approach is more suited to the industry. It takes into account factors like blank screen, defensive design and admin interfaces which are not covered in the class. However, the class process helps us try out new ideas and build on them. Since they are largely common, it is upto the user to decide which is more relevant. Personally, I liked the process from the class and when working in the industry I would just add the elements which are missing.

Hao-Wei Lin - 4/23/2014 17:08:58

The 37signals philosophy matches our design process in that it says we should focus on developing the interface first before we start programming. This is similar to our process since we started out with prototyping and evaluation before we even started programming for the application, which would save a lot of time (and money, in the real world) because error is easier to detect and fix with this method.

The 37signals differs from our process in that they treated copywriting as part of the UI design, which we didn't really go over/ talk about in class. 37signals also didn't specifically talk about user testing in their writings. However, their process can be more preferable in a sense that they believe that sometimes it's good to make decisions for the customer/users (e.g. 25 messages on a screen). This is preferable because, despite the fact that user testing is useful, it is true that sometime the users just can't and are unable to decide what is best for them. It is good to make a initial move to go with a certain design (of course, not without any basis or assumption), and user testing can come after.

Hao-Wei Lin - 4/23/2014 17:09:11

The 37signals philosophy matches our design process in that it says we should focus on developing the interface first before we start programming. This is similar to our process since we started out with prototyping and evaluation before we even started programming for the application, which would save a lot of time (and money, in the real world) because error is easier to detect and fix with this method.

The 37signals differs from our process in that they treated copywriting as part of the UI design, which we didn't really go over/ talk about in class. 37signals also didn't specifically talk about user testing in their writings. However, their process can be more preferable in a sense that they believe that sometimes it's good to make decisions for the customer/users (e.g. 25 messages on a screen). This is preferable because, despite the fact that user testing is useful, it is true that sometime the users just can't and are unable to decide what is best for them. It is good to make a initial move to go with a certain design (of course, not without any basis or assumption), and user testing can come after.

Daphne Hsu - 4/23/2014 17:18:19

The 37signals philosophy closely matches the design process taught in CS160. In 37signals, we define a big idea first and ignore details and find the right users, which is similar to what we learn in class, where we create a low-fi prototype and find a good target user group. Another thing that is similar is the use of iterations, from low-fi to high- fi prototypes. A difference is that the 37signals philosophy pushes the idea of getting out code as fast as possible, whereas in 160, we focus more on getting the right target user group and helpful design for them. 37 signals seems faster-paced in producing a product, whereas in 160 we take more time thinking about our users. I think 37signals would be better when you have a tight time constraint because you would be faster in pushing out a product. If you have more time and want to make a better product, then I would use what we learned in 160 because we really take the time to understand the target users.

Will Tang - 4/23/2014 17:18:50

The 37signals philosophy matches the design process that we learned at the beginning of the semester in its emphasis on iterations. Rather than the waterfall approach of development, both of these philosophies prefer starting small and improving through iteration. 37signals also advocates focusing completely on the bigger picture in the beginning, which is similar to what we were taught. Rather than worrying about the colors or small features of our app interfaces, we focused more on the important features that represent the functionality of the application.

Where the 37signals philosophy differs is its focus on designer decisions and speed. Testing iterations is a huge part of the design process we used in class, but 37signals recommends skipping over beta versions and going straight to production. Going through all the prototyping stages is not part of the 37signals design process, where testing seems to happen after implementations are working. In addition, the user testing that we conducted served to gain feedback about many different aspects of our interfaces, and not just the major functionalities. 37signals advocates having designers make decisions for users, which seems to skip the important testing stages. Consistency in interfaces is also ignored by 37signals, where the context matters more. This seems to be a violation of the consistency heuristic we used to gauge interface usability.

Ultimately, in grand scheme of things the 37signals process is similar to the design process we were taught in its focus on iterations. The differences lie in how designers go about each iteration.

Meghana Seshadri - 4/23/2014 17:21:08

There are a variety of matches between the design process taught in CS160 with the 37signals philosophy. Similar to the CS 160 class, 37signals goes through a basic process of idea generation and brainstorming, to creating low-fidelity prototype creation such as paper sketches and balsamiq prototypes, to finally implementing the idea in code and bringing it to life. Another similarity comes from the 37signals “rinse and repeat” process, which clearly maps to the flow we have been following in class where we implement prototypes and go out and “test in the wild” on real target users. From there we take whatever user feedback attained and incorporate it into the next prototype.

There are also several key differences between the two processes/philosophies. 37signals really focuses on specific ideologies that one or a group must have throughout the product implementation process. They go into quite detail on the priorities of building their product. They discuss many of the topics in a more marketing mindset, where they consider customers, scalability, and opinionated software. While our class does emphasize on knowing the target audience and building use cases when designing our applications, we don’t go that in depth on making sure that we have the exact mindset of creating our application for actual marketing and manufacturing purposes once it has been built (since it’s just a class project). Hence, the 37signals process is definitely more preferable when a person or group is really trying to build a product that will be suitable and successful (economically) out in the public for people to use.

Brian Yin - 4/23/2014 17:22:17

Both philosophies share the common idea of pushing the details later (seen in the way we do prototypes and selectively chose what to what to implement in the interactive prototype) and also using several iterations of development and testing in the real world to see what areas of the application need to be improved.

One of the areas of difference is the role of the user opinions. In CS160, a large emphasis on interviewing users to get their feedback on problems they faced and things they would like to see. The 37signals philosophy emphasizes following the vision of the product appealing to consumers. They argue that the right consumers will follow a strong vision. While this approach does open itself to the risk of developing a product that meets no needs whatsoever, it may be better to use such an approach for products which are innovative and disrupt the way users normally do things, as potential users could be strongly influenced by they way they currently do tasks.

Kevin Johnson - 4/23/2014 17:23:52

Like CS160, 37signals prioritizes building simple functionality - or even interfaces without functionality - before the meat of the application as a form of early prototyping. Speed and iteration are critical. However, they seem to place much less emphasis on direct consumer feedback, focusing less on following the results of user studies. Instead, they focus even more on speed and simplicity. The 37signals approach is preferable when you already have a good intuition for what users are likely to want, or when you just need to make something useful, even if it isn't ideal.

Aman Sufi - 4/23/2014 17:27:50

Both philosophies incorporate the design-prototype-evaluate cycle essentially. However, our class is more based on learning about UI and trying to incorporate it into our applications in a novel way while at the same time trying to help us learn how rapid-iteration works, while not actually pushing out new iterations constantly and essentially only completing the cycle once.

To expand upon that, we never actually implemented HTML prototypes, and all of our assignments have only been done once to get a ‘taste’ for how it would be done in real life, which makes sense in the classroom context. 37signals philosophy is also centered more around web development, but it corresponds closely to app development. There is less focus on design theory and more focus on design practice, such as ‘Epicenter design’ or ‘Defensive design’ and planning for error and new states in an app interface, which I feel is preferable to the many theories taught in CS160 in its application in the real world. However, the CS160 process does have merit in being broader based and drawing comparisons/giving examples of non-apps/web interfaces (i.e. physical products) as well and gives a broader approach to design. Both processes emphasize user feedback before moving forward in the design process, resulting in many fewer wasted hours revising already implemented code.

Doug Cook - 4/23/2014 17:28:00

The 37signals philosophy matches the design process taught in CS160 in that it emphasizes iteration (like the design cycle) and testing (like our prototyping and usability studies). There are also similarities in Ch. 4 where it instructs designer to find the "right" market, much like we did in our brainstorm process. The philosophy differs in that it also takes into account staffing and scalability issues which a real-world company might face, unlike the relatively small scope of design in CS160. For that reason the 37signals process might be preferable in commercial contexts, but CS160 is obviously superior in academic ones where it's important to learn about each step of software design (without distractions like shareholder concerns -- which are very relevant to companies).

Shana Hu - 4/23/2014 17:30:02

The 37 signals policy provides a more concrete design process in which they specify direct steps that one should take. They are also focused on a software product versus the general designs process which is applicable to projects of all types. Where's interface design is a subset of other facets of design, the 37 signals project send to be targeted at a limited, software focused community which aims to make products at a mass market scale.

Andrew Lee - 4/23/2014 17:30:48

The processes are similar in how iteration is a key part of the process. However, the starting points seem a bit different. In CS160, we started with trying to really understand the users first, whereas the 37signals philosophy emphasized getting something working first and fast, effectively deferring the user understanding in the form of feedback.

The 37signals approach is probably preferable in startups, since they need to quickly be able to present something in action, whereas in CS160, we have the luxury of not having this kind of pressure.

lisa li - 4/23/2014 17:32:19

I can draw a lot of similarities between 37signals philosophy and what taught in CS160. For example, in chapter four, ideas about "ignore details early on:, "scale later" are similar to creating low-fi, inexpensive prototype first. Also the idea of "go from brainstorm to HTML to code" is also similar to methods that's introduced in 160. In chapter 6, the idea of iteration is similar to the design cycle we learned at the beginning of the semester. In chapter 9, the idea of context over consistency also talk about the importance of attention to context, as we learned context inquiry.

Most of the principles introduced by 37Signals are applicable to light-weighted web apps. However, in other cases, some principles might not be applicable. For example, if a software is too heavy-weighted, it will be very expensive for the company to launch a product and change the whole design later. Also, if a product have a very very large user base, it might not be a good idea to launch a imperfect product because of the number of people affected is too large.

Tristan Jones - 4/23/2014 17:39:13

I think design philosophy talked about in 37signal's essay is pretty different than what we're learning in class. 37signals advocates having a quick launch while fixing things as you go, while our class talks about conducting a lot of user testing to make sure the user experience is perfect. To draw a comparison, 37signals is much more like facebooks "move fast and break things" while this class is more like Apple's "It just works" with perfect, well researched, and intuitive UIs. 37signals also talks about making strong decisions and not dwelling on them, which is something I like quite a lot. Some features just have to be prescribed so users don't have to learn between multiple variants. One similarity I found was their segment on "From idea to implementation", linked here:

They talk about having brainstorms, to paper sketches, to HTML mockups, to actually coding it up. That's completely identical to the design process taught in this class, except without the user testing stuff. It is a bit extreme though, not having any user testing so in my opinion, a compromise between CS160's "Apple paragon" and 37signals "Build incomplete things that kinda work and iterate" is the best design process.

Eric Hong - 4/23/2014 18:24:13

The 37signals philosophy matches the CS160 design process in that the application goes from big idea to details, from idea to implementation. The philosophy suggests developers to start with brainstorm and sketches, get a quick working prototype, and work on details later, which is what we are doing in CS160. Similar to the process taught in class, the 37signals philosophy also puts emphasis on restricting the target users and "Test in the Wild," or getting real users to try the product even before it is fully finished.

The CS160 course did not emphasize the "Three State Solution," or designing for regular, blank, and error states. However, this design focus is useful for complicated applications that have multiple different blank and error states, depending on the data. Focusing on getting every state working correctly would reduce the number of application crashes and give a priorities for the next feature to accomplish.

Nahush Bhanage - 4/23/2014 18:39:44

The 37signals philosophy revolves around an iterative approach of building an application. This closely matches the design-prototype-evaluate cycle taught in CS160. Both approaches admit that it is not possible to achieve perfection in the first iteration, so it not really wise to follow the waterfall development model that doesn't bring in the testing phase right until the very end. An iterative approach seeks to get frequent feedback from the potential target users and accordingly fix the design and come up an updated prototype for further testing. Both CS160 and 37signals speak about creating a specific vision for the application and accordingly start working on the idea from a broader perspective. They advise not to get into specific implementation details during the initial design phases of the process, since you will have to change them later anyway based on the user testing feedback. Another similarity between the two philosophies is that they emphasize on designing the interface before starting on any coding - otherwise, there is a noticeable gap between the UI design elements and the underlying implementation. In CS160, we also studied about targeting the right customers instead of targeting the whole population - however small the target size be, it has to be a focussed group that would really benefit from the application. Similarly, 37signals also speaks about focussing on the right audience. Finally, both philosophies encourage the developers to do some real world testing by interviewing the potential target users of the application to get real feedback. This is aligned with the iterative development process - frequent evaluation and feedback help the developers to stay on track.

Though there is a large overlap between the design process taught in CS160 and the 37signals philosophy, I think there is one significant difference in their ideologies. 37signals emphasizes on developing and releasing the application, however basic it may be, as soon as possible. The rationale behind this is that you won't get real feedback unless you have some sort of an interactive prototype that you can play around with. According to this philosophy, beta testing on an such a prototype would cover all aspects of interaction that are not possible to recreate on a mock-up user interface. On the other hand, CS160's ideology focusses more on the design process and mock-up interfaces before starting with the code implementation. The rationale behind this is that it is better to get as much feedback as possible on a low fidelity prototype since it is easier to fix the design and other functionality aspects at this stage.

The 37signals philosophy primarily focusses on getting the application out in the market as soon as possible - I think this approach would be preferable to the one taught in CS160 if you are working in a faster development environment with a short time-line. I believe this would be the case with most start-ups which do not have much time and resources at their disposal. On the other hand, I think the CS160 design process being more detail-oriented would lead to a much better application in the first iteration itself and should be preferred in case you are working on a relatively relaxed time-line.

Conan Cai - 4/23/2014 19:16:36

So far in CS160, we've followed a very careful design process.Through the class, it isn't until the last month that the application is actually being coded. There were 2 months of planning and designing prior that will hopefully lead to a relatively polished product. However, with the 37signals philosophy, it seems like they are saying, "worry about it later." They say to worry about problems later, when they actually arise, rather than try and prevent them now. Get something working, it doesn't have to be polished. Test in the wild so that you can push something to your customers as soon as possible. This process could be preferable in the current mobile landscape, as thousands of apps are released each day. There is only a small window to release a popular app and capitalize on the users' short attention span. For example, Flappy Bird spawned numerous clones. Developers were more focused on getting something released to get a "slice of the pie" rather than focus on a well made product. So in the current landscape, when trends are changing so quickly, it might be preferable to not worry about the details to get something working and released before your competitors leave you behind.

Romi Phadte - 5/1/2014 3:58:58

There are several similarities in the concept of moving from large to small. The concept of writing 4 lines of code instead of 7 is definitely something that we see in cs160 with our low fidelity prototypes. Additionally, the concept of working in iterations is nothing new. We see this emphasized throughout the semester in the product design cycle. The emphasis of "test in the wild" is also mentioned in the class. One thing that seems different is the idea "context over consistency". 37 signals mentions that "It's ok to be inconsistent if your design makes more sense that way." In cs160 however, we emphasized the importance of consistency as a design principle and used if several times as an indication of the strength in a design. One thing that we didn't really mention in cs160 is the concept of designing for the blank screen which is a screen devoid of data. We talked about help for getting users to understand the app at login. But we never talked about making sure the app looked good even without any initial data. This a fairly important insight since its what every new user faces and impacts the view of the site. This is probably also the reason why social networks force you to have a couple friends.

To be honest both processes are similar enough that I wouldn't be comfortable calling one more preferable than the other. At the heart of it all, the philosophies come from similar principles and ideas from both should be incorporated in how we design and plan future products.