Openly | An app that helps couples take the guesswork out of showing they care.

Openly is an app that helps couples take the guesswork out of showing they care by giving them obtainable suggestions for everyday life. People are in relationships with their partner because they like them, and they want to do nice things for them… But they don’t know what exactly to do all the time.


Openly is an app that helps couples take the guesswork out of showing they care by giving them obtainable suggestions for everyday life.


The heart of Openly is a simple app that gives people two suggestions a day of tangible actions they can do for their partner. Once they select a suggestion they can set a reminder for when they would like to be notified again.

4.29 Final Presentation_MM copy-03

These suggestions are based on an initial quiz to find their love language every user takes. The love languages are a framework that has helped millions of couples better understand their partner’s needs. Though it has been wildly successful in helping couples understand their differences, it still requires a lot of work for couples to integrate into their everyday life. Openly makes it straightforward and easy to integrate into your calendar no matter how filled it might be. 

4.29 Final Presentation_MM copy-04

The second quiz, explains how you think and make decisions. The quiz results will change the way Openly interacts with you. For instance, if you are an analyst, there will be more explanation on the reasoning behind the suggestions. Whereas an ally might need more notifications with their partner’s name in it to hold them accountable. Additionally, the quizzes give the couples an opportunity to gain a better understanding of one another. It expresses their differences and their unique individual needs.
4.29 Final Presentation_MM copy-05

In the Be Heard section of the app, people can add their custom suggestions for their partner. This takes away the awkwardness or pressure in having to ask for what they want in a low-risk way. They can also return to their ideas and edit or delete them as needed.



Here’s an illustration of how Openly takes your love language, custom suggestions, and swaps them with your partner.

4.28 Final Presentation.001


You can return to view and compare quiz results anytime through the Be You section. The Be You section gives the user a chance to review their quiz results, retake the quiz and compare their quiz results to their partner.  Being able to compare quiz results to your partner enables a deeper understanding of your differences. 

4.29 Final Presentation_MM copy-06

We conducted a one-week long user test with 3 couples lasting a week long. Every day we texted them two suggestions based on their partner’s love language. Only 5 days were skipped the entire week between the 6 participants. Meaning 88% of the time, the participants put Openly’s suggestions into action. During the exit interview, Brian said to us, it was like having a personal marriage assistant. Many times, he wants to do something nice for Kim but doesn’t quite know what, so he found our suggestions extremely helpful.


4.29 Final Presentation_MM.001

Transitions are stressful even if they’re good. About 44% of couples who get married each year are going to premarital counseling. This means people are willing to put in the time and money to have a healthy relationship. We know openly will be a great tool for couples when they are going through challenging transitions such as having a newborn or moving across the country. It can be easy to forget to be intentional in your relationship during stressful times. However, it’s in those moments where supporting your partner is critical.

4.29 Final Presentation_MM.001

Our next step is to conduct a local pilot and adapting our strategy to work sustainably with larger groups. This pilot will give us a better perspective of what types of nudges allow for behavior change. If you or anyone you know is interested in participating in our pilot, simply take this quiz and fill out the form at the end. We are also looking for potential developers and investors who share our passion for helping couples build stronger relationships through open communication.

User Testing with Openly | Week Five

Collectively as a team we’ve focused on creating complete user flows we could test this week. We went back and forth several times and iterated until we had something that was complete enough to test.

4-10 Blog Post .0014-10 Blog Post .0024-10 Blog Post .003
We completed our first round of testing with three users. We knew they weren’t perfect. There were many screens missing, but we knew it was enough to put in front of people to get a reaction. It became evident we had major navigation issues. We user tested with the Think Aloud method where we ask the participant to complete a series of tasks thinking out loud.We tell them at the beginning we are not able to assist them or answer any questions. User testing was reassuring because they were able to work through the flows without significant confusions. They all happen to be in relationships and excited about the concept. It was validating to hear some of them get excited about a product like Openly launching.

As we move into week five, there’s quite a bit to do. We need to continue to user test, iterate and refine our wires.

Our primary focus will be on figuring out our navigation system the beginning of the week. We will be presenting a practice round of our final presentations next week. A significant amount our effort will be spent working on our presentation as well.

Restarting | Q4

Coming back from Q3, we weren’t entirely sold on The Elephant in the Room.  We received feedback that we weren’t specific enough and as a result, our product was hard to believe. Some conflicts are smaller and can resolve through one honest conversation. Then some conflicts are formed over years and require ample time to address. We doubted our ability to provide the value promise of the Elephant in the Room, so we spent the first week revisiting our research. This inspired us to make a big pivot from conflict resolution to building open communication in romantic relationships.

We first asked what they were doing, feeling, and thinking now. Then we juxtaposed it with what we want them to do, feel and think after using our product.

Chase (3 of 4) Chase (2 of 4)

Chase (4 of 4)

Q4 is all about pitching, refining, piloting, and selling your idea. In order to truly do so successfully, we need to believe wholeheartedly in our idea. As a team we decided to make a shift, rather than catching couples when they are already upset at one another, we decided to shift into something that catches them sooner.

To gain a better vision of what value our product could provide, we conducted case studies on companies like Headspace and Joyable. This gave us a perspective of their approach, their business model, their value promise and how they have shifted as they have evolved.

Chase (1 of 4)

We are developing an app called Openly that helps couples build healthier open communication with one another.  Our phones have become one of the best communication tools so why can’t it be used to help us do it better with the ones we care most about?


We all grow up hearing about fairytale romances. We’re sold the idea that there is a perfect ideal other half for everyone out there.


Our phones have become a tool for us to help us find our match, putting us a swipe away from finding our “Tinderella.”


When we do finally find someone, we start to build our life together and think it’ll be happily ever after. But in reality, happily ever after rarely exists.


Because when you get into a relationship, it’s only the beginning. Typically, there are many trial and tribulations ahead. We’ve also been told statistics like “50% of marriages end in divorce.” Relationships are really, really hard. In studying conflict resolution during Q3, we found the majority of conflict is a result of poor communication resulting in assumptions and outbursts.


Openly is broken down into three sections. Understanding how you show and receive appreciation, what your motivations are, and most importantly practice.


Moving forward, we will be creating wireframes of the entire system, scenarios, and working on our pitch. Stories are what helps people cling and buy into ideas because it helps the idea become real to an audience. This next week, Meg and I will be focusing on creating a strong cohesive narrative for Openly.

This quarter has been a whirlwind, but what’s reassuring is I know we are fully capable of producing something valuable by the end of this quarter. We were reminded today it’s not about being finished but pushing forward as far as we can because no product is ever truly finished. Even the greatest apps and technology are constantly evolving.

*Visuals produced by my talented teammate Meg

Design Strategy | Chase Mobile Banking App

This week we focused on creating a design strategy brief which is created to stand alone. It’s a document to pass off to people in different departments such as marketing to understand what the app will do, why it’s important, and how it will benefit the customer. It should provide people with the vision and excitement to actually build the app.

The struggle this week was understanding how much to add, the order of the story, whats important, and what did I actually want to say. There’s a tendency when completing these assignments to just want to get them done for the sake of the assignment, and it becomes a list to check off. When that happens, I go from “think critically” to “get it done” mode and some decisions are made that don’t make the most since. It’s important to go switch back and forth rather be one extreme or the other.

Since this document is supposed to stand alone, I will keep this post short and let it speak for it’s self.

Cheers! Click here for full PDF


Here’s a quick snippet:

Design Strategy Feature Brief png.003Design Strategy Feature Brief png.002Design Strategy Feature Brief png.009 Design Strategy Feature Brief png.013 Design Strategy Feature Brief png.018

Quantity VS Quality

Sometimes hours of work isn’t quantifiable and is invisible to everyone outside of it. From an outside perspective, it may seem like we didn’t do much this week but Meg and I recognized some holes in our product. We focused our attention in creating a higher quality product rather than just producing more flows or work aimlessly. The more we went through our flows we found a “cliff” hanger at the end. We are in the process of coming up with more specific suggestions or prompts per the different types of conflict one might have.We also worked hard to refine what we have so that it could be in a state to be completed without our guidance. We had to add more instructions and reword many of the questions. We’re also continuing to ideate on ways to move further away from as many fill in the blank questions. Open ended questions are great because they allow for people a chance to articulate their feelings who otherwise wouldn’t. However, it’s not quantifiable and make it harder to build a customized experience. We received quite a bit of feedback from Pat this week to make our product more specific. He suggested we focus on a particular type of relationship and what prevents a person from approaching conflict. In the past, our team has immediately shifted according to the feedback that we received. However, this quarter we are working hard to take feedback and synthesize as a team, thinking through why before we shift directions.

DSC05045 DSC05039 DSC05025DSC05047


We also found organizations who offer and teach conflict resolution classes. My roommate’s mother teaches one of these classes every semester which people pay for. We plan on sending her our work and hope she can give us insight to which areas need more work. We’re curious to learn how it’s comparable to what she currently teaches. We are also hoping to test with some of her students who are actively trying to get better at conflict resolution.

Moving forward we will be conducting more user tests to refine the reflection part of the app. We currently don’t have data to support changes, but we know we will gain insight and clarity after we user test next week. Our efforts will be put towards facilitating user testing and preparing for our final presentation next week. We are working towards crafting the best narrative to articulate The Elephant in the Room to a new audience.

To Make or To Break

This week Meg, Sarah & I took a break from user testing and focused on pushing through to further develop what we had. We focused on ideating ways to make it less “fill in the blank” and more visual or interactive. We are currently flushing out a series of mini games after each step that also resembles something they can do for their mental health. An example would be to help the elephant calm down through breathing out longer than they are breathing in. Studies show that by breathing out longer than you breathe in, your heart rate reduces as well as your anxiety.

We also went back through each step and reworded pieces that people found confusing. An example would be changing “I would like to see” to “What would you like them to do” because “see”didn’t exactly translate to an action to the people we tested.

During the practice piece, we had no instruction to read the screens aloud, and it required us to explain it every time. So we added more instructions but also came up with the idea of having them look at themselves through the video practicing saying it. It has much of the “look at the mirror while your practice” effect because so much of communication isn’t just about what you say but how you say it. It’s important to understand the nonverbal queue’s you’re giving off as well.

At the beginning of this quarter, I was challenged by Jon not to make as much as possible. Hearing him tell me to try and not make alone gave me a bit of anxiety because it was the thing I knew to do best. He challenged me to stay in ambiguity as long as possible so that when I do make, it’s well thought out. Initially, it was frustrating and made me quite antsy. But this week we were told it’s time to make, and it was brought to our attention how much time we were spending critiquing what we made versus making. I’m personally known to be an extremist, and it goes to show how important it is to take steps back to see where the need for attention is. The rule of thumb we were given was to spend 80% of your time making and 20% of the time critiquing or “breaking” the idea. Truthfully it’s about where you are in the process because during design research there’s a whole lot more thinking than making.  We’re taught how to “break” and poke holes at our ideas just as much as we are taught to just go make a thing. By breaking down ideas, it makes them stronger and give it a greater chance of making an impact. However in ideation, it’s a constant tension between making and thinking thru. So this week, we will be focusing on creating more.

DSC05024 DSC05025

Thus far, The Elephant in the Room has been tested by seven individuals and this week we will be testing with two participants over a series of days. This will be the first time The Elephant in the Room will be used without our presence. It will be a real test of how intuitive each step or question is and where the app breaks down. We’re excited yet anxious to see the results and if it enables them to address their elephants in their life.

User testing with The Elephant in the Room has been interesting in that we’re asking people we know to certain degrees to share vulnerable details in conflicts they typically wouldn’t. We have found that the fewer the people the more depth of a conflict they will share. They’ve ranged from spousal traffic arguments to feeling unheard at work. The last time we user tested one to one, the participant chose a to discuss an on going feud between her and her twin sisters. In this case, it was interesting to watch her entire demeanor change when the prompts about how her sisters might be feeling came up.


Moving forward, we were also seeking to speak with mental health clinicians or counselors to get their feedback. Could this be a tool they used? Pat reminded us the value of our product if we can qualify the effectiveness of it. Conflicts are inevitable, complicated, and yet critical to overcome in building healthy relationships. If relationships are what dictates a happier & healthier life, then if we can create a product that enables people to do that we will indeed be making an impact on the wicked problem of mental health.

Product Roadmap | Chase Mobile Banking App

Previously, I went through a product sizing exercise where it is identified how long it will take to bring a product to market. During this process, everything that is unnecessary or isn’t critical to the users experience is removed and reimplemented at a later version if added back into the product at all. During this process, I removed the spending habits portion of the application because it added almost an entire month. Additionally, it is not critical for this banking app to be successful.

The next step is to identify exactly when specific components and parts of the app were going to get built. As a primarily right brained person, creating a roadmap doesn’t exactly have me jumping up and down. However, as I approached creating the roadmap, I understand how critical it is for me as a designer to comprehend this part of the process. A roadmap essentially dictates how much of your design gets built, when, and the quality of the product. It breaks down the stages in which a user gets to experience your design since an app is typically released in parts.

The process I used was to go through each screen and enter into a spreadsheet how long each component or feature would take.

Screen Shot 2016-02-10 at 3.46.11 PM

Then I took small sticky notes (3 colors for 3 versions) and had each sticky note represent a day. During this process, it’s important to keep in mind what needs to get built first before the other parts. Since two developers are working at the same time, it’s best to keep one person on one flow or the other on a separate flow. An example would be for the same person to add in the selection of transfer to account and confirm transfer pages. This will keep the confusion and need for translation of thought processes to a minimum.
DSC05012 DSC05005



After putting it up, I took a step back with Jon and had him take a look. He asked me a series of questions such as why locations was in the first version or why my first version was so much smaller than my second. He suggested the transfer function up to the first version and notifications to be in the second version.  I also put up screens for referencing next to each part represented in sticky notes.



From the wall, I created a simple, readable version in illustrator. If I were working with a team, this is what would be passed along to them so that everyone would be on the same page with expectations and delivery.

Road Map -01

Click here  to see it in a larger view.

Right now, the app is planned to be completed by May 3rd with two developers working 40 hour weeks. Which in my opinion isn’t so bad but as with anything in design and production, it always takes longer than you think. This is a great starting point to at least know what to do next. The design team has to be a couple steps ahead of the developers so they aren’t wasting time and waiting for designs to implement.


Product Sizing | Chase Mobile Banking App

This week, we’ve been learning the process of bringing a design or product to market. For this assignment, I will be using the Chase Mobile Banking app I redesigned last quarter. We were each assigned a developer who we will be working with to go through the steps of going from wireframes to a useable product. The developer I was assigned for this project is Chap, who also happens to be an alumni from AC4D. He has been a great mentor for my entire duration of AC4D, so many thanks, Chap!

First, I compiled all of the most recent screen designs and printed them out in order. I labeled them giving each screen a unique name. We sat down and went through every single screen to estimate and price each screen. I would start the conversation explaining what each feature was and he would ask questions to clarify.

2015.02.01_Product Sizing Evaluation.005

From there he assigned each feature a number of points depending on how long he thought it would take. The numbers ranged from 0-5.

2015.02.01_Product Sizing Evaluation.003 2015.02.01_Product Sizing Evaluation.004

Through this process, I learned what types of elements app developers get for “Free” and which ones take more time. Essentially, the more.
So even if user tests prove your design works better than what is IOS standard, it might not be implemented because of the time it would take to develop. This is when it’s essential for a designer to have a clear idea of what features and controls are essential to the interaction.

2015.02.01_Product Sizing Evaluation.006 2015.02.01_Product Sizing Evaluation.007

There are some screens that aren’t a part of the “hero” or “ideal” flows but are critical to the usability of the app, such as having a negative balance or if there is an error due to connection issues.

2015.02.01_Product Sizing Evaluation.008 2015.02.01_Product Sizing Evaluation.009

2015.02.01_Product Sizing Evaluation.001

After looking over each screen after our meeting, I started to notice there were quite a few redundancies and things seemed like they would take longer than I expected. So I asked Chap to schedule a Skype call to go over those screens to see if we could shave off any time. During the first call, he assigned any screen that was similar to something before a 1. However, during the call we bumped all of those from being a 1 to only a .25. Which shaved off quite a bit of time.

2015.02.01_Product Sizing Evaluation.010

After the points were assigned to each screen, I added up the total for each major task and put it in an excel document. As you can tell below, it was originally projected to be completed Early June if the start date was Feb 1, 2016.

2015.02.01_Product Sizing Evaluation.011 2015.02.01_Product Sizing Evaluation.012

He ended the phone call telling me that he priced mine a little higher than some classmates because it seemed as if my wireframes and designs was at a higher fidelity. He said he knew if he were actually to develop it he would need more time to make it exactly right, whereas if they were less developed, he would have more room to add some design decisions himself. I was surprised because I initially thought for developers the less flushed out, the more time they would estimate. Chap has a design background so it would make sense how having the freedom to make design decisions could boost his coding efficiency. Where as with a traditional software developer might not feel comfortable making those decisions or make very well thought out ones.

After the call almost an entire month was saved.

2015.02.01_Product Sizing Evaluation.013

From there I started asking these questions to decide the order of importance during product development.

2015.02.01_Product Sizing Evaluation.014 2015.02.01_Product Sizing Evaluation.015

I created a high level plan of when each version would be released and what features would be included.

2015.02.01_Product Sizing Evaluation.016 2015.02.01_Product Sizing Evaluation.017 2015.02.01_Product Sizing Evaluation.018 2015.02.01_Product Sizing Evaluation.019

Moving forward I will be creating a detailed timeline of when each feature, control & version will be developed and released.

“The more you learn to love yourself, the less of what other people do for you matters.”

This week Sarah, Meg, and I have been continuing to iterate and dive deeper into ideas, creating detailed hero flows. Hero flows are the ideal scenario of what one would experience when using our product or service.


We have struggled a bit this week because relationships are different for everyone meaning the way they build, work, and break is different too. This makes it extremely hard to ideate because However, we need to keep reminding ourselves; the goal is not for it to work for everyone but a particular population.

Often through this process, we find ourselves talking about our experiences and what we felt during those times. In passing Sarah said,“The more you learn to love yourself, the less of what other people do for you matters.” For some reason, this quote has been circulating through my mind endlessly since. I struggled with learning to love myself my entire life until this year for a number of reasons. Many of which I recognize now as pain and wounds my parents passed on from their life. It wasn’t their fault and in many ways, I am fortunate because I have had the experiences I needed to heal. However, I’ve also realized most people don’t heal from their past they just learn to be numb and cope with it. This results in it negatively impacting many areas of their lives. Hurt people, hurt people, and healed people, heal people. People receive the love they believe they deserve and that how people treat others is a direct reflection of how they treat themselves. Loving ourselves is an essential step in being able to love others freely. So if this is true, people being able to love themselves is also a critical part of them being able to build deeper relationships with others. As a team, we’ve been bouncing back and forth on focusing on the individual or tools to building relationships with others. Relationships are like designs; they aren’t ever really finished until you give up on them. They always have the opportunity to get better or worse through iteration.


Last week, I made coffee-crusted, cherry topped pork loin and a roasted beet salad for the cohort and tested an activity. (The recipe will be posted here in February.) DSC04759

We very much resemble a family in that we know very intimate parts of each other and genuinely care for one another, yet there is plenty of internal baggage and hard moments that are inevitable in relationships. We had a bucket of questions where we randomly drew out of and selected an individual to answer the question.


What we learned from this experience is there have to be boundaries set beforehand. Some I would have set would be that no one is allowed to speak if someone is answering a question. It happened multiple times, and it immediately shut off any vulnerability of the person that was sharing. Regardless of the intent of the comment, in our case humor was traded for vulnerability. We also had unexpected guest in class that affected the mood. Though they were troopers and played along with us, I think people coming in and out caused distraction and also kept the conversation from going as deep as it could have gone.DSC04770
Moving forward, we’ve decided to test out two separate ideas. One focused on self-reflection and building a deeper understanding of themselves and the second a tool to build deeper relationships with others. Both are essential to the mental health of a person yet just left for people to figure out on their own.

The first scenario we are pushing further is either an app or a physical product that allows for self-reflection.

The second is an activity or game that allows for individuals who know each other to build a deeper relationship. The focus on this is to provoke conversations they wouldn’t have otherwise. However, the struggle with this is the emphasis on keeping it lighthearted yet sincere and intentional.

These ideas are by no means any reflection of our final product. They enable us to test ideas with real people to start the iteration process, into something that is impactful and meaningful.

Methods for Evaluation

The last several weeks we have been learning about evaluation methods for a product. Having these methods is an important skill set because it enables us to make judgment calls even when there are no users to test on. The first method I learned was the Cognitive Walkthrough. It is used for evaluating the learnability of a product based on a theory of problem-solving in unfamiliar situations. To do a cognitive walkthrough, I first have to have a prototype, even if it’s just sketches. In this case, I used the Chase mobile banking app I redesigned last quarter. Then I had to identify the user and also assume it’s their first time using the system. From there, the primary goals and each step through the product that supports the user’s main objectives need to be identified. I got a screen shot of each step in the walkthrough.

Next I paired each flow or sequence with the following questions.

  1. Will the user try to achieve the right effect? Will the user understand the intent?
  2. Will the user notice that the correct action is available? Is it visible?
  3. Will the user associate the right action with the effect that user is trying to achieve?
  4. If the correct action is performed, will the user see that progress is being made towards their goal? Is there feedback?

Celine did the cognitive walkthrough on this app as well.

The second method I learned is called Heuristic evaluation. During Heuristic Evaluation is a method used to identify usability problems in user interface designs. It is used by comparing the screens to a list of “best practices” also known as heuristics to determine the usability problems. This method is best done with 3-5 people, so I sought help from my cohort. David, Misty, and Celinè all took parts in helping me identify major issues found within the app.

We paired each screen individually with the following ten questions.

1. Visibility of system status
The system should always keep users informed about what is going on, through appropriate feedback within reasonable time

2. Match between system and the real world
The system should speak the users language, with words, phrases, and concepts familiar to the user, rather than system-oriented terms. Follow real- world conventions, making information appear in a natural and logical order

3. User control and freedom
Users often choose system functions by mistake and will need a clearly marked emergency exit to leave the unwanted state without having to go through an extended dialogue. Support undo and redo

4. Consistency and standards
Users should not have to wonder whether different words, situations, or actions mean the same thing. Follow software/hardware platform conventions.

5. Error prevention
Even better than good error messages is a careful design that prevents a problem from occurring in the first place

6. Recognition rather than recall
Make objects, actions and options visible. The user should not have to remember information from one part of the dialogue to another. Instructions for use of the system should be visible or easily retrievable whenever appropriate.

7. Flexibility and efficiency of use
Accelerators unseen by the novice user may often speed up the interaction for the expert user to such an extent that the system can cater to both inexperienced and experienced users. Allow users to tailor frequent actions.

8. Aesthetic and minimalist design
Dialogues should not contain information that is irrelevant or rarely needed. Every extra unit of information in a dialogue competes with the relevant units of information and diminishes their relative visibility

9. Help users recognize, diagnose and recover from errors Error messages should be expressed in plain language (no codes), precisely indicate the problem, and constructively suggest a solution

10. Help and documentation
Even though it is better if the system can be used without documentation, it may be necessary to provide help and documentation. Any such information should be easy to search, focused on the user’s task, list concrete steps to be carried out, and not be too large

All critiques from both methods were recorded in a shared Google document. I took all of the feed back, including my own, using the methods and found that there are three major themes of issues within the UI (user interface) of the mobile app.

The most common comment across the board was to check the size of the touch points and to consider making them larger because there is the space to. After doing research, I found according to IOS standards, 44px by 44px is the minimum size. So when I compared that to the touch points on my screens, they passed the minimum size test. After going through the benefits or potential drawbacks, I decided to focus on the minor adjustments that would take a longer time wasn’t worth it immediately.

Heuristic & Cog Walk through 2015.01.18.001

These things included making the title bar 44pt instead of 82 px or adding a status bar. I also think adjusting the current title bar to be smaller would make it harder to read or understand.

Heuristic & Cog Walk through 2015.01.18.002

However, there were other elements that had a much larger impact and lower time commitment such as the correct standard keyboard for entering amounts and alert consistency to match IOS standards.

Heuristic & Cog Walk through 2015.01.18.003Heuristic & Cog Walk through 2015.01.18.004The second common theme was there is a lack of user control or freedom. The nature of the UI design currently is to enter the user in a step by step process to prevent confusion or information overload. However, a downfall of that approach is it takes away a user’s freedom and control. So for the next phase, I will be taking more time to draw out and talk out with my cohort what controls enhance a user’s ability to learn or use the product. In many ways, I feel as if there is a bell curve where too much user freedom could drastically decrease the learnability and usability of a product.

Heuristic & Cog Walk through 2015.01.18.007

The final category is help, documentation, and error prevention. There are simple fixes that I believe could greatly enhance the learnability of the app. These include adding a blinking cursor, or an indication on where to click to take a photo for checks.
Heuristic & Cog Walk through 2015.01.18.012Heuristic & Cog Walk through 2015.01.18.009 Heuristic & Cog Walk through 2015.01.18.010

Other examples of simple fixes that need to be made are to change the spending alert screen. It currently looks like with the slider adjustments can be made to their budget when the intent is to alert them their of spending in a category for that month.

Heuristic & Cog Walk through 2015.01.18.011
During the redesign of the app, I also decided to take out the entire “help” section because it seemed unnecessary. However, coming in from a first time user perspective, help screens would be extremely helpful, especially the first time around. After the user does the tasks several times, the help screens will no longer be needed. So I will explore building out “tips” or a “first-time walk through” and what those elements might look like integrated. This is a much longer time investment but could increase the learnability of the product drastically.

Heuristic & Cog Walk through 2015.01.18.013

Moving forward I will be fixing the most important aspects of each category and working down the list as time permits. More and more, what I’m learning about is there is no such thing as a perfect app or product. I’m confident that if I put the most beautifully designed apps up against the heuristic or cognitive walkthrough, I would find an array of issues. I’m also certain, the designers working for those companies have a long list of changes they are planning on making. So with that, the most important lessons I can learn is not how to make something perfect but how to discern what is most important now. There will always be a thousand things I “should” work on but understanding what’s essential to the product and customer right now is invaluable. I think as a designer who is used to being on the production side, I find myself getting lost in the details. Some that matter and others that don’t. So for the rest of the quarter, I will be focusing on thinking through what’s most essential first in both this class but also all areas of my life.

I read this book over winter break, and it gave me an excellent perspective on what it means to be an essentialist as well.