Mobile Start-Ups

From CS160 Spring 2013
Jump to: navigation, search

Contents

Readings

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

The chapters are very short.

Reading Responses

Lauren Fratamico - 4/14/2013 15:45:35

37signals' philosophy mostly matches what we have learned in CS 160. In particular, in both we learned about the importance of having a big vision focus (both not focusing on too many things and also having a ideal user in mind and not building for everybody). Both also stressed similar design cycles (brainstorm, make quick drawings to get an ideal of the ui, code at the end, then iterate to improve). One thing that I don't believe were mentioned in 160 was "starting at the epicenter and building out". This stresses an importance for building only the essential things into the ui first, then as you iterate later and get input from users, add extras later. While we do iterate and add additional features in this class, there was more of a stress by 37signals to only have the minimum there first and don't waste time thinking about what additional features to add to later. In this case, I prefer how we were taught in 160, I feel that users may not think to desire an additional feature unless we present it to them. I believe this is how inovation is driven. An additional difference was 37signals' idea to design not only for regular use but also design for errors. I think this is something that should be mentioned in 160 because while our app might work well most of the time, it is also important to keep our current users using our product if an error occurs. We want to ensure that users have a pleasant experience even when the ui is malfunctioning.

Colin Chang - 4/14/2013 18:41:29

The selections from 37signals' book Getting Real describe one startup's process for designing and implementing successful web applications.

Where does the 37signals philosophy match the design process taught in CS160? Where does it differ? Is the 37signals process preferable to the one taught in CS160? Similar: iterations, design first then code Differences: 37signals focused on establishing an initial vision. User testing also differred, 37signals erring against formal usability testing and similar devices (which, I presume includes contextual inquiry) and suggesting instead some A/B testing variant. In terms of preferability it depends what you mean by preferrable. 37signals and CS160 in some cases covered non-overlapping topics: in 37signals, a focus was put on ongoing development, like keeping true to an initial design decision, putting off decisions that didn't require immediate attention (not implementing bill paying stood out to me), or attending to forgotten situations like introductory screens (for new users) and error screens. In CS160 more attention was put on the brainstorming and other ideation related activities (contextual inquiry, interview, prototyping etc). I suppose the diplomatic thing to do is to accept both, but that's no fun.


Shujing Zhang - 4/21/2013 17:27:33

First of all, they clarified their vision and purpose before they started to create the app. Also, they know what their app will different from other applications. Second, they find the target market for the application and focus solely on them. Third, they create mock-ups quickly and don’t waste time on overbuilding prototypes. In addition, they also work in iterations. They first brainstorm, and use paper sketch to achieve quick, dirty, and cheap prototype, and that’s exactly how you want to start out. After sketching they just build a mock-up in html and css. Implementation comes later. There is plenty of time to be a perfectionist.

During the testing phase, test the app via real world usage. There’s no substitute for real people using your app in real ways. Get real data. Get real feedback. Then improve based on that info.

The differences lie in some details. First, 37signals' book mentioned that the app should take sides, which is a way to demonstrate their vision. Customers are looking for a vision. So decide what your vision is and run with it. Second, your app should decide the little details so your customers don’t have to. Third, 37singal also emphasize on the defensive design. Always search for trouble spots that cause visitors confusion and frustration. Forth, they mentioned that they should choose tools that keep your team excited and motivated.

37 signal's book coincides with process mentioned in CS 160 very much. But 37 signal's book is more preferable because it addressed more realistic problems especially in deciding preferences. The defensive design is also a key issue during the design process.

Jeffery Butler - 4/22/2013 15:34:44

  The priorities section of 37 share a lot of similiarities and disimiliarities with our class approach. In the 37signals, there is a lot of emphasis based on only worrying about a problem when it arrives since its more important to get your product out there and than not having to worry about overloading servers. On the other hand, our class approach doesn't really go into these issues. Instead our class places an enormous emphasis on getting a superb prototype together so that the coding is a lot easier. These two stances can conflict if the building of a 'Perfect' prototype takes too long. 
    In the process section of 37 signals, there are a lot of descrepancies in relation to the proper execution of a project. The 37signals do not do Wizard of Oz testing because itll fail to give the proper information to what the user would want. Next, instead of getting perferences from the users before the high fidelity prototype is made, 37 states that if there's a preference: make the decision for the user instead of giving them the option (more of a Waterfall approach). Thus, 37's implementation will find the real user's preferences when the app is in the wild and being tested by users. Lastly, the 37 says to act on the fly if they are given certain problems to fix when the app is in the wild instead of worrying about them in advance. 
      The interface design in 37 is very similiar to the class design but they also introduce a few new cool points of view. The regular, blank and error mentality in 37 is highly applicable in the high fidelity prototype. Here the programmer worries about the first time user uses the app and how the app will handle errors in each screen which are similiar to the applying the proper Heuristic Evaluation principles. However, the interface design in 37 jumps from paper to high fidelity thus skipping a lot of the intermediate steps that we completed in class. 
  I personally prefer the 37 approach more than in class approach. I felt that the amount of time that we spent designing a proper interface was great but a lot of the real design implementations came when we actually had to code it. Therefore, if designers spend a lot of time with Wizard of Oz testing etc... they could get helpful information though a lot of it tends to change once they have to actually code the interface. On the other hand, the approach in class really helped with getting a solid design down before coding which gave my group members and I, a solid idea for how long things would take and successfully avoid huge design changes. I personally think this class placed too much emphasis on the before stages of high fidelity rather than what to do when at the high fidelity stage. 

Soo Hyoung (Eric) Cheong - 4/22/2013 17:44:30

A lot of the 37signals philosophy matched the design process taught in CS160. One was during the ideation stage, both recommended having a clearly focused vision for the app, while not focusing on too much details. Also both suggested on having focus on a specific set of customers for the app, and then branching out. However, one difference was that 37signals said to take clear sides on the issue and do not be flexible about it, but CS160 taught us to be flexible.

During the prototyping stage, both suggested to get prototype set up quickly to get feedbacks rather than continuously pondering on our own. Then moving on to iterations to repeat the design process. In support of such iterative process, both recommended starting prototype with sketches rather than focusing on nitty-gritty details. The 37signals suggested deciding the little details on our own so that the customers don't have to, however, our approach in CS160 was to cater to the customers as much as possible. One very unique thing about 37signals was that it focused on designing for three state solution where we consider the cases for regular, blank, and error states for every screen, while CS160 course did not put focus on considering all three. Also 37signals said to add admin function into interface, while we do not have anything like that.

Zeeshan Javed - 4/22/2013 18:58:33

37signals place a priority on designing the interface before designing the program. In many ways this overlaps with the design philosophy of the course which stresses a design, prototype, and test paradigm. While CS160 may not place an emphasis on some of the aspects covered by this particular reading, 37signals stresses Starting from the core of the page and build outward, Designing for regular, blank, and error states, Setting expectations with a thoughtful first-run experience, Designing for when things go wrong, and Incorporating admin functions into the public interface. I would not say that the proccesses taught by CS160 are less preferrable. I think that in respect to the specific goals of 37signals and their products, their own design philosophy makes it easier to scale for larger numbers of employees and compromises on design ideas that may already be pre-instilled in incoming engineers.

Scott Stewart - 4/23/2013 12:55:02

The 37signals design philosophy is very similar to the CS160 design process in that they both follow an iterative pattern. Both design processes require creating something (paper sketch, mockup, etc) and then getting real feedback in order to improve on that design. The main difference is how the iteration takes place. CS160 design process focuses on steadily building on effort/cost at each step, so that design decisions can be made quickly and then refined before the actual product is made. The 37signals philosophy encourages building a working product as soon as possible. A paper sketch or an HTML mockup are used for quick design, but these are used more as references for building the product, and then the working product is iterated on. I think that the 37signals design philosophy is preferable for building web applications. Web applications are able to be updated easily as iterations take place, and feedback is also easier to gather from users as they actually use the product. For other products, however, such as building an OS, the CS160 process would work better, since the cost to build the product is much higher, and distributing updates and getting feedback are both more difficult.

Annie (Eun Sun) Shin - 4/23/2013 15:14:28

The 37signals philosophy mentions having a vision and hiring the right customers. A vision, which "will guide your decisions and keep you on a consistent path," (Chapter 4: Priorities) and targeting a specific audience is similar to the definition stage in the design process taught in CS160. During the definition stage, designers focus on the problem that their product addresses and choose the appropriate level of detail. 37singals' book encourages designers to "get something real up and running quickly" (Chapter 6: Process), which is something that our class' design process does not emphasize. Our class' design process just mentions that implementation and evaluation happens multiple iterations throughout the creation of the application, which is similar to the "rinse and repeat" philosophy mentioned in 37signals' book. The book then mentions brainstorming (especially by drawing sketches) and testing (with real users), which are also mentioned in our design process. The 37signals philosophy also mentions to scale later, to not get bogged down by the details of the product (e.g. UI details such as font) or get too ahead by forming potential problems in your head, and to break down time. The parts of the book that differ most from the CS160 design process are found in Chapter 9. Readers are told to "start from the core of the page and build outward." Such specific advice is not mentioned in the CS160 design process. It mentions other specifics such as designing a screen that "people see when using the app for the first time, before data is entered" and another error screen that users "see when something goes wrong." The book mentions the impact of the blank state and how customers determine whether "an application is worthy at this blank slate stage--the stage when there's the least amount of information, design, and content on which to judge the overall usefulness of the application." I believe that advice addressed by the book is an important and interesting point that I wish I had in mind. Both the book's philosophy and class' design process offer good structure and advice when approaching app development. The 37signals process seems to be more preferable for more experienced designers while the class design process is better for first timers.

Elizabeth Hartoog - 4/23/2013 15:18:58

Similar to our processes. It's the idea of starting big, then working down small towards the details. The location and size of a submit button is unimportant if you can't figure out the bigger picture of the form. Similarly, they talk about how you want to focus on the core target/audience, much like we narrowed down what our target was for our app and focused on pleasing them. Their actual design process is also similar, though most likely quicker since they emphasize moving onto software. They have brainstorming, then they work on a low fi prototype of a sort with many sketches before creating their hi fi prototype out of html. Once the html sketch looks good, they add in the implementation. Though their prototypes are less functional, they server a similar purpose...minus the need for people to be able to test with them. They also advocate interface design first over programming design.

Some of the differences between what we were taught is their extremely low emphasis on prototyping and testing and advocating for a straight to it programming. For most people, quickly rushing to developing an app is dangerous, but it works for them because they emphasize interface design first and make sure that is designed before moving on. Instead of using customers to gauge how some interface decisions should be done, they say you should just make the decision yourself and if people don't like it they can tell you about and you can fix it later. Instead of usability studies which they consider to be too "stiff", they send the app straight out into the world for beta testing. Also, one interesting thing is they advocated "context over consistency", which could break a rule in heuristic evaluation in certain situations. They argue that if something needs to be inconsistent to fit the context/situation, then it should be done. Design shouldn't be jerry-rigged, which I sort of agree with. Though ideally it should be designed so there doesn't need to be any inconsistency without inconvenience.

Sumer Joshi - 4/23/2013 16:09:02

37's process seems very logical and refreshing to read. I think the cool thing about their process is that they think about starting large and and ending small in terms of a thinking process. This differs from our class because for us there is not really a thinking process on how to attack a problem, but rather just start with the basics, and then go to the details.

Alice Huynh - 4/23/2013 16:31:03

37signals philosophy is to first start with an idea before doing anything. This is similar to the brainstorming that we did in class and the process that we did to narrow down the idea to one thing. 37signals stated that it’s important to work from large to small. In the early brainstorming stage it’s important to not criticize any of the ideas in order to help get bigger and better ideas. It’s not until the process of after deciding on an idea that the details then come into play. Iterations is a common theme in both 37signals and CS160. I agree with this quote in the reading “Knowing that you're going to revisit issues is a great motivator to just get ideas out there to see if they'll fly.”

Another similarity between CS160 and 37signals is “test in the wild” which encourages all developers to go out there and get real world feedback on the apps. I believe that this step is very important because this follows the iterative model rather than the waterfall method that gets feedback way too late in the designing process. By getting feedback as early as possible the changes to the fundamentals of the application is still easy to change.

One huge difference between 37signals and CS160 is “get something real up and running quickly”. In CS160 we focused a lot on storyboarding and hand-drawing a lot of lo-fi prototypes before we got the point of running software. 37signals encourages its readers to get running software as soon as possible and take as many shortcuts it takes to get to that running software. This idea by itself is very different from CS160, but later in chapter 9 in the reading in the interface design section is where 37signal tells developers to design the look first before ever programming anything.

One aspect that CS160 didn’t cover is the idea of the “regular, blank, and error states” for each of the screens. These state screens are touched upon in the 10 “usability” rules that we learned about, but chapter 9 gives us a much more specific list of things to keep in mind when ONLY designing the interface rather than any of the functionality.

Overall, I believe that the CS160 timeline is a much more relaxed process of designing something where as 37signals process seems a bit more rushed. 37signals believes this because in the real world, not in a class environment, it’s important to think about things in a shorter time-line. In the real world it’s important to think fast and act fast on ideas that many start-up employees want to get out there fast and done well. When it comes down to it, CS160 and 37signals have very similar process of designing with lots of real world feedback and lots of iterations. This big idea of lots of feedback and lots of iterations is the preferred process.

Cory Chen - 4/23/2013 17:17:53

Chapter 4 of the page talks about the process of creating and designing your application and what aspects you should prioritize. The main theme is that at this stage in the process, you should not be worrying too much about the details or planning too far in advance. The main priority at this point is to get the core functionality out and running, and then tackle the side issues later. The chapter constantly stresses worrying about issues when they come up instead of anticipating them in advance so that the application can actually see the light of day instead of being in incubation until the end of time. The chapter also stresses being focused on the vision and purpose of the application, not allowing yourself to be swayed too much by the opinions of your users. This chapter is very similar to the designing and prototyping part of the design process we've learned in class. While constructing a low fidelity mockup, we focus on the big picture functionality instead of any per-pixel changes that the application would need. The low fidelity and prototyping parts of the design process are all about figuring out the focus and goal of the project, which is the same as 37signal's philosophy.

Chapter 6 focuses on the actual process of creating your application. This section also seems very similar to our design process, except there is a greater emphasis on getting through the design process quickly and getting to an actual implementation of the application (emphasized in the "Race to Running Software" section). Another aspect of the design process that 37signals seems to focus on more is the idea of breaking down the design and implementation process into small chunks. Instead of creating a deadline of 3 weeks, you should plan 3 smaller 1 week deadlines to help work be broken down into more manageable chunks. The two design processes mostly share similarities though, such as focusing on simplicity in design (avoiding preferences), testing with real world people, working in iterations, and the process of going from brainstorm to implementation.

Chapter 9 is specifically about the actual interface of the application. This chapter points out some interesting areas of focus that I feel we haven't covered much in class. The idea of needing to focus a lot on the blank, initial screen seems like an important one. If the first impression of the application is good, the user will probably use it again. Epicenter design, context over consistency, copywriting as interface, and combining the admin and public interfaces are concepts that we have not extensively covered in class. Both design processes stress designing the interface first; we did this for our project when we created Balsamiq mockups of our applications.

Overall the 37signals design process and the design process that we've been learning in class are quite similar. The 37signals process has more detail to it, and seems to be more specific towards developing web applications. I think the major difference between the two methods is that the 37signals process emphasizes getting a working, coded version of the application out. While this might be the case for web applications (I'm not sure, I've never developed such a thing), creating a working product in other circumstances leads to hesitancy regarding changes to the application. The design process we've learned in CS160 is more flexible in the early stages of design and should be more useful for creating powerful ideas and applications

Moshe Leon - 4/23/2013 18:32:14

Chapter 4, “what’s the big idea”, discusses having a vision. I think they simplify the notion of the initial design into the sole purpose of having a basic idea which you may then start pursuing as a goal. Over the time, this idea is being refined, but the gist of it is still there to hang on to and for sanity checks. The design cycle we have discussed in class is also discussing the need to know why you are even thinking of creating something, but it just packages the same thing differently. In “ignore details early on”, it discusses how too much attention to details could lead to bad results early on. There is an emphasis and talk about the consequences, something that is not discussed in our design process as much- we mostly talked about pros, not cons. A difference between our class design cycle begins in the “it’s a problem when it’s a problem” part, which discusses how things that are not important should not be implemented as long as they are not needed. The focus needs to be on developing the basics, and make it work. This is indeed, the philosophy of a startup- bring it up, worry later. We did not cover this methodology in class, as far as I can remember. We did mention scalability, but also that we don’t need to worry about it since it is 169 class material. The important thing to take I believe is that the attention needs to be placed on things that get you moving towards the final line of this race, and not on the next race already. I tend to do the latter, so this is definitely something I need to adopt. “Hire the right customers” was largely discussed in class (the Homer-Mobil) and is another important topic carried directly out of the first chapter. In “Scale Later”, it is being redundant, reiterating what it mentioned before as an example in “it’s a problem when it’s a problem”. The approach of ‘you are either on the bus or off the bus’ in “Make opinionated software” will make sense, only for an experienced company which knows what it is doing. If the idea is good and strong, and there is enough target market, there shouldn’t be any reason to change it anyways, right? So assuming you follow the design cycle, and make sure you are truly answering a need of an audience, things should play along just fine, and there is no need for snobbism. This agile methodology is also discussed and practiced in cs169. The biggest difference starts in chapter 6, “get something real up and running quickly”. Our design cycle not only avoids it, but also warns us from getting our hands on something that would be hard to let go of later. We only start with sketches, then low-fi, then hi-fi. I heard someone say once regarding the need to discard big chunks of code he has written as ‘killing his children’. He was joking, obviously, and mentioned it is always tough to do. “Rinse and repeat” is very similar to our design cycle, with its iterative perspective. With every iteration the design becomes better and better. “From idea to implementation” is more like what we did and discussed in class, when html stands for the balsamiq as low-fi. In “Avoid preferences”, it discusses how preferences should be avoided whenever possible, and we should be taking the decision instead of the client when he uses the app. I agree, although I disagree when they say to trust our intuition- we should trust a more educated guess, such as a demo of several screen options with clients to really get a notion of what the right path is. Class also discussed the notion of simple interfaces, and not to confuse the user whenever possible. In “Done” there is a philosophy of building momentum, rather than stagnating over things until they are perfect. In class we test it, and make sure it is satisfactory with real customers before we proceed. “test in the wild” is referring to testing, although I think beta testing is risky for the company’s reputation in case of a bad product. “Shrink your time” is an important aspect, which is just reiterating the idea of iterations rather than a big long single step. Overall I think that 37signals are using a good working schema, however, they are an experienced studio, and they already know what they are doing. It is more realistic in the sense that many companies want to get something out there, rather than work on it until it is perfect and ready to ship. Sometimes the moral of the staff is more important than the design cycle, and moving things along could really help, but the drawback is that getting rid of things that were hard to design and produce can be hard, and sometimes people would do anything but to backtrack and fix the issues.

Sihyun Park - 4/23/2013 19:40:31

37signals' philosophy generally match the design process taught in CS 160. Both philosophies' core is in "iteration." Design is never "done." It takes multiple iterations to reach a product that users would really appreciate. That's why 37signals emphasize the importance of iteration - ignore details early on, scale later, rinse and repeat, etc. The same goes for design process in CS 160, in which we go through multiple iterations of a product, moving from a low-fi prototytype to hi-fi prototype, etc., based on users' feedback. Iteration is governed by validation. To iterate, both 37signals and CS 160's design processes require validation of the initial hypothesis, e.g. a feature of a product, a customer pain, etc. As such, designing a product involves conducting several experiments/beta-testing to see if the hypothesis is true; if not, make improvements and iterate. Through such iterative process, both 37signals and CS 160's design processes seek to address the customer's needs as much as possible. The goal of such processes is to create a product that best satisfies users' needs. Iterating quickly allows the product to fit to users' needs - although the product might not be perfect in its first few iterations (it will most likely be imperfect in the first few iterations), repeated iteration and validation would make the product fit to the users' needs over time. Indeed, you never know the customer's needs until you talk to them & find out. Given these matching nature of the two philosophies, 37singals' approach and CS 160's design process are equally important in product design.

Thomas Yun - 4/23/2013 19:43:46

The 37signals philosophy is very similar to the design process taught in CS160. To start, the 37signals says to define a big idea, ignore details early on, and to find the right consumers. This is similar to defining the problem, creating a lo-fi prototype, and finding the right target users. Next, there is rinse and repeat, starting from brainstorms and working your way up to coding, and testing it in the real world. In CS160, the design process includes iterations, which is rinse and repeat. There is also a huge emphasis on brainstorming, to sketching, and then finally coding when our ideas are on paper. We are also ask to find real target users to test the mock-ups on. I think where 37signals differs from CS160 is with some of the things mentioned in Chapter 9. I don't remember anything about starting from the center or anything related to a 3 state solution. With that said, I don't think a process should be preferable to the other because they both touch on the main points of interface design. One is simply more detailed or just follows another route from the other. Regardless, both design processes talks about the same necessary steps for good interface design.

Alvin Yuan - 4/23/2013 22:49:01

The reading's philosophy matches with the CS160 design cycle in that both are iterative and recommend sketches/mock-ups before jumping in. They differ in that the reading's philosophy seems to emphasize getting code working faster while the CS160 design cycle seems to emphasize spending more time to understand the users and their behavior before jumping to development. The reading's process seems to work better in the Web context. Websites can afford to get an unpolished site up early, at which point the designers can get constant user feedback by collecting data on site usage. Thus, the less emphasis on understanding the user prior to development makes sense, since observing users and getting feedback becomes much cheaper and available once a site is up and running. Other products though cannot always afford to make a sloppy first impression. App development needs to devote more time to refining the first product, because it most likely needs early positive reviews to have a chance at becoming big. Thus more resources are spent doing things such as usability tests before they put the product in the market. Websites don't seem to suffer (at least it seems that way) as much from making an unexciting first impression (first impression in the sense of the first couple users, not the first time for users); negative impressions don't really stop sites from gaining users in future versions. Negative app reviews can make it difficult to get users to try out future versions though, so there is a lot more riding on that first production.

Alvin Yuan - 4/23/2013 22:49:38

The reading's philosophy matches with the CS160 design cycle in that both are iterative and recommend sketches/mock-ups before jumping in. They differ in that the reading's philosophy seems to emphasize getting code working faster while the CS160 design cycle seems to emphasize spending more time to understand the users and their behavior before jumping to development. The reading's process seems to work better in the Web context. Websites can afford to get an unpolished site up early, at which point the designers can get constant user feedback by collecting data on site usage. Thus, the less emphasis on understanding the user prior to development makes sense, since observing users and getting feedback becomes much cheaper and available once a site is up and running. Other products though cannot always afford to make a sloppy first impression. App development needs to devote more time to refining the first product, because it most likely needs early positive reviews to have a chance at becoming big. Thus more resources are spent doing things such as usability tests before they put the product in the market. Websites don't seem to suffer (at least it seems that way) as much from making an unexciting first impression (first impression in the sense of the first couple users, not the first time for users); negative impressions don't really stop sites from gaining users in future versions. Negative app reviews can make it difficult to get users to try out future versions though, so there is a lot more riding on that first production.

Winston Hsu - 4/23/2013 23:05:46

The 37signals philosophy has a lot thats similar to whats learned in CS160. It emphasizes an iterative process that leaves the finer details for later. However it seems to think less of formal usability studies when compared to just letting things out in the wild. The 37signals processes seem more geared for fast moving, money tight startups, whereas the 160 process seems better for bigger, wealthier companies trying to deliver a more polished product.

Soyeon Kim (Summer) - 4/23/2013 23:57:06

The philosophy of 37signal matched for the most of the time with the design process taught in CS. In the “Priorities” chapter, things like, “Ignore Details Early On" and “Hire the Right Customers” is exactly the same with the one that was taught in the class for trying to obtain specific target user groups and focus solely on them because we cannot please everyone. Also, in “Process” chapter, “Rinse and Repeat” is what CS160 emphasized, the iterative design process. “From Idea to Implementation”, in “Process” chapter as well, is equivalent to the brainstorming techniques and rapid prototyping techniques that we learned in the class. Lastly, “Test in the Wild” was congruent to pilot usability testing that project teams have been performing.

I wouldn’t say that some parts of their philosophy are ”different” than the ones taught in this class. It is that some parts of the 37signals are not exactly applicable to what we are doing in CS160. For example, things like “Get something real up and running quickly” in “Race to Running Software” and “Design for regular, blank, and error state” in Interface Design chapter were not ideas that we were exposed in CS160. I don’t find the 37signals process preferable because I think the one taught in this class is more applicable to mobile app application development.


Samir Makhani - 4/24/2013 0:08:12

Similar to the process taught in CS160, one of the first steps of the 37 signals is to design and define the "one-point vision for your app." It begins with creating a vision that should be brief and get the idea across. This was also the first step in CS160, which is to design and brainstorm a particular idea for your application, and determine a user-market for you to focus on. This is also directly conveyed in the "Hire the Right Customers" section since it advocates that one should determine the "core market for your application and focus solely on them." The 37signals philosophy also emphasizes the importance of prototyping something rapidly, and to iterate over it and until it gets better and better. The 37signals also differs in some senses. CS160 focus's on iterating the product based on the user. The 37signals process, under the "avoid preferences" section, suggests that sometimes the application implementor should also decide the little details, and make the call on behalf of his or her customers, if the calls are simple. I feel that cs160 process will permit AB testing for situations where the implementor is confused whether a certain feature is beneficial or not, but stray away from "gut decisions."

I would not say that the 37signals process is preferable to the one taught in CS160 because it is very specific in some cases (such as the "Incorporate admin functions into the public interface") which may not apply to all application implementations. CS160's process is more preferable in my opinion because it's very simple, and can be used for pretty much any interface design.

Yuliang Guan - 4/24/2013 0:10:32

(1). The first point of 37 signals process is “what’s the big idea”, which is to explicitly define the one-point vision for you app. This is similar to our design process taught in CS160. Both of them require us to analysis what the tasks are and what the app stand for. And then define the app. Secondly, the 37 signals philosophy encourage designers work from large to small and not pay much attention to the details at first. This point matches our design process as well. In the process of implementation, we are also required to scale up low to high fidelity. In low fidelity, we use simple sketches or paper models to show the basic tasks of our app which may not include details at first. Another matching philosophy is “hire the right customers”, which is to find the core market for you app and focus on them, but not try to please everyone. Our design process also asks us to make sure who our users are, who our app is designed for, and focus on our target users. In addition, 37 signals emphasize the vision of an app is also important for users, but not only the features. Our design principles also believe the vision is significant. An successful app should have a clear, simple, and nice looking.

(2). Meanwhile, there are some differences between the 37 signals philosophy and our design process. For instance, the biggest difference is about when to scale. 37 signals suggest designers not to scale right now but to do it later when users start using it. At that time, you still have time to adjust and respond to the problems. However, our design process requires us to evaluate the app before real users start to use it. During the process of evaluation reveals problems with design, and then we need to re-design and repeat the evaluation process again and again. Furthermore, 37 signals advocate not to waste time on problems you don’t have yet. But the design process we learnt does not mention this. Instead, we’d better try comprehensive thinking during design process.

(3). Well, I don’t think the 37 signals process is preferable to the one we learnt in class. They have some aspects in common. However, in my opinion, the 37 signals place an emphasis on how to get more benefits from the market and how to save time on a particular app design process. It does not try to avoid problems during design process, instead, it only try to solve problems when they happen. The design process we learnt in class is more complete and detailed. It focuses on how to design a great app but not how fast we can put our design into the market. Therefore, I do like the design process in our class much more.


Christina Hang - 4/24/2013 0:45:17

The design process taught in CS160 requires a lot of time to test and get feedback from the potential users, but 37signals pushes for a faster launch. There's a big emphasis on low fidelity testing before actually coding, but 37signals launch their application that may actually have design problems and rely on their customers to complain or give feedback about the design. Both process are iterative and it requires the designers to go through the cycles a couple of times. Although it is a good idea to get the application up and running quickly to get real feedback from users, but taking the time to ensure the usability of the app and testing the design before launch is better so customers are more satisfied with the product.

Cong Chen - 4/24/2013 1:01:14

Some of 37signal's philosophy that matches with the design process taught in our class are iteration, getting low-prototype sketches first before actual coding, find the big idea, and brainstorm well in the beginning. All of these ideas of essentially follow what we have been taught in cs160. First, we must have a good idea of what we are trying to solve with our app. Then, we start out with sketches and work up with small improvements until finally, do we do the coding.

Some philosophy that differs are avoid preferences and race to running software. The reading argues that when deciding small preference details to just make a decision and move on. In class, we are taught to interview the users to find out what kind of preference they would prefer before making a simple decision and waiting for complaints to make changes to it. Another difference is that the reading urges for quacking getting running software working. From class, we do not race to working software; we slowly build up to it from low-fi to high-fi to prototype to working prototype and throughout the process, we want to have user studies and stuff to get feedback to improve our iterations.

I do like 37signal's philosophy because I feel like it's concise and very fast past; like there is little room for messing around. However, it does take this feeling to the extreme and thus, I would think a compromise between the 2 philosophies (37signal's and cs160's) would be idea.

John Sloan - 4/24/2013 1:20:54

For starters, the very first section of the reading is about finding a problem that app attempts to solve. 37signals asks questions like "Why does it exist?" to really understand the purpose of the app before delving in. Next, they say not to focus too intensely on details in the beginning. This is consistent with the ideas of brainstorming and low-fidelity prototyping. Just get the big ideas out there first, and add specific details last. They also advocate finding the correct audience for the app, such that you don't try to accommodate everyone, but instead use personas. The Rinse and Repeat section is exactly mirroring the design-prototype-evaluate cycle we have learned in class. The idea is to constantly be updating and redesigning until something is just right. 

One deviation I noticed was in the Race to Running Software section. 37signals advocates that getting to real software as fast as possible is best approach. In class we learned that this high-fidelity approach for prototyping can sometimes lead to poor design since people will become attached to their design choices before they are properly tested. Using low-fidelity prototypes are cheaper and more flexible in the long run. However, they do mention the value of paper prototypes in a following section and in the Interface First section they talk about not programming first, so it seems like a contradiction somewhat.

One spot I found interesting was designing the Blank Slate of the app as well, not just when its flush with data. I hadn't really thought about the situations where the app might be used for the first time and have less data to work with visually.

In general 37signals follows very closely with the design process taught in class and does not seem any more preferable.


Brian Chang - 4/24/2013 1:26:23

Many things are similar in what is taught in CS160. For example, we worked on our apps mission statement as something short, we were taught that we needed to working in iterations, and starting with designing before coding. There are also differences such as we focused on getting an easy, medium and hard task up and running, but 37signals tells us to just get an app up and running quickly. We also combined the xml/html step with the background code step rather than making them separate. Overall, the two philosophies are pretty similar. I think there are different parts emphasized in each. It would have been nice if we had more time to work on the app so that we could go through more iterations and be able to test with more iterations. Working in iterations was taught in class, but it seems like we just have one long iteration.

Mukul Murthy - 4/24/2013 2:38:00

A lot of the 37signals philosophy is similar to the design process we have learned in this class. One of the highlights of the reading was the focus on the right customers, which we also touched on a lot in CS160. The customer base has to be focused enough that the app will actually benefit them. In particular, the "if you try to please everyone, then you won't please anyone" section reminded me of the Simpsons car from lecture, which tried to be for everyone but no one ended up wanting it. Also, the 37signals approach talked about the importance of getting a version out quickly, which is very similar to the iterative design cycle we talked about which involved early low-fidelity prototypes. Their version is paper sketches to HTML screens to full code; the analogous Android version is paper prototypes to Balsamiq prototypes to full code.

However, there are a few differences. One of the biggest ones is in the way designs are evaluated. In this class, we talked a lot about how to learn and improve a design from talking to potential users, both before and during the app's conception. However, 37signals has a different approach, which is to simply release it as a beta because people don't perform well in tests where there is a camera. Both approaches make sense, but I can understand why they choose to do their way for web apps. It also helps if they already have a small user base that will try their beta, something that not all developers have access to.

Kevin Liang - 4/24/2013 3:01:35

One philosophy that 37signals mentions is the get something real up and running quickly. That is what we kind of do in our interactive prototype by using a bunch of wizard of oz techniques to minimize the backend workload. On the user's side it seems real and is how the user would basically be using the application. It differs because our interactive prototype does not emphasize on speed but rather emphasizes the fact that it is the prototype stage of the application so details may be omitted. I believe that 37signals is preferable because speed is what should be emphasized. It is the speed that matters. Taking your time for the prototype is useless because it should be trivial to build the prototype to experiment with.

Achal Dave - 4/24/2013 3:36:28

The 37Signals process is very similar to the design process we learned in that it constantly hammers the idea of iterating on ideas as quickly as possible. The book argues that designers and developers should go from brainstorming straight to sketches to HTML, which is similar to our flow, minus a few steps.

The process is different in that it encourages a quicker jump to a technological prototype, which is interesting because of the arguments that 37Signals presents: that creating a technological prototype builds excitement ("this is 'real'"), that it provides a physical and direct interface to jump off of ("this is what it will look like on the screen"), and because it allows us to get a good understanding of the technical difficulties associated with the task ("what kind of budget will I need to build this?"). I would argue that in this sense, if we have designers who are very fluent with HTML/CSS, the 37Signals process is slightly better; of course the advantages are lost if the designers take more time to write a technological prototype and thus hinder the speed of the iterative process.

Ben Dong - 4/24/2013 4:03:40

Some aspects of the 37signals philosophy match the design process in CS160, such as designing the interface before starting to program. Other similar aspects include the design cycle from brainstorm to sketches to coding, working in iterations, and targeting specific user groups. However, some aspects differ as well, such as the fact that 37signals espouses testing in the wild via real world usage instead of conducting closed usability studies taught in CS160. Much of the 37signals process is similar, and while it is not necessarily preferable to the one taught in CS160, it is mostly complementary. Depending on the situation, it may be useful to draw from both philosophies.

Tananun Songdechakraiwut - 4/24/2013 4:20:20

Both state that we should get something up and running quickly and utilize iterations(like the design cycle covered in class). The article also describe the design process starting from brainstorm, sketches, mock-ups, and coding. These match the one taught in the class. Likewise, we have to test our design via real world usage and collect real feedback(Prototype testing such as Pilot study).

The article tends to favor designers just making their own decision so customers don't need to do hard work, and less coding as well. However, in class, those decisions come from observing target users.

No, it isn't. The main reason is because the 37signals is a subset of the one covered in class. In particular, CS160 design process is for general UI design purpose while 37signals philosophy focuses on designing web application and thus it is more specific to a particular aspect. 37signals design process may not be applicable to some other interface design. Therefore, it is unfavorable to prefer one over another.

Juntao Mao - 4/24/2013 6:41:29

The process described in the reading is quite similar to our process in CS160. Their philosopy focuses on always keep moving, getting fast ideas into running software, fake it to make it, similar to our philosophy for first iteration of testing. In their design process, they first start with brainstorming, thinking about what the app needs to do. Our process differs a little in that while we have very similar philosophy in brainstorming without rejecting ideas, when it comes to what the customer needs the app to perform, instead of thinking, we went to interview potential target users. After that, the philosophy from reading uses paper sketches, which we use in 160 as well. After that, the 37signals create fast html version of the feature such that people can see what it could look like. We also did a more solid iteration where we created low def prototypes using Balsamic. And from then, 37signals' process move on once the mockup is good enough to coding and reiterate. In 160, we move onto coding before mockup is fully finalized great. And we test in different stages of coding to get fast feedbacks and making changes as we code more of the app. Therefore, I prefer the process taught in CS160 since this version gives many chances to test along the design process, which is very important for UI design, because programmers should not guess what the users would think, but actually let them try it.

Bryan Pine - 4/24/2013 8:26:12

In broad terms, the 37signals process is similar to the CS160 process. Like CS160, they suggest beginning with scaling from big ideas to small details, beginning with brainstorming, "low-fi" prototypes like pen and paper, and html-style mockups for initial interface testing and then only moving to implementing the full code once you have seen some results from the low-fi methods. The 37signals methods talked about focusing on the main idea first and getting your main ideas out quickly, which is similar to what we talked about in the early parts of the class. Both processes stress iterative design and the need to have something tangible throughout all stages of the process.

There are also many differences in the two processes. The 37signals process (at least what we read of it) doesn't include a counterpart to the Contextual Inquiry or other pre-design information. Their process seems to involve making your app, and then finding the users that appreciate what you have made, rather than the other way around. It's not that the 37signals ignores user definition, it just doesn't seem as user-centered as the CS160 process, probably because the 37signals process is concerned with getting apps up and running as quickly as possible. Another minor difference is that CS160 tends to stress consistency throughout the interface, while 37signals specifically says that inconsistency can be useful in a lot of situations. In general, the two processes are similar, but stress different aspects.

I don't think that one process is necessarily preferable to the other in all situations; it depends on the application. In a time crunch situation where users are diverse or hard to reach, I might go with the 37signals approach because it involves getting a viable product out quickly, and working out kinks through user feedback later. If the first impression is more important and the user group is small, focused, and readily available, I would probably go with the CS160 approach because it involves more opportunities to build user information and preferences into the design from the beginning rather than waiting until later in the process where major mistakes are more expensive to correct.

Tenzin Nyima - 4/24/2013 9:13:15

From Brainstorming with wild ideas to implementing the app, the 37signals's design process is pretty much what we learned in the class. But in the process of Interface Design, the 37signals uses a technique called "the three state solution" where they design three different interfaces - regular, blank and error states. This is something we didn't do in CS160. According to them, regular state is the screen people see when everything's working fine and your app is flush with data, blank state is the screen people see when using the app for the first time, before data is entered and error state is the screen people see when something goes wrong. Having these three different state seems to be serving well when it comes to test your app. Another difference that I noticed is that in CS160 we spent huge amount of time for Task Analysis and Contextual Inquiry whereas 37signals process involve more of the actual interface design process. I personal prefer CS160 due to the fact that I think the app will come out much better if spend a better amount of time for task analysis. Overall, I think there isn't much difference between CS160 design process and that of 37signals.

Weishu Xu - 4/24/2013 10:01:38

It highlights focusing on the details earlier and focusing on big ideas first. it recommends focusing on a specific target audience, which was also highlighted in CS160. It even intends for software to take sides and for programmers to make simple design decisions for customers.

Get to running software quickly. In CS160, we focused on running through a lot of designs and tests before building out our software. It also focuses on iterating through real feedback. However, they did not run tests on their sketches, but with a full team of engineers working full-time, they were likely able to build out prototypes faster.

I liked how the 37signals book recommended that we focus on the blank state page, since it is when many users make the judgment about the app. It is something that may not have been specifically mentioned thus far in CS160 but is certainly very important to remember.

Tiffany Jianto - 4/24/2013 10:27:54

The 37signal philosophy has many overlaps with the design process taught in CS160. One major point of similarity is the fast design, prototype, and evaluate cycle. In in the design stage, we were encouraged to go from a very rough lo-fi prototype to a better Balsamiq prototype, and finally the final product. Similarly, 37signals also starts with brainstorming to paper sketches, to HTML screens, to actualy code; they overlook the small details in the beginning and their design process also works in iterations. They also tell us to focus on a narrow market, which is something we’ve learned is important in CS160: “If you try to please everyone, you won’t please anyone.” Finally, testing the application in the real world is very similar as well. However, 37signals does not recommend using a video camera or camera to record, while this idea was introduced to us in Wizard of Oz testing. We also didn’t learn much about releasing beta features much, which is an interesting idea. The specific details of the fonts, sizes, etc. for the interfaces we did go through in class as well, and they go through it very briefly.

We didn’t cover very much about preferences, to decide the little details so the customers don’t have to and that they are a way to avoid making tough decisions. Another idea we didn’t learn is what 37signals calls “Epicenter Design.” This idea says to design the main page that is the focus and most important page of the application rather than work on other page.

I think that both 37signals and CS160 cover a lot of important points about the design process but focus on different things. While CS160 leans a little more towards building user interfaces in the design process, 37signals is more concerned with the design process and how it should be done. I wouldn’t prefer one to the other, but I think they both complement each other well. And lastly, one of my favorite quotes was from the “Done!” section in chapter 6 where Derek Sivers multiples the idea and execution to see the value of an idea; I thought it was funny (because it’s true) and very interesting.

Brian Wong - 4/24/2013 10:50:13

37signals follows the general 160 Design->Prototype->Evaluate process quite closely. They constantly state how it is important to keep on pushing out updated products and getting feedback from users. However, there are many specifics they mention that are not necessarily accounted for in the 160 design process. For instance, in one article, 37signals explicitly says that sometimes you, the designer should basically tell the user what they want. You should "pick a side" and convince the user this is the right way to approach a problem. This is because a typical user may be able to say when they don't like something, but will often not be able to come up with some ingenious way of solving this issue. Therefore, it is up to us, as designers to take initiative and make bold changes, even if the user has a chance of hating them. That's what the next iteration is for. Another article "Avoid Preferences" further adds to this idea and says that there shouldn't be many options at all for the user. Instead, all these options should basically be decided by the designer (such as how many messages to display on a page). These are decisions that only bother most users.

I would say that the 37signals process is preferable partially because of where we, the class of cs160, are in our lives. We are all in college, have access to the resources of the best public university in the world, and live in the tech epicenter that people strive to be able to live in. The 37signals approach is about making tough decisions, creating minimal viable products, and making many mistakes along the way. This is much easier to do when you have customers that understand your pain and where you're coming from, and are surrounded by fellow entrepreneurs and mentors to guide you. And this is the exact environment we are in right now, which is why I feel the 37signals is something we should follow. We shouldn't be afraid to fail right now and make mistakes. We should strive to create great things fast, and learn along the way.

Claire Tuna - 4/24/2013 11:04:58

The 37signal philosophy's primary difference from the CS160 philosophy is its underestimation of the power of low fidelity prototyping. One of its advices was to rush into "real" implementations, saying that people tend to disagree over sketches. In the 160 view, these arguments are crucial for redesigning the sketches. 160 claimed that higher fidelity prototypes lead to more superficial feedback, i.e. "this font is too big, this spacing should be more", rather than the fundamental reworkings that occur at a low-fi level. So maybe in the 37signal framework, there are fewer arguments about design, because people are nitpicking at these higher aesthetic levels, but fewer arguments and fewer redesigns likely don't lead to the best, most thought out interfaces. Also, 37signal asserts that you don't really know how something will work until it's "real", but in my project group this semester, paper prototype testing led to crucial problems and insights about the design. Many confusions are visible to users on a piece of paper--it doesn't need to be on a phone/website.

The 37signal reading got a few things right : the idea to design the interface before you start programming, define vision before coding. This is in harmony with 160. However, they had little to say about the design cycle being a cycle. Design sounded, from their document, like something to get out of the way before you start programming. They had no notion, like CS160 has, of redefining the vision after designing a prototype, and performing this loop until time/money is depleted.

I think the 37signal philosophy is a little too hasty and dismissive about the design process and too eager to see "real" software built.

Erika Delk - 4/24/2013 11:13:57

Like the process taught in 160, 37signals recommends that you design the interface of your application before starting to program, and that you view the development of your application as something to be done in iterations. It differs in the emphasis on the three-state model for screens, the wording used in the interface, and the idea that the designer ought to make an application that offers less preferences to the user to cut down on the time the user has to put in. I think that the 37signals process is very similar to the cs160 process, and that the book's process might be more ideal for actual real-world startups that have a lot of time and money on the line, while cs160s method is more ideal for semester-long projects.

Linda Cai - 4/24/2013 11:26:28

Our process is to design, prototype, then evaluate, and continue repeating based on user input. 37signals suggests to get something working, iterate the design a lot, while testing the design on users. They also suggest moving from brainstorming to an HTML mockup to actual coding. Broadly speaking, both process have a number of similarities in there is a cycle of continuous revision based on feedback. However, 37signals seems to suggest getting something working as soon as possible, possibly starting from a worse state. Whether that method is preferable or not is rather context-dependent and no judgement can be made in general.

Yong Hoon Lee - 4/24/2013 11:32:22

The most critical part of the 37signals philosophy is to iterate. Indeed, Chapter 6 focuses, in a large part, on just that, namely the importance of iteration and getting some version of the project working. Both processes therefore really emphasize rapid iteration, believing that seeing an actual product will enhance the future experience for the developers and customers, and planning for everything is impossible. Furthermore, they also utilize brainstorming and sketches as parts of the iterative process.

The differences lie primarily in the brainstorming stage, as well as the different processes for designing the interface. In CS 160, we focused a great deal on the brainstorming process, looking at IDEO's rules and others, and cited it as an integral part of the iterative process, in which ideas are generated and culled down, with an emphasis on collecting all ideas possible. The 37signals philosophy is much more lax about brainstorming, with simple suggestions to perform it so that the group's priorities can be in line, but not much focus on the actual structure of the brainstorming. Furthermore, 37signals focuses on smaller details of the interface design process, emphasizing an "Epicenter design", and prioritizing the user's blank slate experience as well as the three different program states of error, regular and blank. These details are not as emphasized in CS160, which focused on the actual iteration cycle. It appears as though the 37signals process is less concerned with having a structured cycle, and is more concerned with the processes governing the design and execution of the product, despite both processes' emphases on iteration.

The 37signals philosophy is not necessarily preferable to the one taught in CS160. Rather, they can be thought of as complementary to it, as it allows for more structure in the iteration process, more tailored for startups. One can combine the iteration cycle taught in CS160 as well as its brainstorming philosophies with the design and execution philosophies outlined by 37signals, as each one emphasizes the less-emphasized parts of the other, and they do not contradict.

Nadine Salter - 4/24/2013 11:54:25

The 37signals process, like CS160's, calls for rapid iteration, but it eschews CS160's more formalised process (several user testing scenarios with low-fidelity prototypes) in favour of building and testing many fully-functioning versions of the product in a less-formal setting. This process works well for HTML-based applications and has practical advantages over a heavily academic process in, say, the startup world. It is not, however, objectively better or worse than CS160's—in the case of, among others, mobile applications, building a functioning native prototype requires significant time and effort, and so the low-fidelity prototype approach is more appropriate.

Elise McCallum - 4/24/2013 11:55:52

In order to consider how the philosophies align, I will juxtapose each chapter with CS160 individually.

Chapter 4: Both CS160 and 37signals focus on thinking big and being able to easily summarize the purpose of your application. They also both emphasize the iteration element and improving one's design through every iteration. While in CS160 we are not directly taught not to be a perfectionist, we are encouraged to make changes to our interface each week and thus not worry about creating a perfect interface in one iteration. 37signals also teaches the importance of a target user group so that each application has a unique and meaningful purpose and audience. One thing that differs from the way CS160 is taught is that 37signals instructs developers to not worry about problems that do not yet exist. In CS160 we are taught to think about scalability of our application and how our application would face problems in the real world, while 37signals encourages waiting for those problems to actually arise before addressing them. A second difference is that 37signals emphasizes the idea of opinionated software, which is not a concept we touch on in CS160.

Chpater 6: Both CS160 and 37signals support getting an application up and running quickly, even if there are problems with the application and it needs to be refined in terms of design. They also emphasize that the changes that need to be made will make themselves apparent as users start to interact with the application. Both processes also focus on iterations as the key to the development cycle and profess beginning with brainstorming and moving to sketches then implementation. The two methods also both emphasize testing one's app in the real world with actual users to see how people would actually use or not use the application. While they breakdown the testing process in different increments than taught in 160, 37signals also encourages using smaller time frames for task completion.

Chapter 9: Like 160, 37signals encourages designing the interface before implementation instead of designing concurrently with implementation. 37signals does differ from 160 in that it professes starting from the core page and building outwards, while 160 makes no mention of such a technique. 37signals also goes into details about planning for three states (blank, error, and regular) while 160 does not teach this particular technique. 160 and 37signals both do encourage building defenses in one's application in order to troubleshoot and solve errors when they arise.

Overall, the two processes seem too similar to determine if one is preferable to the other. I personally find the one taught in CS160 to be preferable, while the 37signals process is certainly a thorough and successful design process.

Aarthi Ravi - 4/24/2013 11:58:11

37signals philosophy matches the design process taught in CS160 in terms of the priorities. We were asked to narrow down our target customers and make an App catering towards their needs rather than try to satisfy everyone. When working on the low-fi prototype we were asked not to worry about implementation issues but to just test the concept and design of our application. These principles are the priorities mentioned in the 37 signals reading. We were also encouraged to develop a prototype quickly which was the interactive prototype and we were made to do a couple of iterations after testing prototypes in the real world. This closely matches with the 37 signals philosophy of "Race to Running Software" and "Rinse and Repeat". It differs a bit in the interface design. Though we designed our interface first before starting to code we did not consider the "The Three State Solution" or having a back-up "Defensive Design". For the most part they are similar. 37 signals philosophy is more comprehensive in the interface design process which is necessary for a real world application but for a class project it may not be necessary.


Brent Batas - 4/24/2013 11:58:59

37signals philosophy is similar in that it emphasizes low fi prototypes and mockups before actual programming. It similarly emphasizes agile iteration and building upon continuous feedback from real time customers rather than spending a lot of time up front to release something polished. In addition, 37signals recommends describing the application in terms of stories, which is much like the user stories we discuss in cs160 for coming up with tasks. Other similarities are how 37signals encourages planning for all scenarios—error prevention, recovery from errors, and otherwise being “defensive.” This is similar to interface principles we learned in cs160.

Some differences are that I think 37signals places extra stress on being lean and only including things when absolutely necessary. The cs160 process seems to be more in line with, “if customers need it, we should build it.” In other words, for cs160, the customer has the final say, whereas for 37signals, I think the designers have the final say—they have a vision, and they stick to it no matter what.

I really like the 37signals emphasis on minimalism and saying “no.” It is a design principle I’ve held tightly to ever since I designed games in high school, and it’s probably the principle that I think has made my designs succeed where others have not (i.e. I truly believe a big reason why my games are popular is because of all the neat features I said “no” to). And, when I work together with people, my philosophy of saying “no” to virtually everything at first is something that leads me to conflict a lot. They take it personally, as if I’m unwilling to give them the benefit of the doubt because of some personal bias, but really I’m just saying “no” because I, like 37signals, believe features need to work really hard to deserve implementation.

Very similarly related, I love how 37signals stresses that your app needs to be opinionated. Some people I’ve worked with like to build things that are as flexible as possible, because it seems the most “powerful” that way—i.e., don’t limit features, and give preferences for anything that might differ among users. I think the result of this is lukewarm software that nobody really can complain about, but nobody really wants to use, either. I think it’s very true to life, in general, that if you try to please everyone, you will please no one. So it was awesome reading 37signals’ take on it.


Monica To - 4/24/2013 12:00:10

   From the chapter selections of 37signals' book, Getting Real, I definitely saw similar design philosophies to those taught in CS160.     
   Chapter 4 and 9, Process and Interface Design, had the most similarities. It described the design and implementation process for creating a web app or any kind of software product. Like from CS160, Getting Real emphasized the importance of designing first with low-fidelity mock-ups because paper sketches and HTML or Balsamiq mock-ups are much cheaper and faster than writing code from the get-go. In chapter 6, 37signals had a section called "From Ideas to Implementation", their method described is almost identical to the brainstorming and early design phase that Prof. Hartmann walked us through with our own group projects - We brainstormed in the Woz with our groups and created low-fidelity mock-ups with Balsamiq. Getting Real also encouraged the iterative process of constantly moving forward instead of dwelling on certain details. This was similar to what we learned in CS160 with the development cycle. This way of developing an software product is meant to be quick with iterations of improvements and changes. The last aspect of the development process that 37signals described that matches a philosophy taught in CS160, was the importance and value of testing with real users and getting real feedback. By testing iterations of our app, we can iteratively gain more information and insight about how we could better design our app for our target audience. User testing is not only important to the development process, but it is also very valuable.
   The main parts of the chapters of Getting Real that differ from material taught in CS160 was probably the additional information. Chapter 9 included many new and additional philosophies that CS160 did not cover. It covers more detailed and specific information regarding the actual designing of interfaces. For example, in the section "Three State Solution", it goes it more deeply about the nitty gritty details of a screen like the components, state, copywrite, preferences, and etc., while CS160 has a more general approach in elaborating on interface design like generally critiquing existing UIs on the surface but not really going into much depth about the components of the UI. 
   Overall, there are many design philosophies between 37signals' book and the material taught in CS160 that overlap. And the details that don't overlap are still quite similar in spirit. I think it is good to see the whole range of design processes because there is no one correct design/development process. Different applications and software products will require different processes and one process used in one project may not be the right/most efficient process for another project. 

Christine Loh - 4/24/2013 12:06:50

The 37signals philosophy begins with "working from large to small" and "ignoring details early on", which is similar to the design process taught in CS160 in that lo-fi prototypes are first made just to gauge how it works out with users before moving upwards and working harder on a more complex prototype. Finding the core market audience is also important to both processes. However, the main difference is that the 37signals philosophy encourages people to simply publish their apps even if they are simple and have not been tested yet. In CS160 we are taught to make multiple stages of prototypes and test each stage thoroughly, confer on the results, and come up with the next stage. There is no publishing until at least a few stages have passed. I think the 37signals process is preferable in some cases, but in most cases we want the most polished app, so the CS160 design process would be preferred.

Timothy Ko - 4/24/2013 12:15:02

Both the 37 signals philosophy and the CS160 design process focus on finding the right target users. They both share the sentiment that you can’t please everyone. The paper and the class also think that multiple iterations are a good idea, since you will be able to constantly revise your application and make it better with each new iteration. For this to happen, each iteration cycle should be short, no more than around a couple weeks. Additionally, they should be tested by real world users, not the developers.

There are a number of differences, however. There is a general notion in the 37signals philosophy about ignoring the details until they become a problem. They think that you should get the general idea of your application through and worry about other things like small design choices later. This also extends to when they actually implement their running software. Their thinking is that you shouldn’t waste time with mockups and sketches and just try and get a working prototype up as fast as possible. This is in stark contrast with CS160, where we believe that mockups can help with getting rid of bad ideas before they even get into the actual application. The paper’s idea of no preferences is another contrast with the class, since it implies that developers should rely on their own intuition. This is something that CS160 is strongly against, as we were taught to trust completely in the users.

I prefer the CS160 design process. While you shouldn’t waste too much time on paper interfaces and mockups in general, I think it helps to at least go through one cycle of mockups to get a preliminary idea on the design of your interface. CS160’s focus on the idea of iteration cycles is more emphasized than it is in the 37 signals. Also, there are a lot of conflicting ideas in the 37 signals paper.


Eric Xiao - 4/24/2013 12:28:15

37signals philosophy is a very startupy way of thinking. Build build build, iterate iterate iterate, users users users. Don't sweat the small stuff, just test it out on customers and see what they think and find your target audience. You can't listen to everybody.

I prefer the 37signals process if only because I love startups. I think CS160's design process is very similar, but focuses a lot on errors, experiments, and tasks, as well as adding a bit of formalism to the process. 37signals process focuses on getting things done, plain and simple.

Minhaj Khan - 4/24/2013 12:39:39

The 37signals philosophy matches the design process in CS160 in that it involves designing the interface before writing the code, which is what he have been doing with the interface designs and prototypes before writing the app code. It also differs, or rather has elements not discussed in 160 in that it encourages designing pages from the core and then outward and designing the interface in three states. These ideas are an add-on to the design process not conflicting with 160's design process but adding more onto it.

Its not clear which process is preferable, since both have their own values and ideas which work well. CS160 has more methodology and ideas from all stages of production that are needed to execute a successful app, while 37signals outlines specific ideas relevant to their design situation. It would be a combination of the 160 ideas with the 37signals ideas that would be best and give more direction.

Ben Goldberg - 4/24/2013 12:47:06

Working from large to small is a philosophy that is taught in CS160, definitely. We start with very loose ideas, but from that we move on to low fidelity prototypes and then high fidelity prototypes. This is an example of working on the large details before working on the small ones.

Pretty much all the concepts in the reading are ones we follow in 160. Perhaps the Context Over Consistency chapter differs however. I believe we were taught to have a consistent interface.

Nothing is black in white. It's hard to say if one process if preferable to the other. If I had to choose though I would say I'm more comfortable following the process in 160. Perhaps this is just because I'm more familiar with it however.

Tiffany Lee - 4/24/2013 13:00:09

37signals' and CS160 philosophies match in their proposed overall design process. For example: both teach to work in iterations, to design first then program, and also to not sweat the details in early designs by making low fidelity mockups and increasing in detail as iterations increase.

However, the two philosophies do differ in terms of the details on how to implement an idea. For example, 37signals' teach its readers to not care about scale when programming and to deal with it when it needs to be taken care of; however, in CS160 Professor Hartmann gave us an example of Friendster losing a lot of its users when they had to re-implement its whole infrastructure because they couldn't scale up. Another example is the difference in design decisions. 37signals teach for applications to give as few preferences and options for users as possible; this clashes with the teaching of flexibility as a design heuristic taught in CS160. 37signals also teach context over consistency which clashes with consistency as another design heuristic taught in CS160.

The overall design process taught by both I believe are basically the same. Some details of how to implement the application differ. In terms of which are preferable, I believe is determined by the context. For example, sometimes its best to be consistent, other times, although more risky, its best to design based on what you think makes sense. However, I prefer the CS160 philosophy of keeping scale in mind when implementing the application because it seems more efficient to do so than to just ignore it and then try and fix it later.


Alexander Javad - 4/24/2013 13:09:36

The design process we learned in CS160 lecture was 1) Design 2) Prototype 3) Evaluate 4) Repeat. The 37signals "philosophy" or design process matches up entirely with CS160 design process.

Firstly, chapter 9 of 37signals begins by saying "design the interface first!". Then, chapter 4 of 37signals emphasizes defining the one-specific vision for the app as well as focusing on the "big picture" at first. This corresponds to the "Design" section of the CS160 design process because we are specifying the scope of the application, the problem it solves, and drawing paper or Balsamic mockups to get a "big-picture" view of the application.

Secondly, chapter 6 focuses more on what would correspond to the "Prototype" section in the CS160 design process. This chapter discusses the importance of getting a working prototype up and running (based on predetermined mockups) as soon as possible,because the goal is not to be perfect but to iterate on a working prototype by testing with real users. Which, speaking of user-testing, chapter 6 of 37signals also discusses how crucial real-world user testing is to the design process because that gives valuable feedback to improve the application. Again, the goal is to iterate and improve upon the application, and user testing allows us to "Evaluate" our initial prototype's usability and make informed decisions, based on user-feedback, to improve the application.

It is clear to see how the 37signals process matches up with the CS160 design process and how both processes are iterative in nature where we continuously design, prototype, and evaluate, making the application address users needs better and making it easier to use too.

Timothy Wu - 4/24/2013 13:11:05

The 37signals philosophy matches the design process taught in CS160 in that the two processes are highly iterative. 37signals makes sure to emphasize quick and dirty implementation at the beginning so that you can prove the application in the real world. They stress that you shouldn't focus on the small details before you should or stress about issues so far in the future that they are basically immaterial. CS160 has a similar philosophy in that you start out with really bare-bones prototypes and work up from there. At the beginning, you show testers your Mockups, then your Lo-Fi Prototype, and then a version of your product half-implemented, just to test out the minimum features required to determine whether your app is usable or not.

After each trial run, you then collect results and make improvements. It is this feedback loop and improvement that really set the development of the application moving forward quickly. Planning ahead of time is error prone because you can't make accurate predictions about users whims and preferences in advance.

The 37signals philosophy differs in that it is focused more on the creation of applications for the purpose of creating a business. Since the goals are different, this translates into different priorities. Their philosophy prioritizes quick and dirty design at the beginning because it allows them to push out a product in front of users as fast as possible. The 160 process on the other hand is focused on pushing out a quick prototype at the beginning in order to gauge usability and design. The CS160 process is more about ensuring product integrity and quality iteratively, while the 37signals philosophy is much more holistic towards creating a business.

In my opinion, I think the 37signals philosophy is more preferable because it has a more big picture outlook. You have to look at design and usability in the context of the entire system, meaning your organization, your business model, and your industry. I think their philosophy really captures this gestalt view of software creation, and rightly puts design as an extremely important piece, but not as the sole focus.

Oulun Zhao - 4/24/2013 13:14:00

In cs160, we were taught about low-fidelity prototype, which matches with the section "Ignore Details Early On". During agile development, the design changes on a fast pace therefore, it makes sense to focus on important parts only at the beginning and polish up the details later.

In "Avoid Preferences", the reading recommends to make decisions for the users instead of having them choosing. However, in class, this concept was barely touched. cs160 recommends us to make common tasks easy to use and rare cases possible as for design principles.

I think both have its own pros and cons. In order to say which one is more preferable, we need to take the context of the application into consideration. I personally feel 37signals probably will suit web development better while the process taught in cs160 suits mobile development.

Brett Johnson - 4/24/2013 13:29:08

The two different design philosophies do match up when we look at the overall design process. In CS160 we have talked a lot about the process of starting super low fidelity with paper drawings after a brainstorm and then scaling up form there. At 37signals, while there are less in-between steps between the paper prototype and the final product, they still start their project with a brainstorm and paper sketches before actually building anything. And, the omnipresent mantra "iterate, iterate, iterate" is stressed in both philosophies.

One point that 37signals and CS160 differ on is user testing. In class, we have talked extensively about conducting different types of user testing, while 37signals states that "formal usability testing is too stiff."

I think that which process if preferable depends on the circumstances. The 37signals process may be more efficient when working in a small team that is trying to push out a product quickly, as these are the conditions that they are working with. However, if the team is larger and has more resources for things like usability studies, I think that the approach taught in CS160 may be more beneficial. I have learned that tasks like user testing can give you information that faceless user statistics with beta features simply cannot provide.

Dennis Li - 4/24/2013 13:37:01

Their philosophy focuses on thinking up a big idea and then implementing that. They work to get the main functioanlity of the app implemented before focusing on the problems that could occur and only address those problems later. They don't focus on designing an app for a certain group of people, but instead build the app then modify it to conform to a group of people. Additionally, a topic we didn't really talk about in 160, but 37signals scales their app as they need to, rather than right away. I think that the 37signals philosophy has some strong points but also weak points as well. I feel that their model is a bit weak in the fact that if they don't foresee a large problem there could be huge issues with functionality and cause a problem with their business. Additionally, by not focusing their app on a specific group, they may be making it too broad of an app that doesn't do what any group really wants. The good thing about their philosophy, however, is that they build their apps in a very streamline and rapid way, and it's likely quick to add functionality and there is short latency between pushes.

Andrew Gealy - 4/24/2013 13:43:52

Their design process for the most part describes more micro level decisions than the process taught in 160. Still, there are some similarities. Both focus on an iterative approach, encourage the early use of low fidelity prototypes, and encourage testing with real users. 37signals seems to reject formal usability testing, though contextual inquiry would probably be one response to their criticisms of ecological validity.

I feel like the process described by 37signals is sufficiently different that it's hard to say whether one is preferable over the other. They certainly mention a lot of lower level details that are helpful and would be easily applied to the cs160 process.

Harry Zhu - 4/24/2013 13:49:03

One process described in the book was get a working prototype done as soon as possible. It emphasized mainly on quick ramp up to get a working product, then iterate through it many times to refine it using quick design choices and user feedback. It matches the design process described in CS160 by emphasizing many iterations in the design process. It emphasizes that you as a designed won't get everything right the first time, and to fix your mistakes after each iteration. It is also similar in that it knows the importance of user feedback. It differs as it really focuses on getting a working implementation as soon as possible, rather than focusing on lo-fi mockups or prototypes.

Edward Shi - 4/24/2013 13:52:59

The 37signals philosophy matches the design process taught in CS160 in many ways. First off, they emphasize iterations which is also what is taught in CS160 (design prototype evaluate).This is good because it is almost impossible to get every right the first time. Also, they suggest finding a target user just as in CS160. The reason being is you can't please everybody and everything is good for something and worse for another. Another similarity is the focus on quantity over quality during the brain storm phase. 37signals talks about how it is not worth thinking about problems that don't exist at a certain stage sine different issues may arise. They also stress the use of paper prototypes just as we did because paper prototypes are quick and easy. Most importantly, they are cheap and easily changeable. The similarities include finding a target users and not overthinking and being bogged down by details in the beginning. Also, both 37signals and CS160 stress testing our app in the real world beyond just heuristic evaluation. Always get real target users to test out the application as they are the ones using th application and they are the ons who know their needs. One difference I did not ice is that 37signals stresses the significance of having a vision in the beginning. However, CS160 says it is alright if direction changes in the middle as it takes time to decide whether an idea will work. CS160 also did not have HTML coding prototype. CS160 also stressed having tasks and then designing interface as opposed to simply designing an interface. I think this may be good for our class since we dont' have a true vision and may switch ideas at any time. However, for industry, it might be good to start with the interface since they have an idea of what they want and need. I think both processes have the advantages. CS160 was good in the way that allowed us to explore many different ideas. However, I believe 37signals might be better for industry if they already have an idea of what they want and need. Then having a vision and sticking with a vision will be more important than exploring ideas.

Edward Shi - 4/24/2013 13:53:28

The 37signals philosophy matches the design process taught in CS160 in many ways. First off, they emphasize iterations which is also what is taught in CS160 (design prototype evaluate).This is good because it is almost impossible to get every right the first time. Also, they suggest finding a target user just as in CS160. The reason being is you can't please everybody and everything is good for something and worse for another. Another similarity is the focus on quantity over quality during the brain storm phase. 37signals talks about how it is not worth thinking about problems that don't exist at a certain stage sine different issues may arise. They also stress the use of paper prototypes just as we did because paper prototypes are quick and easy. Most importantly, they are cheap and easily changeable. The similarities include finding a target users and not overthinking and being bogged down by details in the beginning. Also, both 37signals and CS160 stress testing our app in the real world beyond just heuristic evaluation. Always get real target users to test out the application as they are the ones using th application and they are the ons who know their needs. One difference I did not ice is that 37signals stresses the significance of having a vision in the beginning. However, CS160 says it is alright if direction changes in the middle as it takes time to decide whether an idea will work. CS160 also did not have HTML coding prototype. CS160 also stressed having tasks and then designing interface as opposed to simply designing an interface. I think this may be good for our class since we dont' have a true vision and may switch ideas at any time. However, for industry, it might be good to start with the interface since they have an idea of what they want and need. I think both processes have the advantages. CS160 was good in the way that allowed us to explore many different ideas. However, I believe 37signals might be better for industry if they already have an idea of what they want and need. Then having a vision and sticking with a vision will be more important than exploring ideas.

kayvan najafzadeh - 4/24/2013 13:55:29

One thing (which is very important) that has not been mentioned in the 37signals design process is the iteration cycles. In our design process we have this loops which will help us detect errors early on but 37signals to me is more like a waterfall process rather than a iterative one. But they still suggest to be flexible and not start coding at the first stages but starting with mock-ups and fixing errors as you go.

Matthew Chang - 4/24/2013 13:57:04

The most important thing in the 37signals philosophy is getting something tangible quickly and then iterating upon it. This closely follows what was covered in the first few lectures in CS160. Iteration allows for building up momentum, making things tangible, and for catching problems with more ease than say a waterfall development paradigm.

37signals' design philosophy starts to differ when it comes to the interface design. There is emphasis on just getting something out, which is much more different than the research process used in CS160. In class, we are taught the value of doing contextual inquiry and performing background research to make a more informed design. The philosophy outlined in the reading does not emphasize this and instead assumes that the developer already has a good idea of what is needed.

The process described in the reading can be preferable depending on the situation. It is geared toward web development, where iterations have near zero cost. This allows for the arguably more reckless behavior when it comes to designing the user interface. Whereas with what we are doing in CS160, android app development is nowhere near as flexible and there is a variable size lag between when an update is pushed and when a user sees the new update. Also, since we are working on an android app, one may argue that the user must be more invested in using the app versus a web app because of the effort required to download the application for use.

Kimberly White - 4/24/2013 13:58:02

The two philosophies seem very similar. Both say to pick a "core" or target user group and focus the design on them. Both encourage iterations and testing with users, and making changes as you go along. The two models also say to design the UI first, before any code has been written.

There are some differences suggested in the Interface Design section. For example, 37signals says to do Epicenter Design, starting with the core functionality and then working in things like navigation and tabs. In class we weren't taught one way or the other, but my group found it more natural to start with a frame and overall navigation before working out the details of each page. 37signals also talks about integrating admin features, and has very rigid concepts of what pages should look like, such as suggesting each page have 3 different states.

Overall I don't think there are any major differences in the design processes from class/37signals, but the one taught in class seems more geared towards learning and just starting out, while the 37signals guide seems to focus more towards polished, ready to be released to the world apps.

Jian-Yang Liu - 4/24/2013 14:00:05

Similar to CS160, the 37signals philosophy tells us that we should ignore details early on and focus on the big parts, of drawing out the big parts that will be the main parts of the prototypes. Also, we should not overbuild unless it's necessary to. So things such as more servers and whatnot shouldn't be worried about until we've already completed the previous step: creating a great software. The main design process is also very similar, of working in iterations so that we can get something real up and running quickly so we can look at it and see what decisions/changes should be made. What it does differ, however, is in that there are times where we should just launch the prototypes with what we have, solving problems that we currently have. Only when new problems do appear should we try to solve them. Also, it believes that we shouldn't try to please everyone, but only those who the app is really intended for. There are also a lot of stuff on the interface design section that aren't as talked about in CS160, of designing each screen with regular, blank, and error states in mind. There are parts of the 37signals process that is preferable to the one taught in CS160, particularly the parts that tell us that we should lavish attention on the things that require immediate care, and work on the rest of the stuff later. Further, we should focus on the interface design first instead of the core programming so that gaps won't show between the two. Finally, the idea of the three state solution is especially intriguing, as it indeed is a core matter that all interface programmers should know and use immediately, rather than at the end of the iteration when we're attempting to bug test the app.

Ryan Rho - 4/24/2013 14:00:07

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

I have been using 37signals' one of the most successful products Basecamp since early 2000 and I was amazed by how its product has been evolving up until today. Not only its user interface is intuitive, 37signals is also great at adding a feature without disturbing the layout of the previous features. As a result, both basic users and advanced users enjoy their scope of features.

First of all, 37signals emphasizes the importance of user interface design. Rather than jumping into programming, user interface design should be implemented, which is also taught in CS160. This will eventually reduce the cost of the development by reducing the cost of modifying the user interface and its supporting back-end API.

Starting with the core features and then speeding out to sub-features is one of principles learned in CS160. Rather than completing one feature in detail, designing core features first makes you see the big picture of how your product is going to be and what kind of users you are targeting for.

Where does it differ?

37signals mentions that the interface is your product. Although this is mostly true, but this is more suitable for a consumer product. This may not be always the same as business software, although the importance has been growing. It differs with CS160 in that while 37signals say that the interface is your product, CS160 mentioned about several possibilities of development process based on the size of team or company. Some could still to waterfall process and others would do agile process. Although CS160 also believes that a waterfall process is not effective, it implies the possible alternative thought process about how your product is described.

Is the 37signals process preferable to the one taught in CS160?

Although CS160 deals with more extensive methods of user interface design, 37signals suggested its own method, thus simpler. It feels to me that 37signals made a method incorporating several methods we learned in CS160. In addition, the recent success of its product Basecamp makes me want to try its user interface design method, so I prefer 37signals' process.

yunrui zhang - 4/24/2013 14:01:59

The 37 signals philosophy match the design process taught in CS160 in a way that it discourage to work too deeply into a project, which would mean making process that takes a lot of work and hard to reverse. And it also favors a particular target user group and revolve the design of the project based on the needs of those customers. It also have a brainstorm phase. The philosophy differs from the design process taught in CS160 such that it shrinks the prototype and testing phase, and start from design to html to coding. Then the test phase only occurs after coding. It also specifically emphasis the design of 3-state.

Zhaochen "JJ" Liu - 4/24/2013 14:04:03

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

It matches the 160 design philosophy for the most part. For example, in Chapter 6, the sub-chapter “Rinse and Repeat” emphasize the importance of iterations. Likewise, in the CS160 class, the “design-prototype-evaluate” loop is taught a lot of times as well.

In addition, Chapter 6 also talked about how to use brainstorm ideas and make them into sample interfaces (HTML) first. In our CS160 project, we used the same methodology: we first came us an idea and used Balsamiq to mock up the interfaces.

Where does it differ? Is the 37signals process preferable to the one taught in CS160?

For the most part, they are the same. Something is different is that the “Getting Real” book also talks about “Test in the Wild” that they suggested that we should test the application in a real world situation. However, in the class, we mentioned a lot of different test strategies, such as Wizard of Oz, Pilot User Study and Low-Fidelity prototype.

Depends on the situation, one methodology is preferable than the other. “Test in the Wild” method is good for getting massive feedback from the real general public. It should be used for some commercial application that is intended to be released to the public in the soon. It is a fast way to test things. However, the testing methods we taught in classes are taking smaller steps as we are doing tests at different stages. It is good as an academic approach. Also, if you are not in a rush, taking baby steps make more sense and reduce the possibilities of publishing the wrong products to the market.

Derek Lau - 4/24/2013 14:05:51

One point where the 37signals philosophy matches the design process in CS160 is creating a design first before implementation, as seen in Chapter 9. Both philosophies push for an idea of a design to be formed first, because design ideas are easy to switch in and out, before committing something to software, which is harder to change. Alongside the idea of design-first philosophy is a concentration on creating solid customer-facing, front-end design interfaces first. Both 37signals and CS160's emphasis on front-end design is key to achieving customer pleasing software.

One point where the 37signals philosophy differs from the design process in CS160 is the idea of quick prototyping, as seen in Chapter 6. Both 37signals encourages getting a version of the product up and running quickly as quick as possible, de-emphasizing mockups and wireframes. However, in CS160, mockups were a big portion of the design process when we used myBalsamiq and tests were even done with them.

For myself, I prefer the CS160 design process because of the emphasis on prototyping. I believe that getting good feedback on design ideas and prototypes is important to delivering a good final product. If the entire feedback process is rushed, the end result becomes sloppy and requires more time and work to clean up on the final product than if the earlier iteration had been better evaluated.

Lishan Zhang - 4/24/2013 14:08:31

The 37signals philosophy matches the design process taught in CS160 for most of the parts. As for the priorities part, “Ignore details early on” is the same when we do our own application. We will focus on the major features rather than finishing all the features at one time. The Process Chapter talks about “Rinse and Repeat” which professor emphasizes that we need to work iteratively in design process. And “Shrink your time” is what we do as a group: break the project into small parts and assign the task to specific person. In Chapter 9 for Interface Design, They design the interface first before really implement it. And we are also asked to build the UI and test before we fulfill the features.

However, the 37signals philosophy also differs in some part. For example, we didn’t “hire the right customers”; we only do the persona for our target customers. And “Test in the Wild” differs from what we exact do. We only test with a small group of people.

I think 37signals philosophy has some advantages in working an really application in a company, but it costs much more then the way CS160 taught. But basically they are quite similar in design process. I personally prefer the way CS160 taught.


Sangyoon Park - 4/24/2013 14:27:37

I believe that the 37signals' phiosophy almost matches with what we learned from cs160. From 37signals' philosophy, deciding priorities, process, test, and later improve interface designs are very similar to the design process (Evaluate, Design, Prototype, then iterate).

Each small sections of chapter 4 (Priorities) are about how to do a better brainstroming, and the process of idea creation - idea selection. I liked the sentence, "If you try to please everyone, you won't please anyone." that was exactly the same as we learned from the class before (with the weird looking car with the Simpson's father).

Chapter 6 is about creating low-fi prototype, test, and iteration. These are almost the same as what we did through the semester in this class.

Chapter 9 is more about some details that are focused on actual user interfaces before writing the code, and how to improve the application for better user interactions.

Avneesh Kohli - 4/24/2013 14:27:37

The 37signals philosophy definitely matches the design process taught in CS160 with regards to designing and programming in iterations. They strongly highlighted being able to get the minimum amount of designs or prototypes out into real customers hands so you can learn from that and make adjustments on the fly. This is exactly what we did in CS160 through the low and hi-fidelity prototypes along with their associated usability studies. I would say that the 37signals philosophy is a little bit more lenient and flexible than the process we followed in CS160. A lot of their process is dependent on context and the project they are working on, while CS160 was more of a scientific method that everyone had to follow (possible because of the constraints of a classroom). I'd say the 37signals philosophy is more preferable because every software application is of different nature, and thus the design and development of the app can't follow the exact same process, which is why a more flexible and on-the-fly approach would work better.

David Seeto - 4/24/2013 14:28:12

They work from lo-fidelity to hi-fidelity, ignoring details in the initial process. This allows for spending less resources initially and then putting in more effort as the ideas become more solid. They also try to take sides, which is very similar to developing a very specific target user and trying to account for only that group's personas. In addition, they have rapid prototyping, working in a cyclic fashion to iterate again and again. There is also the mindset associated with this that we can always come back to it, just move forward. Testing is also done with real users, allowing for feedback to help aid further prototypes. Finally, there are techniques to help with the design process: prototyping the design, designing for the norm, accounting for the irregularities, etc.

They take various further steps not necessarily presented in CS160. For example, they tell us to ignore problems until it becomes a problem. Rather, getting critiques can help avoid problems. They also claim to decide the little details for the customers, which can be risky. The idea of states are novel and the epicenter design is similar to the building for representative tasks, but doesn't really focus on tasks.

Overall, I feel that their process is more based on industrial experience and practice. In contrast, the theory based process taught in CS160 is the ideal, it works and it irons out a lot of wrinkles. In the end however, that might not be the case in the practical world. Also, the 37signals process takes some leaps that I am uncomfortable with such as deciding the little detailed for customers.

André Crabb - 4/24/2013 14:28:26

The philosophy from the 37signals book matches the process taught in CS160 when in comes to the design cycle. They recommend with starting with Designing, or the interface. One thing that stood out to me was how they recommended to not focus on the details. In fact, they say to ignore them, and ignore perfection, until later. Also, both methods know that you can't please everyone, and that you have to pick a specific audience, and not try to make an app that does everything. However, they don't specifically say to test your prototypes as your get to higher and higher fidelity.


I think that both patterns have their pros and cons, but I think I'd prefer some of the 37signals methods/philosophy due to their straight-forward approach.

jin ryu - 4/24/2013 14:30:31

There are a few similar sections in 37signals philosophy that matches the design process taught in CS 160. These would be:

  • A focused mission statement - both the class and 37signals emphasize how important it is to start with a clear and brief vision of the app. It prevents too much wandering and cuts out irrelevant additions.
  • Narrowed target audience - both advise that it is impossible to please everyone. Knowing who the audience is and tailoring more specifically to their needs instead of trying to target a more general group will be beneficial to keeping the app on track instead of having it fall apart.
  • Minimize available options to user - Too many buttons and options will confuse the user and is messy. It may also cause more bugs to deal with in implementation.
  • Iterations and analyzing again - Feedback is beneficial, and improvement is done in repeated iterations. Nothing is set in stone and the process is done in layers with information-collecting analysis each time.
  • Design before programming - Designing is low cost compared to programming where time may be focused on fixing bugs rather than design concepts themselves. Both suggest using paper sketches and mock-ups.
  • Decisions are temporary- As an iterative process, nothing is set in stone. Decisions can always be changed though the cost is different.
  • Addressing error states - It is more user-friendly to have a state that can clearly indicate when there is an error with a detailed log instead of surprising the user by shutting down or no response.
  • "Copywriting" or using words and labels - This suggestion by 37signals ties in with recognition by user to understand what a button does or how to use something in an app. A vague picture may not be as intuitive as a clear-cut label.

Other aspects of 37signals philosophy are different. These are:

  • Disregarding problems that may arise in the future/Scaling - The class may have suggested thinking about scaling issues, although not a heavy factor, so that a good foundation can be set before launching the app in case the app doesn't scale well and by the time the problem is fixed, it may have lost its target group. However, 37signals philosophy says the bigger challenge is getting the app to gain that many users in the first place and scaling should not be worried about until later.
  • Focus less on stories, mockups, and designing because getting started on interactive prototypes is more important
  • There is a stronger focus on moving forward and getting implementation done and improving actual coded app
  • Suggested design cycle by 37signals is Brainstorm -> Design -> Implement. This is slightly different to the class design cycle of Design -> Prototype -> Evaluate
  • Testing is done with beta versions and informal evaluation through real use testing. It ignores formal usability testing and recording data with camera, etc.
  • Context is emphasized over consistency where somethings may be done depending on the situation according to 37signals philosophy. In class, consistency was important.

Is this more preferable to the one in class? The philosophy seems aggressive but it does have a few good points. It also converges with some ideas from class. However, it seems more focused on starting up an app as fast as possible instead and making it effective instead of getting a more thorough design.

Jin Ryu - 4/24/2013 14:30:47

There are a few similar sections in 37signals philosophy that matches the design process taught in CS 160. These would be:

  • A focused mission statement - both the class and 37signals emphasize how important it is to start with a clear and brief vision of the app. It prevents too much wandering and cuts out irrelevant additions.
  • Narrowed target audience - both advise that it is impossible to please everyone. Knowing who the audience is and tailoring more specifically to their needs instead of trying to target a more general group will be beneficial to keeping the app on track instead of having it fall apart.
  • Minimize available options to user - Too many buttons and options will confuse the user and is messy. It may also cause more bugs to deal with in implementation.
  • Iterations and analyzing again - Feedback is beneficial, and improvement is done in repeated iterations. Nothing is set in stone and the process is done in layers with information-collecting analysis each time.
  • Design before programming - Designing is low cost compared to programming where time may be focused on fixing bugs rather than design concepts themselves. Both suggest using paper sketches and mock-ups.
  • Decisions are temporary- As an iterative process, nothing is set in stone. Decisions can always be changed though the cost is different.
  • Addressing error states - It is more user-friendly to have a state that can clearly indicate when there is an error with a detailed log instead of surprising the user by shutting down or no response.
  • "Copywriting" or using words and labels - This suggestion by 37signals ties in with recognition by user to understand what a button does or how to use something in an app. A vague picture may not be as intuitive as a clear-cut label.

Other aspects of 37signals philosophy are different. These are:

  • Disregarding problems that may arise in the future/Scaling - The class may have suggested thinking about scaling issues, although not a heavy factor, so that a good foundation can be set before launching the app in case the app doesn't scale well and by the time the problem is fixed, it may have lost its target group. However, 37signals philosophy says the bigger challenge is getting the app to gain that many users in the first place and scaling should not be worried about until later.
  • Focus less on stories, mockups, and designing because getting started on interactive prototypes is more important
  • There is a stronger focus on moving forward and getting implementation done and improving actual coded app
  • Suggested design cycle by 37signals is Brainstorm -> Design -> Implement. This is slightly different to the class design cycle of Design -> Prototype -> Evaluate
  • Testing is done with beta versions and informal evaluation through real use testing. It ignores formal usability testing and recording data with camera, etc.
  • Context is emphasized over consistency where somethings may be done depending on the situation according to 37signals philosophy. In class, consistency was important.

Is this more preferable to the one in class? The philosophy seems aggressive but it does have a few good points. It also converges with some ideas from class. However, it seems more focused on starting up an app as fast as possible instead and making it effective instead of getting a more thorough design.

Alysha Jivani - 4/24/2013 14:32:11

Some processes/principles on which the 37signals philosophy and the design process from CS160 agree are:

  • “Ignore Details Early On”: It is important to have a broad range of ideas and more of a general idea early on. Through user testing and later iterations, the details will start to fall into place and changes will become evident.
  • “If you try to please everyone, you won’t please anyone” : importance of having a focused, clear target-user group. (e.g. the Simpsons car that we talked about in lecture)
  • “Half, Not Half-Assed” (& “It Just Doesn’t Matter”): We didn’t really discuss this notion of cutting the functionality of your product/app in half. It’s an interesting concept, though, and may complement the design process philosophy that we learned in the sense that encourages focusing on specific tasks that are essential.

They seem to differ on some ideas, including the following:

  • “It’s a Problem When It’s a Problem”: While it makes sense to not worry about issues that aren’t pressing, part of the design process that we learned/discussed involves thinking about elements or process flows that can be difficult for users beforehand. Perhaps not worrying about non-urgent issues immediately makes sense, but it’s definitely important to anticipate potential user interface issues that can arise while in the designing phase. It’s also important to prioritize issues (something both philosophies have in common).
  • “Human Solutions”: While it does make sense to leave some personalization of functionality up to the users (and users will not always use an app or product the way it is intended), one of the main ideas from CS 160 is that you should understand these various user needs beforehand so that you can adequately integrate or support it in your implementation.

Overall, I think it is a good idea to have a combination of both approaches. Personally, I prefer the approach taught in CS 160 since it’s a bit more focused on user research and understanding the user needs in order to guide the implementation. It sounds like the 37signals approach relies more heavily on decisions that the developer makes (and possibly less on the user needs). I think this could be detrimental to the success and popularity of the product or app, so it’s a better idea to found most design decisions based on user needs and feedback.