Product Idea: Privacy First in (Food) Delivery

Problem: 

How many times you received a food delivery and you see on the tax receipt written your name, address, and phone number?

How many packages did you get from a courier with the same data written with giant letters?

Data that could identify you is private, and we must protect it. At the same time, your delivery partner needs those details so they can fulfill your order. Are we in a Cacth 22 type of situation here? Not at all! 

Let’s see the flow of data in this complicated situation:

  1. You order food via your favorite app, and you give your name, address, and phone to them.
  2. They are just an aggregator, so they forward your details to the actual place to prepare the food.
  3. The restaurant uses a courier company (or a shared delivery engine) to deliver the order to you, and of course, they will share your details with them.

You can see your data flowing from system to system without your control or awareness. If you put it on top of that, they print out the tax receipt and hand it over to a 3rd party without your consent, and you could imagine all possible threats. 

You don’t have the visibility of who is doing what with your protected personal data. Any party of this chain believes that they need your details stored and printed out to “help you” get your food or item. And you even pay them to abuse you. Too harsh? Nope.

What is the solution, then?

Let me get this right. We all need service like that – where you can order stuff and get it at home. The goal here is – can we get a service that 1) believes your data is precious and it will use it only when needed; 2) with your permission, and 3) without storing it?

Imagine a situation like that..

The courier needs to deliver you some food. Before she is leaving the station, she would need to know where to go. Remember – they don’t have your data. Then she opens up an application and initiates a request to you to share the details. 

Privacy Application - Request

Then while sitting on the couch, receive an alert for the request.

Privacy Application - Responce

The courier is requesting the first name and the last name. You think they don’t need them for your food delivery. They could need your address and maybe your phone. So you select what you want to share and send it to them by selecting data from your data wallet, where you keep your details secured and encrypted.

Then the courier receives that, and the data will be available only until they deliver the food to you and then will expire and not be visible or stored anywhere. 

Data Wallet?

Here, the concept is that you, as a human you own your data. You keep them safe with you as you have your physical wallet. When someone needs a bit of information, you decide what to send and how long they can have it.

* In the text “Data Wallet” is a concept, not a name of an already existing product.

Privacy First

As I said before in this tiny article – the data we share with random parties must be protected. The best way to do that is to have the control at your disposal and not count on 3rd parties to do that for you. Most vendors are using the data you shared with them for the means you never agreed to. So why don’t we take the control back if the technology supports that?

Food for thought

  • If you recycle, how many times did you make your data unreadable before throwing the envelope in the bin?
  • If you look at the paper recycling bin that sits in front of your building, how many names, phones, and addresses you think you will find?

Privacy header image by Nick Youngson. Published under CC BY-SA 3.0

How I run Ideation workshop to hear “the voice” of the team.

I missed a step in my previous article on purpose. I was planning to write a separate article about that and here it is.

When I was completing my UX training by Chris Nodder I liked a technique called “Ideation” and I have decided to hack it and to use it for my own purposes – as a product person.

So here’s what I did:

Booked a room:

I booked a meeting room for 2 hours. There is no special requirement for the room – you just need a table, a few chairs and a projector. You can also do it in a quiet working space with no cubicles or in a non-smoking bar.

Provided some sweets:

I’ve bought some sweets, to help people concentrate on the topic while doing something with their brains, their hands and their jaws. Later I realized that it would have been nicer if I had brought fresh fruits or something more healthier (I’ve red that in a book called (Design)“Sprint” written by a couple of Google Venture folks).

Provided the tools:

I bought colored pencils and I printed out lots of templates to be used during the workshop.

The template

Ran the workshop:

So, yes, the workshop – the idea was to get different people together working on a task to get some ideas and fresh views.

I invited people from different teams – I got a couple of QA guys, a few of Business Analysts and a bunch of programmers.

Then I randomly divided them in teams. And I gave them the task – a short list of user requirements with the question: How would you do this? Use your imagination and the template to create a simple prototype for just 15 minutes.

There were a few basic rules:

  • The requirements must be always visible on the screen
  • You can ask me questions if you have any (I was the customer)
  • Don’t talk, just prototype and eat sweets.

After this 15 min period, every team had 2 min to present their work in front of the others. There was no opportunity to ask questions during or after the process.
Here are some of the results:
A few ideas A few more ideas more ideas

and even more ideas

As you can see – you can do whatever you want, but you have to be able to explain it after that to the rest of the team and to focus on how it fits the customer requirements.

Anyone can prototype!

We repeated this with a few more requirements and at the end we had a lot of ideas to discuss with the rest of the team.

The outcome:

The goal of this workshop was to hear “the voice” of the whole team. Some guys are shy (mostly the developers, oops) and can’t share their ideas while we are discussing in a meeting.

The output was to generate ideas and to show great approaches on how we can solve a customer pain point.

Solving customer pain point through simple prototyping and using my 20/10 rule

Prototyping is part of my work. I don’t trust product owners or analysts that do not prototype ideas and share them with the customer or another stakeholder. I will tell you more now about my strategy and I hope it can be useful for you.

I have grown the ability to listen, remember and prototype nearly live time, but since my buffer size is not so large I ask the customer to do short 30 min iterations, instead of just Q&A for 1 hour.

How does it usually work?

 

First meeting

Let’s have this imaginary situation – a customer approached me to create a very simple (from hers point of view) application to help her to run their business better. The first 20 minutes of our discussion I have been asking questions and in the next 10 I have been able to come up with an idea. After 30 minutes I had this ready – ugly, but useful

Prototype on Paper
Prototype on Paper

The customer was happy with the development, so we moved on to the next screens, again using 20+10-minute approach. At the end of the second working session, I had the full concept on paper together with a lot of notes and small indicators of interaction. (see the arrows and the kpi indicators)

 

Second meeting

I put all of these papers on a wall and I have created the first digital mock-up by using balsamiq (one of my favorite tools). I tried to make it as close to the paper version as possible spending half a day in just making it “clickable”, so I can present it later faster.

 

Digital Mock-up produced after the first meeting.
Digital Mock-up produced after the first meeting.

 

After that I had a presentation session with larger group of stakeholders (from customer’s side). In general they liked what they saw and asked when they could play with it. I told them I would give them a prototype in a week, noting that the prototype would not look like the one they saw today since the appearance would have to come come from our design team (mainly thinking about UX guys first). The agreed principles, however, would remain the same.

 

Third meeting

With all the screens and my notes I contacted our UX guys and Information architects. They gave me some advices on how to incorporate our company style, usability patterns, and UI into the prototype, using the information I have collected. The final result was smashing. I have created a small Js APP using the company framework to make a real looking prototype.

 

Part of the JS solution
Part of the JS solution

Another view of the JS prototype
Another view of the JS prototype

The customer was happy with the job we have done. I gave them the prototype to play with and we tracked their way of learning the new interfaces and their journey inside the app. We have collected useful data and that helped us a lot in developing the product.  By knowing what everyone expects I can write better tasks to the developers and will shorten my communication time with the customer and other stakeholders.

It was a huge success and I am planning to use this approach again.