Reframing Failure: Our Journey Continues

How many women connect with the idea of celebrating failure? What does the full customer journey look like for an ATX Fail Club member? These are the questions we tackled this week.

Since our last update…

  • We crafted social media posts to test our messaging and gauge the number of women open to celebrating failure. We shared posts from Spanx CEO Sara Blakely about the way she has reframed failure to be a positive. Our Instagram post was the most successful receiving 17 “likes” in one day. These posts drove 6 new users to our website where 1 person signed up.
  • We also met and fleshed out what the ideal customer journey might look like. Starting when a woman first discovers the club and ending when she is fully engaged and helping to grow and spread the venture.

Failure_Jounrney Map

  • Another accomplishment was getting our event registration and purchase options ironed out on the website. We previously had it set up through an app in the site for people to register, but the payment options were not ideal. This week we created an event on Eventbrite and integrated this into our website for the April failure dinner.
  • Lastly, we created first drafts of the mission, vision, and goals of our business. We think these will be useful on our website to better explain what the club is about, and help us moving forward align our decisions more closely to the goals and outcomes we hope to achieve with ATX Fail Club.

Lessons Learned:

  • Time flies when you’re juggling multiple responsibilities. This week other obligations and things coming up caused us to reevaluate our initial plans. Next week, we hope to front-load more to schedule and get all the necessary supporting materials lined up early on to make this less likely to repeat itself.
  • We shared a video on facebook and twitter, and an image on Instagram with the image receiving more interaction. Either, image posts are more impactful than videos in gaining traction, or Instagram is a better way to engage with our audience on social media. Facebook still appears to be the best way to drive users to our website with 4/6 new users coming from Facebook and 2 from Instagram.

Our Next Big Question:

Test reactions to our newly drafted mission and goals. Are these relevant for our target audience?

Now we’ve got to…

  • Outline a clear testing plan for this week so that we can divide and conquer.
  • Define what our goals and metrics are for testing and how we will know if we are successful.
  • Begin soliciting sponsors for our April event.

One way you can help right now is…

  • Contact us if you have a lead on a sponsor we should reach out to. Ideally, food/drink/space/swag-related for a group of 8-15 women in April. Our emails are Jen.Figueroa@ac4d.com, Laura.Sepulveda@ac4d.com, and Vicky.Pridgen@ac4d.com.
  • Sign up for a 20-minute video-call feedback session to offer input on our concept. You will answer a series of questions and conduct a short activity and there will be time at the end of the session for additional feedback. Click here to sign up.

Progress Update: Optimizing Effective Advising

We are building a tool to assist advisors of non-traditional college students broach the topics of self-advocacy and social and emotional learning. Our tool is a questionnaire that optimizes the short time advisors have with their students, making sure that the sensitive root causes of problems are the center of the conversation. 

This week our team focused on our end-to-end solution in order that we can hone in on the most appropriate MVP to launch next month:

  • We began a first iteration of a service blueprint. The visual artifact has already begun to help us define the nuts and bolts of our product; how it works; how it is adopted; how it works as a business model. Further iterations will continue to nail down how the product will offer the most impact to stakeholders in the college persistence industry.
  • We began mockups of what our questionnaire will look like from the student’s side as well as the dashboard the advisors will pull up on their computers, displaying a profile of student’s responses and predictive analysis of flagged topics to discuss in the meeting.
  • We began work on a customer journey map so that we can reconnect with the empathy we developed during our design research process to ensure that the product lands with the most meaningfulness as possible.

As described, these artifacts are not only helping demonstrate to the outside world what we are building, they are constantly helping us determine the minutia that helps the product take shape in our hands.

This coming week we will:

  • Pitch our end-to-end solution and spend time creating a narrative around the delivery.
  • Further iterate on the fidelity of artifacts to support our pitch.
  • Continue organizing ourselves around the agile Kanban sprint methodology to get the most out of each week.

How you can help:

We are arranging time slots to further research what is currently being used in the advising market as software for student databases and tracking academic success through the college lifecycle. If you are familiar with, or could connect us with, college advisors and/or college persistence organizations we would love to hear about the tools and software you currently use. Please contact us at cristina.suazo@ac4d.com or apruem@gmail.com.

Designing for Successful Mentorship

We are building a platform for first-generation Americans to access resources that support success. Our product matches mentees to mentors and provides a framework to facilitate successful, productive relationships.

This week our team focused on defining our end-to-end customer journey:

  • We created journey maps to document how mentors and mentees engage with our digital platform and how the platform integrates into their physical meetings.
  • We created a service blueprint to define the interactions organizations, mentors, and mentees have with our product from the time they learn about our mentoring program through to the ideal future state. This included defining our visible actions, behind-the-scenes actions and necessary support at each touchpoint.
  • We created a list of artifacts to create to support our mentoring platform

Additionally, we spoke with more people who match mentees with mentors about their methods. We have made strides in defining our unique approach to creating successful matches.

In the upcoming week we will:

  • Create a midterm presentation deck
  • Create artifacts to support the mentee-mentor relationship
  • Create a high fidelity mock-ups of digital interactions

One way you can help right now is…
If you know anyone looking to begin a mentoring program we would love to speak with them about or upcoming pilot launch!

Please reach out to one of us:

Christina Davis, Susi Brister, and Catherine Woodiwiss

 

 

Defining Our Vision

We exist to create a world where working students have the option to prioritize school over work because working full-time demands time and focus at the expense of academic success.

This is the vision for our Capstone group (Kay, Kim, and myself) and we aim to realize our vision through FundEDU. As a reminder, FundEDU is a crowdfunding platform that helps students leverage their support network to lessen the financial burden of school, allowing them to work fewer hours while undertaking their academic journey.

Over the last week, our team spoke at length about what value we are trying to provide and how we can achieve it. We iterated on our service blueprint — a design artifact similar to a timeline coupling a customer’s journey and the actions our business must take to support that journey — to create a visual representation of a user’s flow through FundEDU. Next week we will be increasing its fidelity to include in our pitch deck.

Screen Shot 2019-03-22 at 8.13.06 PM

One of the greatest values that sites like IndieGoGo, Kickstarter, and GoFundMe provide is the ability to give funding campaigns visibility beyond a person’s immediate network. For example, GoFundMe has a ‘trending’ section for each category a donee can choose for their campaign (pictured below) which gives those seeking financial help a better chance of meeting their goal by advertising the campaign to a wider audience. This is something that we’d to emulate with FundEDU. 

Screen Shot 2019-03-22 at 11.38.21 AM

Our next step is to continue refining a minimally viable product we can test with real people. The main challenge we face is deciding which parts of the product should be included in the pilot and deciding how we will define success. Once a consensus is reached, we will move forward with implementation. We look forward to gauging how the market responds to FundEDU.

Launchpad Progress Update

Our business venture aims to empower ex-teachers to pursue paths outside of their current career by helping them identify transferable skills and then connect with a larger community of ex-teachers and employers. We will do this is in a summer workshop series combined with year-round events, and a website for additional support and resources.  

This week we have been working on…

  • Defining the thing: We named the pain points along the journey of making a transition out of teaching from what we heard in interviews, ideated on the forms a solution to those pain points could take, chose a suite of workshops, events, and website as our final solution. We also defined the end state by defining five possible careers to help transition people into.
  • Visualizing the thing: We’ve created a customer journey map to illustrate the stages of the user’s journey and the interaction with our service.
  • Thinking through the details: We also created a detailed service blueprint which allowed us to think through the multiple layers of our service and what tasks need to be accomplished to be able to deliver our value promise.

 

Recently, we have been working on creating physical artifacts that articulate our design concept, whereas prior we were working to validate and solidify our concept. Our team has been focused on creating an end to end solution with the intention of validating the concept with an MVP before the end of April.

 

Our next question: How do we validate the value of this solution for employers? How can we utilize what we find is most valuable to employers to give our graduates a leg up?

 

Now we will work to …

  • Create additional artifacts that help to articulate our larger vision until it becomes a reality
  • Create our first draft of our mid-point/final presentation of our progress
  • Place our concept in front of employers to get feedback

To do this, over the next week, we will be…

  • Connecting with employers to gain feedback on our concept before piloting in the first weeks of April
  • Coordinating and hold interviews
  • Working to balance and define the relationship of our product to employers and vice versa

Our priority is creating physical artifacts that are coherent enough to convey our grand idea.

 

One way you can help right now is…

If you or anyone you know hires for in-house recruiters and would be open to talking to us about their process, please reach out to us at sara.miller@ac4d.com or kelsey.greathouse@ac4d.com.

Ought or Ought Not

A lot has happened since our quarter 1 course in design theory. To be specific, we completed a service design project ending with design criteria as a final deliverable to our clients; we redesigned the system of Nespresso Vertuoline single-serve coffee machine; we developed our own social entrepreneurial businesses; and finally, we are prototyping and developing a framework of methodologies in product management of our banking app wireframes; last bust not least, our capstone groups are creating our end-to-end-solutions and piloting MVPs of in the the problem space of college persistence among non-traditional students.

All this to say, time has flown, we’ve been holding our breaths, and now we have a second to reflect on our regenerated thoughts about the purpose of design and the way we talk about it.

It’s no mistake that the first section of the course focuses on “with best intentions.” We covered some similar conversations as in our previous theory course, diving into critical rhetoric about appropriateness and the user’s real interests and needs.

I had 3 particular takeaways that spans across synthesis and the point of views of all of the authors we’ve read (however I will only quote some here).

Information is convenient when it is pleasant but untrue, but it is discomforting information is true but unpleasant.

“When you give the average person an infinite reservoir of human wisdom, they will not Google for the higher truth that contradicts their own convictions. They will not Google for what is true yet unpleasant. Instead, most of us will Google for what is pleasant but untrue.”

-Mark Manson

Mark Manson argues the internet has fucked us over and and is doubtful that we can become “unfucked.” So how do we get a person who donate to Red Cross to understand that the Red Cross isn’t actually doing a good job of building homes and communities to lift Haitian families out of the cycle of poverty after the earthquake in 2010?

The dominant versus the subordinate.

When American western culture made its way to the middle east (note that this is colonialism that resembles the European colonialism in 19th century) it brought with it the complexity of popular culture, ideology, and the symbolism that comes with both. Since the 1970s a tumultuous interplay of power dynamics and reactionary fundamentalism has led to the war-torn tribalism that is strangling the middle east today. I can’t really speak to whether or not politicians and businessmen went into the middle east with good intentions—I would make an educated guess that most were interested in globalism, power and riches with the excuse of capitalism. But with them came miniskirts and empowerment for women.

women-kabul2

“Organizations love to talk about bringing the user’s voice into the conversation, yet if it’s just to retrofit an existing growth strategy, it’s morally bankrupt, and in a connected society, a very poor strategy.”

– Jan Chipchase

It’s foolish to think that introducing the miniskirt, or more currently relevant, introducing technology, is the answer to the problems facing middle eastern culture. A valid argument suggests that designers should not be meddling in the middle east at all. That we should stay away. It’s not our job to decide what quality of life is like, what culture is like and what education is like.

Design for all, not just for good.

Since the mid 2000s designers started talking about design for good and human-centered design. In principle, these terms help me understand what I want my designs to do. But I’m not all designers, and I interpret good differently than others that have much more power than myself. PR for big corporations sees design for good as a face for the company. Non-profits and governments see design for good as problem solving for particular wicked problems. These perspectives focus so much on the victims and the marginalized that it fails to see the ecosystem that it needs to support in equity and justice.

Below are several visuals from John Maeda’s design/tech report from this year.

Screen Shot 2019-03-19 at 11.52.00 AMScreen Shot 2019-03-19 at 11.52.07 AMScreen Shot 2019-03-19 at 11.51.50 AM

We have erroneously reversed the value directionality in design for good. The immediate, predictable value of these initiatives is likely to come to the designers rather than to the objects of their work—the recipients of ‘good.’”

– Jayeet Pal

We came to AC4D because, selfishly, we want more out of our work and we want to feel successful in our work life. I can’t speak for my grandparents, but I reckon they didn’t have the same opportunities and world views we do today when we think about our careers and the impact we have. If we want to sit down on a chair the day after we retire and feel good about what we’ve done with our careers, then we need to start thinking about how our legacy lives on and the results and sustainability of the things we make.

dev school.

We’ve been repeatedly challenged to learn this rule at AC4D: The quickest way to understand whether your concept works is to show it to someone else. This week, our challenge was to show our Q3 banking app wireframes to a working developer, work through their questions and responses (and rejections!), and get an estimate of workdays needed to make and ship our app concept.

While I still have a lot to learn about shipping a product from concept to market (that’s what the rest of this Product Management class is for!), our 1-hour meetings with a developer were grounding, humbling, and exciting all at once. Here’s a few things I learned from my first real-world meeting with a third-party developer:

Get Your Shit in Order.

I got through Q3 learning Sketch on the fly. Which means I learned some sophisticated things quickly, and also missed some square-1 basics. Coming out of Q3, my workflow looked like this:

accounts bar, Q3 wireframes

Screen Shot 2019-03-18 at 5.30.36 PM Screen Shot 2019-03-18 at 5.30.15 PM

Not only was my process disorganized—it was terribly inefficient. I still produced some serviceable wireframes, but the UI was stylistically—and functionally—a bit all over the map.

example of flows, Q3 wireframes

Screen Shot 2019-03-18 at 5.35.06 PM Screen Shot 2019-03-18 at 5.35.16 PM

This works ok for a lone designer who knows where she’s going and why. It’s totally unworkable for a team effort, especially with outside consults or clients. So my first shift was to start thinking like a managerIf I am the product lead, what parameters, systems, and symbols need to be in place so others can follow along? 

So I revamped my flow to be easily followed, searchable, and indexed:

accounts bar, Q4 wireframes

Screen Shot 2019-03-18 at 6.07.17 PMScreen Shot 2019-03-18 at 6.07.44 PM

And I learned to save key components as symbols, streamlining both my building process and others’ ease in identifying each flow.

Templates Exist for a Reason.

My first lesson from Chap, the developer I met with, was that anything customizable takes significantly longer to build (meaning way higher developer hours/expense). We sat down to look at my wireframes together, and each time we hit a customized button or login field, he would ask, “Is there specific purpose behind this being customized?” Usually, the answer was “No”—iOS would be fine, and I’d just either not known that was an option, or had just tried to make something cute for the fun of it. Where that approach may work for user testing on the design end, as a product manager you inherit significant constraints—specifically, money, and time.

At his encouragement, I revamped my login screens to use existing iOS buttons and alert formatting. If I’d customized something with specific intent, I kept it. If iOS would work just as well, I swapped it.

You Have No Idea How Long Anything Will Take to Build. 

It turns out I am very bad at predicting what will take a long time. Bitmoji? Only 1 day. Edge detection to capture a check for mobile deposit? Up to 5 days. Linking your app with a third-party bank account? Entirely dependent on any existing agreement between your bank and the other bank, and whether a plugin exists or we have to build one from scratch…so this could take anywhere from 1 day to several weeks. Which brings me to:

Come With As Many Scoping Problems Answered As Possible. 

I had some major blindspots coming into our meeting. I didn’t know if this bank app integrated with others. I didn’t know how many login attempts a user could make before the bank would suspend their account. I didn’t know how far back I wanted users to be able to scroll back through recent transactions before being required to just download their statement. Chap raised several questions around bank data-sharing and “length of time” in my apps’ features, none of which I knew how to answer. This creates uncertainty for the developer, and as Chap told me clearly: The more complexity and uncertainty you throw at a developer, the higher their burden…and they will quote you a (n expontentially) higher rate accordingly.

Chap’s “developer days” estimate. Left: Initial estimate. Center: Scaled 1.5 if mild uncertainty/unclarity. Right: Scaled 2.0 if significant uncertainty/clarity. Note the huge spread between “best case” and “worst case” quotes.

developer’s “developer days” estimate, Q4 wireframes

Screen Shot 2019-03-18 at 5.53.32 PM Screen Shot 2019-03-18 at 5.53.14 PM

With Chap’s feedback in hand, I revised my wireframes: More customized to iOS style; fewer screens to do the same job; and key components broken out for quick reference.

Those are below:

flow: login

Screen Shot 2019-03-18 at 6.08.14 PM              Screen Shot 2019-03-18 at 6.08.29 PM

Screen Shot 2019-03-18 at 6.08.40 PM

flow: check account

Screen Shot 2019-03-18 at 6.08.50 PM

flow: deposit a check

Screen Shot 2019-03-18 at 6.08.58 PM

Screen Shot 2019-03-18 at 6.28.56 PM

Screen Shot 2019-03-18 at 6.09.08 PM

Screen Shot 2019-03-18 at 6.09.27 PM

Screen Shot 2019-03-18 at 6.09.36 PM

components

Screen Shot 2019-03-18 at 6.23.35 PM

Screen Shot 2019-03-18 at 6.23.44 PM

Screen Shot 2019-03-18 at 6.23.55 PM

Screen Shot 2019-03-18 at 6.24.07 PM

Screen Shot 2019-03-18 at 6.24.29 PM 

How do I think like a developer? Lessons learned from my first sizing evaluation with a frontend developer

So now what? I have wireframes that have passed the user testing rounds. But wireframes can only go so far. The next part is to pass the feasibility test. This is the part when the rubber meets the road. As designers have to take our head out of the clouds, come down to reality and start answering the hard question of “Is this app even feasible?” To answer that, only a developer would know.

1. Take Inventory: Break down the wireframes into distinct components. Make an exhaustive list of all features and controls.

First I go frame by frame and identify each distinct component (the capabilities of the app). I am learning to look at my wires in an entirely new way. I made a spreadsheet (image 1.1) to map out an exhaustive list of feature and how they work. It’s important to know this app backward and forward- all the logistics and also the rationale. As a thought exercise for myself, I answer these four questions for each screen.

  • What does the user see? (front end)
  • What is the purpose? (feature)
  • What does the user touch and do? (controls)
  • What does the app think about and do? (backend)

Screenshot 2019-03-19 02.02.52 Image1.1: Feature Capability Spreadsheet

Then once I had all my thought out of my head, I annotated wireframes (image 1.2) aka. redlining), this is a visual that correlates with the features and controls outlined in the spreadsheet. Below is an example, in red are the features; in green are the controls.

!mage1.2 Annotated Wireframe (red for features' green for controls)
Image1.2: Annotated Wireframe (red for features’ green for controls)

 

In preparation for my meeting with the developer, I created simplified and clean versions of the feature’s spreadsheet and annotated wireframes. I also printed out all the wireframes in order to go through the flows. The developer requested printed versions instead of digital because it is easier to look at all the wireframes laid out. It’s also easier to mark up the paper with notes.

2. Size it: Sitting down with a front end developer, I go through each feature in the context of the user flow. Then they determine it’s feasibility and cost.

It reminds me of ordering a cake. I know the exact components: chocolate cake, vanilla frosting, sprinkles and rosettes on top, but I do not know how to make the cake. It’s up to the baker to quote how long it takes and how much it costs for ingredients and labor.
During the meeting with a developer, we first went through the user flow while I verbally described what the features were. Then the developer asked clarifying questions before he finally gave an estimate of how many days it would take to build each feature for the flow (image 2).
My learning moments happened when the developer asked a question I was not prepared to answer. Here are a few of said questions
  • “Is this button custom? or standard?”
  • “Where does the information live- on the device/client or on a server?”
  • “Is this code reusable somewhere else in the app?”

Screenshot 2019-03-19 02.16.58Image 2: Sizing estimate for each feature

All in all, the developer estimated that this banking app with all the features included would take 54-71 days to build.

Thing I will do differently at my next sizing estimate meeting with a developer:

-Bring an abbreviated site map to give a general overview of the app.
-I will make my own estimate predictions prior to the meeting.
-Ask “how can I make this more lean?”. This is a good question because a developer can create solutions to acheive the same end, but by different means.
-Propose more features even if I do not have wireframes to show the developer. 

3. Prioritize. Choose which features make the cut. Weighing between the user value and the development cost, I will re-prioritize which features are most important.

Stay tuned to see which features get cut and why.

Designer Needs Developer: My Blueprint for Building an App

Begin, Again.

“Starting Over!? Nooooo!” said my internal monologue. I knew I had to begin again.

In the final quarter of our year as Interactive Design students at AC4D; we’re learning the pathway to bring a design into the real world. And that pathway can have many restarts or forks in the road. In this case, I’ve redesigned my banking app, Ally Bank, for mobile Apple devices.

I spent the last few months making mockups (called wireframes) on paper and using the program Sketch. I tested my redesign with users, made changes, and went back and started it all again. Then I realized my wireframes looked sloppy, and more importantly, didn’t meet Apple’s Human Interface Guidelines.

Yes, just like cars and trucks have to meet certain size regulations (thanks Federal Highway Administration!) so do mobile operating systems (thanks Apple!). This was the key reason to go back to the Sketch drawing board and make wireframes that a developer could work with.

The saying goes, “developers are lazy.” In fact, they say it themselves. But this is just a cute simplification. More accurately, developers don’t want to do the work of designers. Our class paired us with a professional developer. But before I would go and meet with a professional for an hours estimate, I had to have my wireframes in a decent place. This involved knowing my features, each of my buttons, controls, and an awareness of edge cases, the particular instances where the user doesn’t know what to do.

A rough guide to help a developer get there bearings: Redlining
A rough guide to help a developer get there bearings: Redlining (or in this case, Ally purple)

Designer Meets Developer

I met with Mark Phillip, CEO & Founder of Are You Watching This?! and a very experienced developer. Meeting with Mark was the impetus for creating the guide above, which will help give a developer basic parameters to begin coding.

I showed Mark all of my wireframes grouped in flows. Each flow is a particular task, such as checking the details of an expense. Check out the flow below as an example:

07_User wants to view expense detail and call merchant
Example Flow: User wants to view expense detail and call merchant

Meeting with Mark provided a few key insights:

  • Give a big picture view of the app you want made, perhaps a concept map of the whole system
  • Use iOS standards and guidelines (and Android when needed); particularly built-in functions like date pickers which Apple has already developed
  • Keep tasks on one screen (with pop-up buttons); it can flow better, and it’s cheaper
  • Common customization features can be time-suckers
  • Extensive “redlining” is not necessary, just have visuals, and know what happens when the user takes an action

The flow below is an appropriate example of not making a developer’s life easier. Here, our user wants to send money to an existing contact. But the time-consuming development factor was surprising to me. Allowing the user to select any possible day at any reoccurring frequency is a developer’s nightmare.  The finicky nature of our Georgian calendar causes developers to have nightmares. I plan to reduce the user’s options’ for reoccurring transfers to three particular instances: one time (now); weekly, and monthly.

User-wants-to-send-money-to-an-existing-contact-pt-1
User-wants-to-send-money-to-an-existing-contact-pt-1

 

User wants to send money to an existing contact, pt 3
User wants to send money to an existing contact, pt 3

Cost & Conclusion

Mark was extremely gracious with his time and advice. Based on his estimates to do front-end development; he estimated my 14 flows would take just over 339 total hours, or roughly, 21 days for two developers, or 42 days for a single developer.

Based on a freelance developer hourly rate between $120 – $300/hr; the app would take between $40,000 – $101,000 to build. And that does not account for back-end development (the systems to retrieve all your money data) nor would that include the very extensive task of app management.

With an audience of over six million customers, Ally Bank is most likely hiring a full-time team or employing an internal team of developers to keep this online-only bank functioning.

As for myself, after this assignment I’ll be better prepared in two instances: moving from paper to digital wireframes, and having the visuals for all edge cases before meeting with a developer.

View a comprehensive view of my full flows, hours and cost breakdown here.  

 

Taking Wireframes into Reality

Creating a vision and a visual representation of a screen is a substantially different skill set than the ability to code it into a working prototype. Working with a team is an efficient way to take an app to market; however, teamwork comes with unique challenges. Therefore, designers who are able to communicate with others in their ‘language’ have a distinct advantage in a project management role.

I started the process of product sizing by polishing my wireframes and making the flows more linear. Last quarter I spent a lot of time making my wires feel like a working prototype. However, this made it more difficult to show end-to-end flows. Once I was happy with the architecture of the flows, I began “Redlining” (annotating in red) the flows to better communicate my vision. This, I learned, is what takes the most time. And this makes sense because the more accurately you can communicate your vision (especially when shipping wires off to a developer in a different location, or even abroad), the closer the final product will be to what you want. With the wireframes annotated, I was ready to meet with my developer.

 

FEATURES & CONTROLS

Log In Redline

Set Up Alerts Redline

Pay Now Redline

Auto Pay Redline

Rewards - Gift Card Redline

Rewards - Flight Redline

Deposit Redline

Budget Overview Redline

Scenarios Redline

Flagged Transaction Redline

 

BREAKDOWNS

Log In Breakdown

Set Up Alerts Breakdown

Pay Now Breakdown

Auto Pay Breakdown

Rewards - Gift Card Breakdown

Rewards - Flight Breakdown

Deposit Breakdown

Budget Overview Breakdown

Scenarios Breakdown

Flagged Transaction Breakdown

 

SUMMARY

I met with Eric Webb, who will be developing my banking app, twice last week. He had loads of great insights especially around navigation, custom- versus stock-features, and estimates for how long it will take to complete the app. Below are my preliminary estimates.

Workdays Summary_AS

One thing I learned was how long coding takes. The estimates above are for front-end only (visual elements that the user sees, which excludes any of the behind-the-scenes code that makes the app function).

I also learned that designing for smaller screens is something developers like. Eric told me that you can always scale up, but getting smaller can cause some weird problems.

Reflecting on my developer meeting, I wish I would have pushed harder to get estimates for the back-end code which would have given me a more comprehensive idea for how long this app would take to complete.

The responsibility is on me as the designer to make my needs understood and in this case, I could have done better. To be honest, I was a little intimidated. Eric’s time is valuable and I didn’t want to take too much of it unnecessarily. This led me to not asking all of the questions I had and to not press-in when I didn’t understand something. Moving forward, I will be more cognizant of whether or not I’m communicating effectively.

Link to full estimate spreadsheet.