Skip to content

renepacchaux/gudeeds-responsive-mobile-app

Repository files navigation

Proposing Gamification

  1. Good deeds
    1. Anxious situation for task delivery
      1. Intro
      2. Looking at the Task Business
      3. Research
      4. Gaining trust
      5. Challenge
      6. Project Solution
      7. Design Work
      8. Two canvases
      9. Clear feedback
      10. Testing the Prototypes
      11. Snapshot and moving forward

Good deeds

img

Anxious situation for task delivery

  1. Enabling deed recognition by locals

Intro

Participating in a team of five designers and five developers, I roughly communicate what later becomes team touchpoints. Decisions by the engineers are facilited with the design process.

I'll talk about how I process a decision-required meeting.

Looking at the Task Business

Read on to see what research and business decisions helped fast-forward the live project to a prototype status while also learning about what guides my priorities in design meetings in a team setting.

I am concerned about efficiency and time spent in meetings with designers and developers.

Ultimately, I am building context to accurately express the blueprints to the part of the team that will continuously build it.

Early Assumptions

The cross-functional team went to build all the parts that make up the profile within an app. This person they are modeling has age and location and a role as task giver or receiver.

The mobile-sized screen is my chosen screen to build. This would put anything other than phone-sized screens further down the priority ladder.

I call out a few details about the choices and what doors they might open for future continued updates.

  • Desktop Web Application

    I can get a lot out of browsers. Where a user will open a laptop computer is already defined.

  • Mobile

    I know there is less room for features. Where a user looks first takes a smaller footprint.

To help, I use pieces from [Figma's Material Design UI kit] (https://www.figma.com/community/file/880534892514982400).

I take my questions to other designers before meeting with engineers. When talking to the design team, they mention apps being built out for multiple screens.

At this initial stage, I need to describe a thing that already works. For example, I picture myself at a grocery store. I am carrying a laptop. Who pulls out a laptop at the grocery store? In my thought experiment, I am likely to use my phone instead.

Is it worth a fast-forward sketch-level quality if we know what design system we are in?

To help move this piece forward, I can set one screen as a goal: the mobile version.

I reap the benefit of not doubling my effort over the same material. I need to know consensus direction. I do not need to know plans at this stage. I can listen to issues about the buildout along the way. I wanted to commit to the next meeting going smoothly.

Before any pencil has hit paper, I have made a mental decision about where this application will live.

Research

Much work on the UI has been done externally before I start. I only need to look and see what is out there.

To keep from doing repetitive work, we looked at commonly used (but widely established) features that we would use as pieces of our puzzle in building the initial test app.

Commonalities

I involve more and more interviewees, testers, co-workers, and actual neighbors to better grasp of what the user might use.

Investigating features in similar class apps opens up an opportunity to add new capabilities.

  • Cart
  • Schedule
  • Sort

In similar task apps, we find categories or filters. There is at least someone picking up groceries for somebody else.

  • Task Rabbit
  • Amazon (Wholefoods)
  • Instacart

I work to break feature information down into digestible parts.

Parallel to the inner workings of Gudeeds, the design contributed to what is seen by the user, qualifies as the first action item for a person who needs a thing. The developers have input into deciding the priority of new capabilities we put into the app.

Designing in sprint

A situation was a time-crunch. It was a competition with judgment at the end. Prompted by a set needs, the business ask assumed to carry the business competition considerations needed to follow through on some aspects of the design.

Trust themes

We grouped the themes that came up among the neighbors interviewed.

Learn Quick

In a persona, I attempt to sketch out the day-to-day of a real person with limited time as it pertains to specific frustrations. Who does she pay back first?

Gaining trust

img

https://www.renepacchaux.com/charts-overview/mood-board-proximity-gif

Challenge

For favors, just the stress of asking is enough of a barrier to moving forward. It is the top theme in user interviews.

Project Solution

Less Stressed

Their offers of help go to Sabrina, where if she wants, she can approve or deny based on her original request, focusing on neighbors she deems appropriate.

While she may be busy adding the first few tasks, the estimation is that at this particular moment, she is less stressed out.

Business Analysis

There are symbols or items people expect and go to first. It is important to spend time uncovering those items.

These allow the user to work fast:

  • Cart
  • Date
  • Items
  • Sort

Closeness of Volunteers and Trust Themes

First to sign up

I sketch out the mental picture to document why a person in Sabrina's shoes would have felt the way she did.

I thought about delivery and the final designer meeting. I was a little nervous delivering it to forty people.

Intro to the persona

Our persona was built on a few back-and-forths we had about our mindset.

She has kids and little time. Our Sabrina happens to be a nurse with odd hours.

I take my chance to ask any questions about our representative person, Sabrina.

Persona 1

Sabrina also works to raise two children.

To maintain a growing connection to the people around her and in her building, neighbors need opportunities to help. I worked on simplifying this.

Sabrina needs help. She needs to ask for a favor.

The gudeeds app needs more user uptake to be successful. It is my role to ask what is possible from the dev team.

Don't we need a network in place to gain trust? Is that something that can be coded? The team of engineers seemed to appreciate this problem being voiced at our meeting. I'll consider it in the 'maybe' pile for now.

The persona adds neighbors. They, in turn, help her down the line. Without an initial network, what would lead Sabrina to believe that this app can be of any help when she downloads it?

Design Work

Sketching

I knew my first pencil design would be on a phone-width canvas or a 3x5 actual physical card. I needed to sketch and visualize it.

I moved forward incrementally, and so did the design team. It gave us time as it guaranteed action on a design decision.

I contributed to the design studio visuals knowing we had a short amount of time. We used a bracket system to come up with the final design for our sprint. The design studio winner was cleared away at the last moment for a simplified, condensed, streamlined approach that was drawn live on a meeting.

Two canvases

There is the volunteer who participates by completing grocery pickup and other tasks for the neighbors. I had to be alert about for whom the first draft is about - the volunteer or the neighbor, or both?

Discussing them separately

I make sure, for example, an extremely busy person is not inundated with learning. This app might assign or help with a lot of work at the end of the week. Sabrina, for example, may have the app in hand to possibly do the opposite and take on more tasks than usual.

Now there is a one-pager. In total, a few screens were laid out in succession. This is when we put that much to the test.

Are we talking about using the same screen for adding and taking on tasks? The design and engineering teams agreed that it would be both.

Our design library helped make the decision to moving to a provided color palate.

We asked two actual neighbors for their help and interviewed them.

Clear feedback

We easily save time by acting on good feedback and making good bets. They lead us to clear skies when acting on their clues.

Our initial perception

Sabrina hypothetically prepares for her upcoming week with the help of the Gudeeds app volunteer scheduling app.

Primary action button perception was:

  • Confusing
  • Redundant

Categories

Clarifying the types of tasks that others get help with, she is likely to book also.

Testing the Prototypes

img

https://www.renepacchaux.com/charts-overview/gudeeds-proto-frame-blueprint

I conducted interviews and asked for thoughts aloud if they were comfortable to do so. While explaining their touchpoints on the app, I noted some recurring problems with button placement. There was also confusion about which buttons provided similar action.

Snapshot and moving forward

Maybe for the backend - a dashboard, maybe. Because the testing gave an already clear direction, this contribution did not make it past the design studio stage at the early stages of work.

Gamification can be useful here and something worthy of testing out. I decided to explore this.

It would be fun to have a ‘karma'-like score.

At judgment time, I thought back to the positive approach ‘more' hierarchy would add to the app. After all, I came around on gamification.

Gudeeds as client

To Gudeeds' stakeholders, the tasks mean bookings. Each confirmation is an indicator of the design that the app is more reliable.

Next Steps

Turning the task system into a game sounds like a fun idea.

Fit for games

Sandra just downloaded the Gudeeds app. The app will help build trust across her neighbors ' relationships.

If booking now is based on trust, will charts and mini-analytics be more efficient at confirming her bookings?

Releases

No releases published

Packages

No packages published