Oh-hi: Helping military spouses meet new friends

For seven months, David Bill, Miranda Hoffman, and I have been exploring the world of the military family. Our goal was to learn about their challenges and explore opportunities to address those challenges through the creation of a product or service. One particular issue stuck out to us.

The Problem

One-third of the military moves every year

Every year, a third of the military moves. They call it PCS (Permanent Change of Station). With each move, families are leaving behind the network of people they deeply rely on. This is especially problematic for spouses, as they are often left to take care of things on their own while their partner is away.

To illustrate the importance of this network, let’s look at the story of Rosie, an Army wife. She told us about the last time her husband was deployed. While he was gone, she got incredibly sick and doctors discovered that she had a mass at the top of her brainstem. She had to travel back and forth from Fort Hood to San Antonio to meet with neurosurgeons and for treatment, and she couldn’t take her two-year-old in with her during the MRI. She had to rely on her friends to step up—to travel with her, emotionally support her, and care her son. Because her husband couldn’t be there, these friends really became her family.

“You rely so strongly on those friends—they really become your family. To be able to build those relationships is really important.”

– Rosie

Unfortunately, military spouses are up against a myriad of challenges when finding friends. FRGs, or Family Readiness Groups, are officially sponsored and branch specific spousal organizations. They are meant to be places for spouses to come together and to socialize and support each other. However, these groups are often disorganized and unresponsive, providing little value and gaining a reputation to be avoided. Also, spouses who do try to get involved often encounter judgment and alienation due at least in part to the military’s rank structure creeping into social dynamics.

Spouses have responded by heading online, Facebook in particular, to find friends. However, as effective as Facebook can be for sharing and communicating online, interactions on Facebook rarely lead to spending time together offline where friendships are built. When reaching out, the response is too often, “You can ‘friend’ me!”, but plans are never made to come together in-person.

FacebookPost

The Solution

To address this issue, we’ve created Oh-hi, a tool for military spouses to make new friends. Here’s a rundown of the important features that we have incorporated into the vision for Oh-hi.

We heard time and again how hard it is not only to find someone, but to find someone you click with. Oh-hi gives users access to other military spouses across the entire duty station regardless of unit or rank. They aren’t limited to those in a particular FRG.

To provide information about themselves, spouses are able to share details that are important to them. Additionally, beyond the basic profile information, Oh-hi allows spouses to have their friends provide references for them. Every step of the way, Oh-hi must be a place that military spouses trust and where they can build trust with each other. Friend references are an essential component to that building of trust.

Another key aspect of building trust is allowing users to ease into relationships with each other. By suggesting low-pressure activities, like going for a walk or getting a cup of coffee, users can feel comfortable reaching out and meeting up. To lower the barrier even further, Oh-hi takes the awkward back-and-forth out of deciding when and where to meet up by offering suggestions based upon mutual availability.

Most importantly, every decision that’s gone into making Oh-hi has been made to encourage military spouses to meet in-person. We believe spending time together in-person is the foundation of building friendship. By making it easy to identify, invite, and meet up with spouses who are also interested in making new friends, we believe that Oh-hi has the potential to help military spouses thrive.

For military spouses, we promise to increase their ability to thrive in the military community by reducing social isolation and building connection.

Testing Impact of the Design

We started out with evidence that military spouses were willing to use digital tools to reach out to potential new friends. What we needed to learn was specifically what it would take to ensure would be willing to actually meet in-person. To test our ideas for enabling this behavior, we started with a minimal feature set and implemented a website that allowed users to invite each other to meet up. We ran a pilot at Fort Hood (one of the largest Army bases in the country) for four weeks. Through a combination of marketing efforts—email, a Twitter campaign, and two trips to Fort Hood—we were able to recruit 21 users. The response we received was overwhelmingly positive. People were excited about the idea.

“Oh my gosh, this is something I’ve been looking for! It’s so badly needed!”

– Violet

While it was extremely validating to hear the excitement, the version of our system that was implemented for the pilot was unsuccessful in spurring users to take action.

No invitations were sent, so no one met in-person. We followed this up with user testing to help identify issues that might have presented users from reaching out. Based upon the user testing, we made changes to the system, creating a more robust set of features that gave users more control over their interactions with each other. The results yielded some clear insights that we can apply to future tests.

Insights

Trust is the most important element for us to keep in mind with this system. Beyond trust in the system itself, spouses must be able to trust each other, and they can only build that trust if they are able to interact with each other in the same ways they are comfortable with in real life. Here are the areas we feel we should focus on moving forward.

Access

Because the military community is closed and very protective, it was difficult for spouses to trust us as civilian outsiders. For example, we were kicked out of a Fort Hood Spouses Facebook group because they thought we were trying to sell them something even though the group’s administrators were aware of our project and purpose. To successfully engage with the military spouse community, we found it to be extremely valuable to have someone who is a part of that community speak on our behalf. We have already begun to build relationships with individuals at Fort Hood who believe in the value of Oh-hi.

Awareness

A tool like Oh-hi often requires potential users to hear about it several times before they are willing to use it. We have identified a variety of ways to drive awareness. In addition to the voice of advocates, spouses have responded positively to the idea of hosting events to offer users another way to interact with each other. Because military spouses are very active on social media, continuing to build out valuable messaging via those channels could be another effective strategy. Finally, once we are able to generate activity, we would like to gather case studies that speak to Oh-hi’s potential to help build friendships.

Design

During user-testing, we found that users were looking for key phrases or visual cues to help them identify those they were interested in meeting up with. We will be working on ways to encourage users to share the right level and types of information that would help them identify each other successfully. Secondly, we found that users had particular expectations around how both messaging and invitations would be displayed. If we are able to match these expectations, users would feel more comfortable with, and in control of, their interactions with each other. Finally, users identified friend references as one of the deciding factors in being able to identify someone they wanted to reach out to. We will need to find a way to successfully encourage users to get their friends to provide them with references.

Moving Forward

While the potential for scale is there—there are around 1.1 military spouses whose partner is currently serving—it is not our immediate goal. Our goal now is to demonstrate that Oh-hi is able to build the connections vital to their ability to thrive. If you have any further insights to share or know of others who may be interested in helping us, we would love to hear from you. You can contact us at hi@oh-hi.us.

Oh-hi: Pitching and Piloting

Our team has been working on the development of a tool for military spouses to find each other in their respective communities with the express intent of making new friends. We’re currently in the middle of trying to get a pilot up and running and spent the last week iterating on several things…

  • How we are pitching the idea.
  • The operational details of the pilot.
  • Our approach to acquiring participants for the pilot.

Our pitch has come a long way from the beginning of the quarter, but we are still needing to do a lot of research around the business model. Pricing has to reflect a fair exchange of value and allow the venture to support itself. More specifics to report on that next week.

As for the pilot, the work we’ve done so far and the feedback we’ve received have led us to the creation of a website where military spouses can see other military spouses in their area and invite them to meet in-person. The invitations are for low-pressure activities like going for a walk and getting a cup of coffee.

Here are two pieces of specific feedback that we’ve received after presenting our initial pilot plan:

  • Restricting users to only seeing a few people at a time that they are “matched” with has been unsuccessful for others trying to build dating apps (which is a close analog to our service).
  • On the other hand, allowing users to see everyone in the area will inevitably create situations where there are not enough people signed up in a particular area. It could feel quite lonely and not very valuable.

This puts us between a rock and a hard place, and we’ve yet to gather any clear evidence to go one way or the other. So we picked a direction. Through a combination of anecdotal preference and comparison with other businesses in the same general space, we’ve opted to go with an open community. At least for now, during the pilot, when we can hopefully explain to our few users why the groups are so empty, that’s the direction we are going in. This does not preclude us from offering suggestions for our users, but it won’t be the only way that users will be able to encounter each other.

As of today, we have a service that still relies quite heavily and unsustainably on us to manually move data around and communicate with users. We’re hopeful though that it’s sufficient to be able to learn from a small pool of initial users whether or not there is potential to turn the idea into a sustainable venture. The website is at www.oh-hi.us. If you happen to know any military spouses in the North Austin or Fort Hood areas, let them know! We’d love to see if we can find them a new friend.

U.S. Bank Mobile Banking App: Design Strategy Feature Brief

We’ve been working for months on the redesign of mobile banking apps. We’ve gone from the creation of concept maps (high-level articulations of the app’s structure) all the way to a design strategy feature brief (a detailed articulation of the vision for the project).

The design strategy feature brief is a satisfying document to create because it’s the first thing that we’ve created for this project that is refined and detailed enough to be able to stand on its own. It’s meant to encourage others to get excited and support the project. It can be emailed to stakeholders without me having to be there to explain why the project is valuable.

Here’s a copy of my DSFB for the redesign of the U.S. Bank mobile banking app:
Design Strategy Feature Brief (pdf)

For a full rundown of my project, here are links to previous posts (most recent first):

 

Testing Friendship

This week, our project team got some traction around testing our idea. We’re working toward the development of a service to help military spouses make new friends in person. We have a pile of assumptions and questions around the idea that we’re working to better understand. To do that, we’re finding people that we feel might get along and sending them out to meet up in person. Here’s how it’s going and what we’ve learned so far.

On Monday, we decided to pursue a proxy group of participants that we had better in-person access to: University of Texas college students. College students, like military spouses, are all connected through a common organization. Also, lots of them have moved to a new place relatively recently. Understanding that there are very significant differences between these populations though, we decided that it would still be valuable to test the basic mechanics of actually matching people up and having them spend time together in person. So, we got some bait (cookies) and set up a table on campus.

2016-02-08 16.00.09-1

We went through a prepared discussion guide with each participant, asking them about their experiences and thoughts around friendship. It was immediately striking just how varied everyone’s responses were, seeming to add to the difficulty of our task. However, within a couple of hours, we had enough participants to be able to create at least a couple of matches we thought might work out.

In addition to recruiting participants on campus with whom we had no prior affiliation, we also wanted to test another rather tried and true form of matchmaking: through a mutual friend. To do that, Miranda contacted a couple of her friends who she thought would get along, one of whom had expressed desire to make more friends.

We ended up matching six participants (3 pairs). To facilitate their meeting up in person, we selected low-pressure activities (coffee for two pairs and ping pong at a local hangout for the other). We sent each participant individual emails with a pre-selected time and place to meet up, limiting their required action to a simple reply “Yes”. Two of the three pairs have agreed to meet up and we’ll be doing follow-up interviews to see how it went. For those who didn’t RSVP, we’ll be asking why they decided to opt out.

In addition to our recruitment with a proxy population, we’ve begun to make contacts in the military as well. We hope to have a relatively good sized group of people to run a pilot with next quarter.

Next time, we should be able to share what we’ve learned so far through our very first matches.

US Bank Mobile Banking App Redesign: Product Roadmap

We are getting closer to the development phase for our mobile banking app project. My last post involved creating estimates for feature development across the entire system. Now, we’re working on turning those estimates into a product roadmap that will help guide the development process.

A product roadmap lays out groups of features that should be implemented at one time in order to maintain a coherent system that could be released. Each group of features, known as a “thin-slice”, is distributed across the developers available to work on the project. You end up with an estimate of what value you’ll be able to deliver when. Of course, practically speaking, roadmaps are highly inaccurate documents and must evolve as you learn more and hit bumps along the way. Let’s take a look at what mine looks like now.

ThinSlices

(click image for larger PDF version)

The first slice is a very simple version of the app, containing only a view of the user’s accounts, their respective balances, and the transaction history under each account. Here’s what that would look like, almost entirely.

Screen Shot 2016-02-10 at 6.06.37 PM

There can be lots of benefits to releasing the app with limited functionality. It can boost team morale to see their work being used, and you can learn when the stakes are lower about pitfalls you might encounter during the release process. However, in this case, there are a couple of strong reasons why a release with limited functionality could be detrimental:

  • The industry has an established baseline of features that are available in just about every mobile banking app. For example, being able to set up bill payments that come out of your account automatically at scheduled intervals is no longer optional—it’s required.
  • Some features, if not implemented, would require the business to take on significant investment in human resources to make up for a lack of automation. For example, you can see that OCR is not being implemented until Slice 3. The app could be released without it, but that would require manual processing of every single check deposited through the app.

Because of these reasons, I was motivated to find a way to get all of the baseline features implemented and to do so in ways that would reduce investment required in other parts of the business.

Let’s take another look at Slice 3:

Slice3

The pieces in this slice are as follows:

  • The ability to log in using Touch ID (1 day)
  • The ability to create recurring transactions (8 days)
  • Automated check processing with a 3rd party provider of an OCR API (10 days)
  • Advanced notifications (3 days)

The bulk of this work is in creating the logic for editing recurring transactions and integration with a 3rd party OCR service. Much of this work can be done in parallel by a second developer. Because there are obviously some dependencies between the work being done by each developer, I have tried to organize the work so that there is opportunity for appropriate collaboration and handoff. The second developer is also provided some time prior to the scheduled release date to account for the inevitable hiccups in syncing all that work up. Here’s what the final roadmap looks like.

ProposedTimeline

(click image for larger PDF version in context with thin-slices)

The entire project is scheduled to be developed in 34 days. That sounds hopelessly optimistic. Because road-mapping is such an inexact science, we will have to keep an eye on progress as development is under way. The schedule almost certainly will need to shift one way or the other. Let’s hope our developers don’t decide to take a vacation!

For a look at a full breakdown of features, thin-slices, and the proposed roadmap, here’s a PDF: USBank_Wireframes_Kade_r6_ThinSlices.pdf

US Bank Mobile Banking App Redesign: Development Resource Planning

We have been redesigning mobile banking apps, and so far, it’s been all about the user:

  • What are the user’s goals?
  • Can users accomplish their goals?
  • How can we make the design even better?

Now, it’s time to look at what we’ve got and figure out how to get it into the app store. That means code. That means working with developers. That means pragmatic planning.

To begin, we scheduled a meeting with a developer to review the app’s functionality in its entirety, identifying the app’s features, components, and controls over the course of the meeting. To ensure we were on the same page, this meant literally pointing to wireframes and labeling the components.

2016-02-01 13.19.10

Along the way, the developer was able to react to the elements onscreen with respect to their perceived complexity (based on his knowledge and experience with the development of other mobile apps). There were a few suggestions made to use alternate controls which could reduce some of the development effort required. However, most of these were relatively minor gains in reduced dev time when compared to the impact on consistency and clarity for the user. For example, instead of customizing a table view with additional logic to mimic the functionality of radio buttons (as in screen 4.3 in the image above), the developer suggested simply using radio buttons. However, he also acknowledged the sacrifice in visual consistency that would entail.

After getting through the entire app, we then listed out features and applied estimates for the number of days it would take the developer to complete each one. Here are the final results of the developer’s estimates:

Screen Shot 2016-02-01 at 3.48.39 PM

For a more detailed breakdown of features, components, and controls throughout the app, here is the full PDF:
USBank_Wireframes_Kade_FeaturesComponentsControls_r6.pdf

You can see that the development of the user interface elements does take up the largest portion of the estimated time, especially when accounting for styling near the end. However, there is a back-end portion of the logic that turned out to be surprisingly tricky to build: recurring transaction frequency estimated at 8 days. That turns out to be 18.6% of the development cost.

Because the design calls for the ability of the user to enter in any custom frequency for a recurring transaction, there are numerous edge cases that must be accounted for. For example, say the user wants a transaction to recur every fourth month on the 31st. First, “every fourth month” is not a common frequency and so would have to be entered using a “Custom” option, as in the following image:

Screen Shot 2016-02-01 at 3.58.20 PM

Additionally, there are many months which do not have 31 days. Also, the 31st day of the month may not fall on a weekday… and so on. Just ensuring that the user is confident that they are able to achieve the desired result is difficult enough. Building in all the edge cases in the logic may be even harder.

As is not commonly the case, the estimates came in well below expectations, even accounting for the difficulty of handling the recurring transaction logic. There will be no changes to the scope of the project. However, we will next be looking at creating a roadmap to determine which portions of the app can be released sooner than others. This will result in a phased development approach that I’ll be outlining in my next post for the project.

Military Spouses Project Team Update

The process. Trust the process.

Our project team has been working for months now to understand the lives of military families, spouses in particular. We are starting to gain some confidence around the path along which all of our research has led us. It feels like the process is paying off.

Our guiding light, the insight that has been driving our ideation this quarter, is that transient military families struggle to build deep relationships vital to security and reliability. After several weeks of asking ourselves how we might solve various problems in different ways, writing scenarios, sketching vignettes and diagrams, all of our ideation has started to gel around a relatively concrete solution: a friend-dating app for military spouses.

Once coming to this potential solution, we needed to get some feedback. Yesterday, we did a follow-up interview with a past participant. It was only one opinion (much more testing to come), but it was extremely satisfying when her reactions to the wireframes validated several of our assumptions. For example, we knew that military spouses were consciously aware of the need to make new friends quickly, but we were making a leap in thinking that they would be comfortable with the system making a lot of the scheduling decisions around meeting up. Our participant not only said that it would be nice because it removes a lot of the awkward back and forth of “Where would you like to go? Oh, I don’t care. Well, how about this place?” and so on. She also said that it fits right in with the directness and efficiency of military culture.

In addition to validating some of our assumptions, our participant was able to give us some direction on some issues we were struggling to figure out how to handle. For example, one of our goals is to avoid the judgment and alienation which can be so pervasive among the social circles of military spouses. We knew that the military’s rank structure had a big impact on this. After our interview, we were able to turn a big question into an assumption, and an assumption can be tested.

So, to sum up where we’re at, there is a problem we’ve identified, one among many overlapping problems. And then there’s this web of reasons why this problem exists. And what we’ve done so far has been enough so that we can say, yes, this is an appropriate course of action (at least, to continue testing this idea rather than to abandon it). Now, we’re asking ourselves how we can test the really important hypothesis, that a friend-dating app can actually have the impact of leading to more relationships among military spouses that give them a sense of security and reliability.

Mobile Banking App: Opportunities for Improvement

Throughout quarter 2, we redesigned various mobile banking apps. We are continuing to build upon the redesigned systems this quarter through additional evaluation methods. To set some context, the following is the process we’ve used to arrive at where we are today.

Process and Methods

We went through the identification of user goals and the creation of narrative scenarios around those goals. We also created concept maps that allowed us to articulate the system’s components in a way that the relationships between them and the system’s overall “shape” could be understood at once. This shape is the mental model that users begin to build through experience with the app. By zooming out to this diagrammatic level of abstraction, we are able to create alternative ways to organize the system that are more coherent and more directly support user goals. Once we were confident with the system’s organization (aka the system’s “architecture”), we were able to begin creating potential representations of the screens, or wireframes, that the app might contain. These were organized into flows through the system that mapped to user goals, like “depositing a check”. Each flow was subjected to evaluation by two methods:

  • Think-aloud testing: observing users while they describe aloud what they are doing and what they are thinking along the way. This method uncovers difficulties users have with comprehending the system and can offer insight into their pre-existing mental models around the domain in question.
  • Formal critique: soliciting feedback from colleagues on the quality of the design based on their opinions.

This brings us to where we are this quarter. We have added two additional evaluation methods to our arsenal to cover different aspects of the design:

  • Cognitive walkthrough: based on theories of cognitive problem-solving in unfamiliar situations, evaluators go through a series of task-based flows (such as “depositing a check”) and ask themselves a few questions at each step. The questions put evaluators in the mindset of a new user to evaluate the learnability of a system.
  • Heuristic analysis: evaluators determine whether each element onscreen, throughout the entire system, follows or breaks a set of well-established guidelines for designing a user interface. Because this method covers every element on every screen, it is much more comprehensive than the other methods which are task-oriented. Each heuristic amounts to a rule that should generally not be broken. We have performed these two methods on our wireframes, and what follows are the results from mine.

Results

Each problem identified can be classified as either an issue that is required to be fixed or one that can be lived with, at least in the short-term. I will be focusing primarily on sharing those issues which would be required to be fixed before releasing the product. However, I’ll also be sharing a significant enhancement that will likely contribute greatly to user satisfaction. Primarily because this project is at the pre-development stage (no code yet), it will be relatively easy to address most of the problems, at least in the wireframes. To see full lists of the problems, refer to the following files:

PDF files for reference:

Problem #1: Users have no way to recover from a forgotten username/password. (Heuristic Analysis—problem ID 5)

For the case that a user has forgotten either the username or password, the design offered no clear path to recovery. This is an absolute must-have prior to release. The following image shows the proposed solution to this problem as well as two others (lack of a Log In button and the clear separation of the Touch ID link).

Issue-01

Problem #2: The available options for setting up recurring payments does not allow for full customizability—e.g. every 3 weeks is not supported. (Cognitive Walkthrough—problem ID 29)

In the following proposal, the Custom option is provided for those users who have the need to enter a recurring payment using less common frequency parameters. After selecting Custom, users would have to enter whether they would like the payment to recur daily, weekly, monthly, or yearly and then how often. For example, the user could now enter “weekly, every 3 weeks”.

Issue-02

Problem #3: The system does not indicate that the back of the check must be signed before the photo is taken. (Heuristic Analysis—problem ID 57)

With people using written checks less and less, it’s likely that some users will not understand that a check must be endorsed with a signature prior to depositing it. Those users would receive a failure-to-deposit message, perhaps days later, with no prior indication that this was a requirement.

Issue-03

Problem #4: If users change their mind about an entry made on an earlier step only after completing other steps (of a payment/transfer/deposit), it is cumbersome to back up through those steps in order to make the one change. Additionally, the user feels as though they must confirm each subsequent step moving forward again. (Cognitive Walkthrough—problem ID 11)

The proposed solution to this problem also addresses another significant problem (Cognitive Walkthrough—problem ID 3) where the user is disoriented because they are dropped into the middle of a flow without having a window into all of the information required to complete the task successfully. The proposed solution is to include a summary screen where the user can see each piece of information required to complete the task, can enter that information in any order, and is always confident that the selections that were made are being saved appropriately. Among all of the enhancements proposed during the latest round of usability evaluation, this is the one that is likely to have the greatest positive impact. The following example shows how this would play out for the Pay a Person task. The same pattern would be applied throughout the app for other Pay flows as well as Transfer and Deposit.

Issue-04

Next Steps

In practice, designers must make subjective decisions to balance the consequences of breaking the “rules” against the details of the particular context and user goals. We’ll be presenting our findings this evening and then going on to make those subjective decisions which will also include thinking about feasibility.

Rapid Iteration & Creative Problem Solving: The Final Iteration

While a design can never really be “done”, there may be an end state, a point at which you stop working on it. And because this was a pretty well-contained school project, this may be the final time this gets touched. Which is a shame because I made some pretty significant changes based on both user testing and feedback I received during formal critique.

After the very first round of wireframes, I had a hunch that organizing the app around a bunch of wizard-style flows may be problematic. It was even mentioned by others during critique that first time out of the gate. However, user testing went relatively smoothly through multiple iterations, and I chose to ignore the issue. That issue is as follows…

USBank_ProposedFixes_r7_1

Here’s an example of what that looked like in the wireframes is tested with:

USBank_ProposedFixes_r7_2

To address the issue, I’ve come up with a proposal:

USBank_ProposedFixes_r7_3

And here’s how the same example above would play out under this new model:

USBank_ProposedFixes_r7_4

The next step would be test the new model with users. However, the quarter is over, and I’m happy with where I ended up. Ship it!

Reflection: On the Value of Making Lots of Things

What I’ve learned this week is another thing that I already knew but now understand much deeper. Last week, I talked about the importance of iteration, of doing work early in order to have the time to do it again, better. Now, I more deeply understand the value not only of making a thing, but of making lots of them.

Something I’ve heard quite a bit from faculty is that 9 out of 10 of the things they make don’t get used. I don’t think I understood the value of that until now. Much of design is not about knowing what will work and making that. Rather, it’s about not knowing what will work and trying lots of things (with informed direction, of course).

Over the course of the last couple of months doing research with my group, we’ve had lots of ideas for things we could do. However, most of them never happened. They never became real, not even in the quick sketch sort of way. So, if that’s the case, I think we missed out on the opportunity to capture lots of things that would have worked.

Luckily, I’m recognizing this now with still a week before the final presentation. Looking forward to feedback on our first run today.