Final Reflection

Since this is the last reflection of the year, I wanted to focus more on the semester as a whole than the individual class, as we just talked over our ideas and selected one and began fleshing out a presentation for our final day.

Over the course of the year we took a very rough idea to new heights, and really focused on the specifics of what it would take to bring an idea to reality. I found the interviews were probably the most enlightening part of the semester, and was relatively close to half-way, when we had finally gotten up to our top speed.

It was difficult to find interviewee's, as we couldn't just ask anyone. The issue was, our project REQUIRED that the people we wanted to interview be busy most of the time, which made it hard for us to find a time when they could talk to us. This difficulty was important though, because it taught me one of the most important lessons of the semester: hook people in, then get what you need.

It's simple really, by sending a long email like I did at the start asking for their help and including some of the details, it became a chore for the busy individual to respond, and so they simply ignored it. Later, with some tips from class, I sent a short email just saying that we are interviewing people and if they would be interested, which elicited a response much faster.

Another important point about getting people to help you, for interviews and beyond, is to know them personally. I interviewed my dad and my dad's cousin as well as Abdul Mahdi of IIT, and it was much easier to get time with the people I knew more personally. This shows the value of what many of us have heard about, but not seen evidence of: networking can be more important than anything else.

Later on we looked at different ways to view a problem, such as the user journeys and 5 why's. I wasn't, and honestly, am still not, a fan of the user journey. However, I can understand why they are used: so that you can get a better vision of how the users will use your product/service/offering.

The 5 why's was interesting to me, because it is a simple iterative process to get to the root cause of a problem. Many times, the cause is more important than the problem itself or the solution (for example, people wanted to be connected to their friends and family, they didn't specifically want facebook, it just filled a void that people didn't realize they needed filled).

And finally, if I would do anything different, it would be this:

I would encourage everyone to participate more, and take more responsibilities from Ray. I felt like many people in the group did very little, and Ray would commonly try to take charge of quite a lot. I was in a group with him for Bus100 and he did quite a bit of this too, and I feel as though he sometimes needs to be reminded that other people can and should be doing more. I understand it completely for this topic specifically, because it is his project outside of bus104 as well.

Super Hunch Reflection
(hunch itself in previous post)

We looked at the Really Big Value Idea Sketchpad earlier, but I had almost completely forgotten it, but after having used it I find the idea intriguing, especially in relation to the Super Hunch application of it.

Looking at all aspects of a project, from the people on the team to the users and the offering itself gives a great overview of what the goal is. My idea, related to a rule of "People use creator-defined applications" (I didn't want to use one of our previous rules because I didn't find one that formed a good idea in my head) I decided to work with:

SUPER HUNCH: 

REPROGRAMMABLE/CUSTOMIZABLE 

INTERFACE USING TEMPLATES AS DEFAULT

I thought it was a pretty good idea, maybe not world-changing but interesting and could change the way we look at app's on phones and tablets. Talking to my roommate and friends gave me some good feedback and the most important one I found was that they all found it quite a feasible idea. Problem is, none of them thought it was very impactful, and I can't say I disagree with them. None of them placed it in the 'SUPER HUNCH' area in the upper right of the graph, with the best rating of only 7/6. I need to look at this more. I'm sure I can find an idea that really is worthy of that upper right section. I feel like I need to refine my idea more to move it up. 

Super Hunch

Click for larger view

Comments from the people I asked about the idea:
"You could do it pretty easily, but it might require users to understand some code."
"Might be difficult to make it work correctly, and even if it did, would anyone use it?"
"I don't know how useful that would be."
"Could be really interesting. Might need work."
"I wouldn't use it."


Feasibility/Impact Ratings (X out of 10):
5/6
8/2
5/5
7/6
6/4

Breaking the Rules

The average know the rules.
The good follow the rules.
The great bend the rules.
The best break the rules.

I don't know exactly where I heard this (and it was probably in a different format) but it is something that jumped into my mind when we began to break the rules in our last class. Sometimes we are restricted and don't even realize it; we impose rules and string red tape everywhere, even when it isn't necessary. So what happens when instead of working within the confines of 'reality' we step outside our preconceived notions and realize that a house doesn't NEED to have square corners, a vehicle doesn't NEED 4 wheels or a classroom a teacher?

Our group did well with the exercise, coming up with many different ideas stemming from rules surrounding our project. The only major failing we had was in the making up the rules, rather than the breaking. Instead of rules like 'the app must fit on a phone/tablet screen' we had ones akin to 'people have limited time'. While this is true, it is more a statement of fact than a rule that can be broken for the betterment of the project. After we got over this road bump we found it easy to get going on some of the important assumptions of the project.

That of course is the most important part of breaking the rules: finding them.

The rules that we imposed on ourselves were unspoken and had not been identified, and this class taught me quite a bit about the assumptions I make in my everyday life.




RULES

1. Managers make decisions
2. Displays have are limited to manufactured size
3. People use a keyboard with a desktop.
4. Act by time constraints.
5. People keep track of tasks.

CRUSH CONNECTIONS

1. If managers did not make decisions, then teams would make decisions or use a random process to do so. Teams will need a centralized system to make and view decisions. Or computers can make decisions.

2. Displays are adjustable to size. People can take their work anywhere they are and scale their display to their liking. There would be no need for mobile and desktop operating systems because the screen is adjustable.

3. People don't use a keyboard with a desktop. People think about what they want to be entered. People talk with their computer.

4. People don't act by time constraints. They don't need a calendar, they need a list of things. Their schedule is very flexible.

5. People don't get overwhelmed. They retain to their usual ways and perform the most important things first. People can do as many things as possible at once.

Word Association and Weird Ideas

From waffles to sports shoes and other crazy ideas, the chance connection method for ideation has proven itself before. In class we tried to use this method, and to start with a random noun we went to a random-noun-generator online. At first we got Daffodil and we decided that probably wasn't a good starting word. In hindsight, we may have been wrong.

What we decided to go with instead was the noun 'attitude' which is much less concrete than a noun like waffle or daffodil. We ended up having many variations on the theme of expectation, mindset and many more. Essentially, there was little variance in our associations and we had issues coming up with ideas based around words like mindset.

Off the top of my head I came up with one jokingly related to daffodil and I think it is this that illustrates best why we should have started out with something less abstract than attitude. Essentially I whipped up off the top of my head something along the lines of:

"use the fibonnaci sequence spiral for ordering things like the leaves on a plant or the seeds in a sunflower to organize objects in the application in a way that everything is visible and compact to save space"

Of course I was kidding at the time but that is the kind of thing that we should have been coming up with. With what we actually did, we got almost nowhere and even though we had more time than others because our "How Might We's" did not need to be revised, we didn't get very far into the 'crazy ideas' part of class.

On a separate note, at some point someone said 'crazy isn't really my thing'. I thought this was interesting because the way I looked at it, if crazy was anyone's thing, would it be crazy?

During class we pored over our various interviews looking for similarities and patterns that might illustrate what future users of TimeTraxx may want. We came up with a few very common themes, which propelled us into thinking about possible solutions.

These themes were:
· Ability to easily quickly access/add/manage tasks no matter
  location/device
· Synchronization with Google Calendar/Tasks
· Relevant reminders/alerts
· Deal with a long list using priority

The first one is the problem that I personally have had the most issues with throughout my attempts at managing my time more efficiently. From notebooks to excel sheets and calendars, I always find that the tools take more time to use than they save, and when you cannot access the tool that you rely on, it can be stressful and destructive. This is the issue that I personally think the most time should be spent on, as users will not find the tool useful if they cannot save time using it.

Many users specifically mention Google Calendars. This points out a few things about the future of TimeTraxx. First, much of what Google Calendars does seems to work quite successfully and we may benefit from adapting some of their ideas. Secondly, they may be a stark competitor to such a start-up.

While less common that the first two, reminders and issues with priorities in long lists came up a few times each. To combat the issue of long lists, it seems quite natural to simply include a priority system and allow users to sort their tasks in to customizable categories. However, the tasks of non-intrusive and relevant reminders may prove more of an issue. How might we create a reminder system that does not interrupt a meeting, but still gets its message across?

Overall this weeks class was quite productive, although I believe that some of the members could participate a great deal more than they did. It might not be necessary, as we were able to find a good deal of themes without the full attention of everyone, but for their learning as well as the health of the group, it may be an issue in future.

Looking at themes in our interviews provided great insight into what users THINK they need, but we were unable to come up with any 'unmet needs' that lay buried beneath the literal surface of their words. Hopefully with more time and a better understanding of our users, we will find our 'secret sauce' that will jettison the project into a place as solid as Google Calendars.

Reflection 1: Frameworks

During class we looked at three different frame works for thinking about various ideas and projects.

The first, the POEMS framework, was interesting in its own right. I feel as though it allows a group to really nail down what the important factors in their success are. There is very little room for being vague using each of the five sections, People, Objects, Environment, Message and Service. This could definitely be useful in any group I am in, as the rigidity focuses the users on figuring out exactly how their project will interact with the team and its users in various ways. Although, I felt that 'message' lacked the qualities of the others and had a little too much room for interpretation. Rather than message, I feel METHOD might be more useful: how will you deliver the product,  how will it be made, how will your service be better than others, and in general HOW WILL IT SUCCEED?

Back to the second in a moment.

The third, the user journey, was what we spent most of class toying with. From only a few minutes of using it, I really felt like I got inside the 'customer's' head better than I had ever before. You really have to think like your users, and figure out what might be difficult for them, why they would want your services, and how you can make your product better for the only person that matters, the user. Many different paths can come out of the user journey, and it might still be difficult to find all of the intricacies of your user base, but the more tools you have, the better you will understand your market.

The second one, though, was the one that really made me think. We didn't go over the 5 Why's in class as much as the user journey, but more than anything else I found the 5 Why's an incredibly intelligent way to get to the root of the problem. It is not enough to ask why you want some service or product to be made, you must understand why your users would want it, and to know that, you need to know what causes their need, and why it hasn't been fixed and why and why and why ad infinitum. The 5 Why's made me really think about getting to the very heart of a need; it focuses on the reasons for something rather than the something, so that the creator can understand and tweak their offering (or, if used for personal use, understand their problem).