Leana N

The next component of our project was to conduct user research. It was important that we interviewed the stakeholders of our project, the people we were trying to serve, in order to adequately address the problems they face and observe how they currently work around those problems. We were given two weeks to identify who we would speak with and to arrange meetings, as well as figure out what methods we’d be using to get information. 

The Process

We chose to implement surveys and interviews as the primary methods of research for our design project.

The main targets of our research were international students and medical personnel. We chose to survey international students due to the fact that they are likely to have a different healthcare provider in the United States than in their home countries. Initially, we perceived the process of filling out paperwork to be a significant burden for international students not only due to the language barrier, but also the fact that hospitals most likely wouldn’t have access to their full records. We suspected that some international students may have had their documents translated to English as part of the procedure of enrolling in universities in the United States. However, based off our survey responses, we discovered that most internationals only needed basic vaccination records on file, and that in most cases their full medical records are still in their country of origin. When they visited a hospital in the US, most said that the paperwork process was not very extensive and only took around 5-10 minutes. While language was a challenge for some, most did not consider it a significant drawback to their hospital visit experience. In fact, most thought that the waiting period for medical staff to process their information took the largest amount of time, ranging from 30 minutes to 2 hours.

Our team’s interviews were directed primarily to one of our direct stakeholders: practitioners in the medical field and managers in the healthcare industry. In pursuit of more detailed information from within these systems, we interviewed a number of different individuals including a pediatric trauma/acute burns/plastics nurse at Harborview Medical Center, a pharmacist, a manager at Hall Health here at UW, a nurse at Swedish Hospital and Ensign Dana Canaria, a patient care technician at the UW Medical Center, and a registered nurse in the Navy Nurse Corps. Across these professions there were a number of common threads. All agreed that the current information system in healthcare is, in practicality, functional, but could use some improvement. 

Nurses spend almost equal amounts of time filling out paperwork and charting their experiences as they do working with patients. For information to be readily available, there must be planning in terms of paperwork, authorization to contact any previous health providers, and general health information ahead of time by the patient, otherwise their healthcare group must be contacted and the process must be, as the manager at Hall Health described, “babysat” or monitored, to ensure timely transfer of data. Likewise, the system can move only as fast as snail mail, faxing, or phone calls which can take days, weeks, or months. 

A common desire expressed by our interviewees is a much faster transfer of information, where time spent gathering and authorizing the release of information could be directly administered towards treating a patient requiring immediate response. Information at the touch of a button, organized and authorized ahead of time, as well as a streamlined system for charting information, would go a long way to reduce the hours spent by healthcare providers in which they cannot help patients.

Moving Forward 

By taking these perspectives into consideration, we can now look at our design project from numerous lenses. To better a patient’s experience in transferring health information, we must equally better the experience of those who manage that transfer. By understanding what goes into transferring medical information and who is involved, we will be able to adequately address the design flaws in the current systems these medical professionals face, and provide a new and feasible design solution. 

Up Next

Now that we’ve conducted our user research, it is time to apply what we’ve learned. We will be wireframing in the coming weeks and creating the first low-fidelity prototype of our information system! 

The Breakdown

Essentially, our information resource project needs to solve a real problem faced by a real group of people. The core of our project will be to identify this group and a problem of theirs that can be addressed, to some degree, by information technology. In class we discussed thinking  beyond the immediate context; we thought about people who are typically under-served by information technology: chronically ill, people with disabilities, elderly, homeless, single mothers, etc. With this broad view in mind, we were to think about groups we associated with, or networks of people we are already connected to, to better prepare for when we spoke to potential users and researched the problem area.

By identifying the target user group and potential problem areas we could address, we needed to find out if there were already existing solutions  and how they already address our target problem area.

The Process

Within the week of settling with our groups, my team members and I slept on our ideas. It was the next day when I reached out to them to put together each of our thoughts in regards to the user groups we listed: the homeless, elderly, and college students. Some of the things we came up with were:

A "Left-over Drop-off" where students and restaurants could donate leftover food to the homeless. (It was Wynston who countered the idea by mentioning that restaurants wouldn’t want to be liable for health concerns that may arise from this solution.)

Designing an educational program that could be implemented in technical job training that would aid elderly employment in more technical fields.

Golf cart styled transportation systems across campus for disabled or injured students who couldn't take an Uber or a Bus to the heart of campus

We went back and forth on theses types of ideas until I took a step back and switched gears. I brought up the idea about the transfer of information between health care systems. I was particularly passionate about the topic of health care  because of the backseat view I've had of my mom's educational pursuit to become a Pharmacist. She'd been a technician for over 15 years when she'd gone back to school, so when she'd told me about conflicts in medication that some doctors don't catch or that access to background information being limited when needing to prescribe medication, it was as if a lightbulb switched on in my head.

I proposed the idea of the problem area being the maintenance and organization of medical information, including medication conflict recognition. Our users would not only be any and all kinds of patients, but medical professionals as well. We could focus on making the flow of information, accessibility, and authorization of medical file use more efficient for users and medical personnel. My group members were immediately keen on learning more about what we could do, how we could approach this type of project, and we set to work. 

The Problem Statement

The format of the problem statement was organized by identifying the target user, or stakeholders, first and foremost. This was followed by identifying the problem area(s) we would be addressing in relation to this group, and why they were worth solving. Lastly we listed current solutions that address the problems we noted, what these solutions already did, and why they didn’t completely solve the problem. The problem statement is attached below.

The Problem Statement

Now What?

I never associated myself with the medical field in general, but I think, given this experience, technology will be the bridge between myself and that foreign territory. Familiar or self-associative topics are usually a crutch in projects that require design, but this challenge was welcome to me and my group. Health care, medical privacy laws, the way different medical professionals organize their information systems, and subjects of the like will be questions we'll need to ask ourselves in the future of this project. As of now, I'm not too knowledgeable on the ins and outs of health care operations in general, but I look forward to learning and applying what I'll uncover in the future to this project.

This past autumn I took an introduction to Information Technology course (INFO 200). Led by Professor David Stearns, the curriculum included topics that centered around design thinking, user research, software user interface design, and more. At the start of the quarter, each student was assigned to a group of four, with whom we were to work, cooperate, and execute with through to the end of the quarter.  Every week in lecture a new topic was introduced (as listed below), alongside an assignment that each group would need to complete as a part of the many components to our projects.

Essentially, we were to come up with an "information resource”. Broad as that may sound, the only requirement was that it utilized some sort of “technology” (again, broad) to connect people with the information they need.

The Team

My group consisted of three other gentlemen, Koki, Gavin, Wynston, and myself. After the initial ice-breaker and lighthearted introductory jokes, we discussed potential topics we could focus on. Initially, this was difficult to decide on the spot - we didn't understand the core concept of the project yet and we had to make an important decision within the week, if not during this current class session. After a few moments to think, ideas started to flow.

The Process

The brainstorming phase started out slow and simple; ideas grew off of ourselves, college students, our problems, situations around campus, and other small scale thoughts.

I'd caught on to the ideas that other groups were throwing at each other and they seemed quite similar to ours, so I decided to switch gears. "Let's list some groups of people that are under represented or in some type of disadvantage in our society and see what we get." Believe it or not, our list grew from college students with poor Wi-Fi to hungry homeless people and elderly unemployment. We ended our first session together by identifying team member roles: myself as group leader, and Wynston as moderator - but with our fast growing dynamic, the establishment of these roles was quickly forgotten.  With our new team, we were set to create a problem statement for the stakeholders our project would focus on and build our project from there in the coming weeks.

Group Problem Statement

Topics in Information Technology (INFO200)

Information, Technology, and Society

Design Thinking

User Research

UX AND Interaction

Software User Interface Design

Designing Accessible Systems

VR/AR/MR Design

Designing Secure Systems

Data Modeling and Encoding

Information Architecture

Data Science

Data Visualization

Information Privacy

Intellectual Property

Digital Money

AI & Autonomous Robots

This week in lecture we had Jeff Heer and Kristine Kohlhepp as guest lecturers where Jeff discussed Data Visualization and his own work and Kristine presented about her Device Prototyping project.

Data Viz Process:  Jeff Heer

What was one aspect of Jeff’s project that stood out to you?

Jeff gave a presentation about data visualization and how his research topic went through different stages of translation to best demonstrate his findings and effectively represent them. Jeff explored how disciplines in a university interact and wanted to examine and identify ideas that bridge disconnected fields of study at a large scale. I was impressed with how fluidly he described the process of analyzing differences between relationships and similarities in data. What stood out to me was how he then used these techniques to develop a multitude of effective visual interpretations before creating the final outcome.

EMAR Project:  Kristine Kohlhepp

What was one aspect of Kristine’s project that stood out to you?

Kristine presented her EMAR prototype object, which happened to be a robot that was designed to assess the mental health of student population in real time. A lot of her research came from examining the environment of robots in teenager’s lives already. By analyzing their reactions, working alongside a psychologist, and asking students to create their own interpretations of the robot for reasons like how it would look, what it would say, and how it would sound, the brainstorming process was steady rolling. An aspect that stood out to me was how little she needed to be tech-savy to generate such a medium-fidelity prototype. Also, the fact that she was working alongside a psychologist, who the original idea came from, was surprising to me because of how the two different disciplines were connecting through the use of human centered technology.

Takeaways: 

Experience

This week in studio, we had to chose from a multitude of scenarios to generate three potential concepts and prototypes using Little Bits. I had never used Little Bits before, but after watching a quick introductory video, I anticipated the prototyping process to be reasonably simple. After playing around with the different pieces of the Little Bits, my partner and I chose to design a prototype that focused on when your roommate played music too loud. We knew that all of our prototypes would need the sound detector piece from our Little Bits, so our first step was to think about how we could bring attention to the roommate.

Figuring out how to use Little Bits for our chosen design challenges and brainstorming concept and prototyping ideas

Our first prototype set the sound sensor so that when a certain sound level was reached, the device would ring an even louder buzzer to notify the roommate. Another concept was a counter that kept track of how many times the roommate’s music volume met the level of sensitivity of the attached sound detector, as more of a form of documentation.

Top: The scenario drawing for our first prototype concept with a sound detector and buzzer

Bottom: A closer look at the individual pieces to the mentioned prototype (left to right): battery (power source), sensitivity adjuster, sound detector, and buzzer.

Our last concept was a little more mischievous because we decided to have some fun with the speaker attachment and MP3 player. If the roommate’s music met the sound detector’s level of sensitivity, the other roommate could blast their own music right back! 

Our Prototype Video!

My partner and I drawing out our scenarios for each concept of our design challenge

Reflection

This was my first time using Little Bits and it was definitely a pleasant experience. It exercised my creativity and imagination and was especially fun to play around with! I have never liked working with physical technology, favoring software in comparison, but this sprint was eye-opening for the fact that I witnessed my mind and hands create and recreate original things out of these Little Bits that I didn’t know I could. A problem my partner and I had with this sprint was thinking outside of each concept and not coming up with convergent ideas, like different forms of notification for the roommate. I think the next time I use Little Bits I’d like to have a bigger box set with more pieces to work with since the one’s in studio were limited to a set number.

What did I like most about this experience?

I think the simplicity and creative liberty that comes with using Little Bits is what made this experience so enjoyable for me. In the fifteen minutes that we had to experiment and explore the possible sequences and devices we could make out of these magnetic parts was so much fun, even humorous when different groups discovered how to make the little high-pitched buzzer work. I especially liked how the lack of complexity, creating little devices for a multitude of uses, managed to shed light on the bigger concept of low-fidelity prototyping and little ideas can grow in advancement and design to become something remarkable.

My Tableau Experience

This week’s sprint was focused on Visualization, specifically in terms of data representation. In studio, we downloaded Tableau, a program that specializes in data visualization and a Seattle 911-Incident data report. In pairs, we were given specific events or scenarios to represent using the data file in the clearest possible representation using Tableau. This was much more complicated than I anticipated. There were a multitude of filters, labels, colors, and variables in which we could organize our data, and with this data sample in particular, there was so much data to represent. Practicing using Tableau made using Excel seem easy in comparison, in my opinion. Some of the models, bar graphs, area charts, line graphs, and more, were limited to certain areas of measure or dimensions and I struggled with finding the correct variables to represent my particular scenario of data that was supposed to come across through the visual.

My Data Visualization!

Learning how to use Tableau, through trial and (a lot of) error, in studio

Reflection

Problems I encountered were narrowing down and making assumptions about my given user and their particular goal. My assigned goal was to find the most active areas at specific times for the Officer to feel busier (Picture Below). The problems with this particular goal was that it was quite broad in terms of areas (busiest district or street?) and “times”. I decided to find the busiest district, District K as shown in the table of my visual, and then the top three busiest blocks and the top five days within each month that they were “busy”. Based off of this experience, I would want to familiarize myself more with the program that way I would have been more knowledgeable about the navigation and utilities of the kit.

A post it note written by one of my classmates and distributed anonymously. This was my assigned scenario to create my particular data visual

Besides the Initial Frustration with Using Tableau, What Did You Like About It?

I think Tableau is quite useful for data representation, although unfortunate that I had a poor experience using it. I’m sure if I practiced using Tableau, and hadn’t been on a time constraint to learn how to use it and create a data visualization, I might have had a better experience. I liked it’s different visual structures and flexibility and found that these aspects would be beneficial towards companies or people who wanted to clearly and affectively present data.

Beyond the Assignment

This week in lecture, Jake Fleisher, a Principal UX Researcher from Blink UX, came in to talk about ideation and his brainstorming techniques in his professional work. Alongside him, Katie Derthick, a PhD student in the HCDE graduate program came in to discuss the work she uses user research for in her studies.

What did I learn about the ideation process from Jake Fleisher? What stood out to me?

Jake listed many things that are imperative in ideation work, like using your hands and making things, creating voraciously - crazy ideas always count! -, and drawing all the time. Many of his tips and techniques were important and I took interest in remembering, but it was his statement “Have your design conform to the people’s expectations of the design. Do not expect people to conform to your design”. This sheds light on the  professional aspect of ideation and production, in my opinion. For example, a designer could come up with a product or idea and know how to operate it, but asking people to conform to learning how to use it would be counterproductive. Focusing a design on the expectations of the consumer makes sense because their initial familiarity and assumption of the design will make introducing them to your design and making an impression much more amiable.

What did I learn about user research  from Katie Derthick? What stood out to me?

Katie’s studies were based on incorporating the way certain cultures and religions, primarily Buddhism, met technology and studying how society and technology shape each other. Katie covered a lot of bases with how she processes information with webs of notes and connections illustrated on the walls of her apartment, and how keeping a sketchbook with her all the time makes her very aware of the world around her. A takeaway that stood out to me the most was how she specialized in looking into a particular community to create and influence the design of things for a greater population, and to do this she encouraged studying about people. Being able to recognize and analyze reactions and practices of people throughout her user research helped solidify and categorize her data.

How might I modify the work I do in these areas to improve them?

In terms of ideation, I had a tendency of going somewhere with one idea and trapping myself within the shell of that idea without being able to generate something completely new after it. Jake mentioned to practice everyday with a topic or theme to get into the habit of coming up with new ideas one after the other. I also think too much. One of his techniques for brainstorming was to “Defer judgment”, that way you can avoid thinking too much about a particular idea and potentially hitting a dead end.

Sprint Prep in Studio:

This week in studio we learned about User Research. We were divided into groups of three and were sent to one of two places, Suzzalo library or the Engineering library, to observe students and their practices when studying. We were allotted ten minutes for observation and in those ten minutes we individually listed different observations such as where students sat to study, their body posture, and their interactions with people sitting with them (if any). Back in studio, our groups chose three specific practices from our notes and came up with different design challenges that they could be applied to and then presented them in class. For our own sprints, we were to observe at either a market or bus stop, take notes, identify three interesting practices, and think of a design challenge for one of these interesting practices.

The page of observations I made at the Engineering library in ten minutes

Discussing our individual observations from the Engineering Library and picking our three interesting practices for our design challenge presentation

What I Did:

For my own user research project, I sat at one of the bus stops I take everyday from school. I chose Stevens Way & Benton Lane because it is a commonly frequented bus stop in front of the HUB on campus and at 3:30, a time I usually take the bus, there is almost always more than 15 people at the stop. I started by counting how many commuters there were, and listing immediate observations like who was sitting and standing, how many girls/boys, etc. Next I listed common practices amongst the mass of people and then narrowed down on the people who did their own interesting things like pacing or turning their phone screen on and off. After 30 minutes I chose my three interesting practices: line formation when the bus arrives, back and forth eye contact between their cellphone and the street, and using the bus stop as a location to meet with friends or other rides.

A page from my field notes at the bus stop I observed and the bulleted observations I made 

My Method Technique and Field Notes!

Reflection:

Some things I struggled with for this project was identifying what was worth notetaking or whether or not my observations were significant and considered “practices”. Ultimately, I took note of everything, regardless but later when I read them over I had a bit of trouble picking and choosing the most significant and interesting practices to incorporate into a design. I think in the future I want to learn about people to understand their mannerisms in an observational sense to make this type of project easier in terms of interpreting what I’m watching. This would help with translating people’s practices and identifying ones that are actually practices, rather than basic habits, to apply to a design.

Why Is This Type of Work Important?

Noticing how many practices people at a bus stop has in common was eye opening for me. People-watching helped me understand that by taking note of practices, especially ones that are common amongst a large group of people - in this case, the commuting population- makes designing for a large group or population much more plausible.

Reflexivity:

Sketching my first 10 ideas for different forms of garbage management 

What We Did:

This week in studio we had an Ideation sprint that was centered around putting on our thinking-caps and sketching. We started out with warming up our drawing abilities with a quick holiday/vacation themed 10-minute sketching session. The topic had a broad spectrum which made it as liberating as it was constraining, in my opinion. There were so many elements to a vacation that can be focused on, but I found that it helped to think about what I did on vacation, primarily in the Summer, and the types of activities I did to narrow down my thought process. Later we practiced this again except with a specific topic, garbage management, with constraints and goals. I found this easier than the exercise before because of its specificity on the types of garbage management we were to think about and consider with our sketches. Our assignment, in relation to these exercises, was to generate 20 sketches on the topic given to our particular studio section: Commuting. 10 sketches for the range of different ideas and designs, and then 10 more sketches expanding off of a single design from the previous 10.

My Sketches!

Using hand gestures to describe how one of my sketches would function/be used

Reflection:

I’ve always appreciated art in all mediums and drawing was something I was comfortable with (in terms of detailed stick-figures and the like of course). I found this assignment challenging when it came to thinking about new designs and trying not to think about what has already been created. The first 10 sketches were easier to come up with than the 10 sketches derived from a single idea because I kept getting locked into one idea and then wouldn’t know how to start from scratch again for another one. I think in the future it would help if the topic was even more specific, or if it were centered around a model and an idea and a goal that was designed but needed improvement or some tweaking. I think then I would have felt more creatively inclined to generate more ideas than I was for this sprint.

What Constraints Did You Give Yourself?

With a theme like Commuting, there are so many more forms than the typical train, bus, bike, or car. I think that the constraints I gave myself were derived from my own experiences with these forms of transportation. I did not think beyond myself and did not consider thinking about skateboards, rollerblades, scooters and running-shoes as contributors to commuting for the simple fact that I don’t use them. It was after I’d finished my sketching that I noticed that my ideas were not that diverse from each other, and I believe it was because of these self-imposed constraints.

In The Real World:

Topic of the Week: Criticism

Design Prototyping One-Bus-Away: Alan Borning

        The first panelist, Alan Borning, a computer science professor at the UW, presented on the app One-Bus-Away. The app was once a student project by Brian Farris and Kari Watkins that grew and became a major commuting resource in the Seattle, and now in other major cities. Something I learned about the interaction design prototyping for One-Bus-Away (OBA) was that, like our Interaction Design sprint, one of their design techniques were to think of scenarios for their idea, or when it would be useful. They created a paper prototype of the app, took surveys of people who regularly commuted and what they would want from this design, and had beta testers for their app.

What was one aspect of Alan’s project, One-Bus-Away, that stood out to me?

     An aspect that stood out to me was how much research and real-world interviewing with the potential users that they did for their design, as well as, how much time was put in to make sure to accommodate towards those user interests and how that affected the overall product.

Nordstrom Usability Testing: Laura Barboza

       The second panelist, Laura Barboza, a Senior User Experience Researcher at Nordstrom, explained their design and review processes, user testing process, and overall breakdown of how they could make the layout of their website efficient and clear during their special Anniversary Sale.

What was something(s) I learned about the usability testing project for Nordstrom?

        What I learned from this usability testing project for Nordstrom was that they really took into consideration the design of their website, and how the colors, fonts, and layout affected the user’s understanding and their ability to shop during this certain sale. Like our Usability Test, they wanted to make sure that the user really knew what was going on, the Early Access aspect was tricky for some users. They had to make sure that the user knew how to navigate the website efficiently and correctly during the time of the sale so more members could receive their deserving benefits.

How might I modify the work I did on my own sprints in these areas to improve them?

This week in studio, we had to complete our own Usability Test on a coffee maker, in which we had to have 3 users perform 3 tasks and collect 3 types of data.

The Game Plan:

The testing process began with a brainstorming session in our groups to decide what three types of users, tasks, and data we would have in our experiment. My group thought outside the box when deciding what type of coffee maker to use, so while everyone else chose different types of automatics, we chose the French Press. It was more complex than having the user press a few buttons, I owned one for us to use, and we thought it’d give us some interesting results! When discussing targeted users for this test, we decided on college students, because of where our test would take place, who were frequent coffee drinkers and had never used a French Press before. 

(Discussing and listing potential users for our Usability Test)

Three tasks we thought would give the user the full experience of using the Press were 1) Set up the French Press; coffee grounds at the bottom, hot water poured in halfway (one cup) or to the top (2 cups), and the lid on, the plunger pulled up. 2) Brew and pour their cup; Let the coffee sit and then pushing the plunger all the way down. 3) Cleaning the Press; no grounds left at the bottom or on the plunger. 

(Deciding the types of data we’ll be collecting) 

With these tasks we sought to record each time of execution, the user’s level of execution (successful/unsuccessful) and their rating of satisfaction on a scale of 1 to 7 (1: very satisfied, 7: very dissatisfied). When we got our plan together, we wrote our script, reserved a place to hold our test, and determined who would bring what.

The Test:

On Tuesday afternoon, we got together, me bringing my Bodum Brazil French Press and coffee grounds, Warren his tri-stand to record the tests, Raina with the hot water, and then proceeded with recruiting qualified users to participate in our test. While Raina moderated, I took notes, and Warren recorded, we began our tests. Our first user was successful in executing most of the tasks for someone who had never used a French Press before, while our second user was unsuccessful in the set up, but did well with brewing, pouring, and cleaning. Both executed their tasks in similar short amounts of time, while our third user gave us a more unique data sample. Our third user took longer than both of the first users to set up the press, and even then was completely unsuccessful. They succeed in the remaining tasks and like the other users, found their experience with the French Press satisfactory.

 Our Usability Test Presentation!

Takeaways:

Overall, my first Usability Testing experience was a good one! I enjoyed this process, especially the feedback aspect that happens during the test directly from the user. Performing our own Usability Test made me appreciate the process for its insightfulness and its close observation of user-product interaction. This sprint was not as artistically and creatively liberating as the past few sprints have been, which is what I thought lacked for this project.

Why does Usability Testing matter?

Experience:

For this week’s sprint, we explored the processes of Interaction Design. Our task was to design a smartphone app, for one of the four topics allotted to us, that would support the practice of citizen science.

Before we could get to work though, we formed groups to brainstorm who the target users would be and what activities the app would include for each of these topics. 

My group listing type of users who would participate in the Animal Census experiment

When the general idea of what the apps would need was well documented, we separated into smaller groups to break down each possible aspect that would go into our designs. Some of these characteristics were the types of sensory and numerical data, the means of navigation throughout the app, and the motivational aspects to maintain user interest and engagement. My group was centered around a certain function of the app, Geo-Tagging a photo, and how it would operate and what actions would be required of the user to use it. 

My group discussing the actions the user would need to perform to Geo-Tag a photo within the app

After the dissection of all these components, our individual work began. For our citizen science experiment, we were to choose one of the four topics to create an app for, and then draw the multitude of screens that would be a part of it. As icing on the cake, we were to use an app, POP- Prototypes On Paper, to put it all together and animate it.

Drawing out my first screen on a notecard

My Prototype Design:

I decided to create an app for the animal census experiment. I had already envisioned what direction I wanted to go with this and was eager to get my ideas on paper. In class I listed all the functions that I wanted to include and framed the navigation between screens before I started drawing. I created my home screen first, developed an icon and a title for my app, and then mapped out the web of screens that would be directed from it onto a wide piece of sketch paper. I found POP really easy to use, figuring out the animation and buttons took some trial and error, but I managed to put my app together in one sitting!

My Prototype Demo Video

Some of the screens I drew out and used to create my paper prototype on the POP app

Reflection:

I thoroughly enjoyed the Interaction Design process this week. From brainstorming ideas, to drawing out all the individual screens, this week’s sprint was definitely as enlightening as it was fun! The artistic and architectural freedom for this assignment was definitely my favorite part. Drawing icons, using colors, and deciding on the transitions between screens was a great way of really understanding the operation of an Interactive Design.

Why is This Type of Work Important?

A prototype is like the rough draft of a best selling author’s novel. It’s the first draft of something that has potential to be better. It requires editing and revision, and sometimes needs to be thrown out and started from scratch. But the end results are the same: a best seller. Prototypes are meant to be rough around the edges, in need of tweaking, and without the chance for trial and error, editing and revision, a product would take much longer to be finished and considered adequate enough to be released.

Experience:

Week one of studio, we designed interfaces, some of us (me) doing so for the first time! It started with jotting down ideas of vehicles and users on countless sticky notes. After taking them all to the whiteboard and organizing them into categories, groups were assigned a vehicle and their target user(s). We set out to design a scenario, through drawings and diagrams, in which these users would use the vehicle. After setting up the situation in which these potential ideas would be used, and by whom, we set forth to designing the technology, applets, and features that enhanced the product altogether.  

(Sticky noting our ideas for various vehicles and users)

Reflection:

The process of designing an interface was definitely an enlightening one. I was surprised with how creative and expansive the ideas and topics of design could stretch- vehicles ranged from jets and electric cars to rollercoaster carts and lawnmowers! The technology and features that we used for these products were innovative and efficient in ways more than one!

I really enjoyed this project, for the reasons that I had never been a part of a group brainstorm and white boarding session, like the one I participated in during studio! The environment itself was filled with an openness for ideas and I felt confident and secure with sharing my own ideas. I liked the group oriented work that we did, having to agree/disagree and share and incorporate ideas within the group. I was truly surprised with how we managed to design something so cool!

(Our group discussing possible scenarios to incorporate into our design)

How does this apply to the real world?