Camille Blogs a Bit

Writing about design, technology, maybe philosophy, and daily living (in Singapore)

Menu Close

Tag: ux (page 1 of 3)

Digging deep to find product problems

Double hatting a Product Design + Management role these past few weeks have pushed me to look at product design in a different perspective. Previously, I admit I haven’t been trying hard enough to understand why “we’re doing what we’re doing”, and my product thoughts were something I treated as merely suggestions I can offer to the team. I used to think that whatever feature has been decided on, I’d only need to focus on finding the design solution to solve it. But these days, prioritising which problems to solve and deciding on what to build for the next two weeks drove me to a quest to dig, dig, and dig some more.

Working on a product that has a huge user base affords me the access to a great number of feedback, which is great on paper but not always so ‘great’ when you have limited resources. I think, it was only now that I truly understand what it means to understand who exactly your users are, in what context are they experiencing these problems, and why these problems are happening in the first place.

The past couple of weeks, I’ve been going through a few things over and over:

  1. Finding Problems and Understanding Them – which problems happen most frequently, and affects the biggest percentage of our customers? The loudest of your customers aren’t always representative of the majority, so I have to take qualitative feedback with a grain of salt. At this point, I need to support qualitative data with some user research: who is writing in (or giving this feedback) and why? What kind of quantitative data do we have (which are maybe raw for now, so what kind of questions should I be asking so I could find relevant data)? Are they problems for the target market that we’re focusing on? If not, I don’t immediately set it aside. I still have to ask the next question


  2. Understanding the Problem in the Perspective of Different Users – even if feedback came from a small but loud minority, does it actually also affect the majority of our customers? If yes, sounds like solving it will have a big impact for our product! For each feedback we receive, I seek out to know more — who is experiencing this problem, why does this customer care about it, what specific pain point are they experiencing?


  3. What are the Possible ways to Solve this Problem? – the fun part about brainstorming: you don’t have to worry about resources or time (just yet!). Coming up with ways to solve some problems also involves people from other teams, and this requires an active effort to reach out because I realised that not everyone is used to just approaching you to share ideas!


  4. Narrowing Down Solutions – this part may be tricky. I quickly learned that despite having done as much research as I could, solutions will still need to be tested and validated (and some experiments I couldn’t always do on my own). I read that some teams have a “Discovery track” in their Scrum process precisely to validate and test problems and solutions.


  5. Measuring Success – I’ve come across some problems that are hard to measure by just quantitative data (either by clicks/taps, sessions, etc) just because it’s more on the intangible side of things, and for those maybe I could only get assessment through qualitative feedback. But for everything else, finding which metric will show if the needle would move is my next challenge. How will I know this solution worked, and if not how would I know why it failed?


  6. Deciding on What to Build, and By What Means – to be honest, this is the trickiest part for me because I just doubt even what I initially thought were “good ideas”, and then try to convince myself through different means. This includes getting feedback from engineers and other teams. Some questions help: does this problem happen frequently, and to most users? After which I have to balance the answer to that with time and resources.

This is still an ongoing process for me but from the perspective of a designer, asking all these questions made it easier for me to understand why I’m designing something: for whom, and what for.

Where to Start Doing Data-Driven Design

Data. Big Data. Data-driven. Trending buzz-words in the recent years, and as a designer I’ve heard, read, and witnessed how important data is in making decisions based data. Meanwhile, in reality a lot of companies are still making decisions based on what the CEO or client likes. Based on my experience working with a couple of start-ups, as part of small design agencies and from freelancing, “data-driven design” seemed to be an ideal concept: nice to have, but not always possible. Small teams or clients just won’t have the budget. But if I know that data is important in influencing design, then it must start somewhere — even if that means testing the waters myself.

Armed with this determination, reading about data and analysis online didn’t seem to push me forward. I still felt stuck — I can start adding Google Analytics on a site, for example, but what am I doing with all these data? Week after week, sprint after sprint, I felt like I had a vague idea of what we should measure, but the concepts are still a bit abstract in my head.

Last week, IxDA Singapore invited Cyrille Rentier to give a talk on Data Driven UX Design. His talk was so concise that it gave me a better idea on how to start using data to iterate or influence design decisions.

Read more

Notes on Experience Design Framework from Foolproof

Went to a talk last evening, where Elsa Plumley from Foolproof shared their framework on experience design. As a framework, it’s more of a general guideline. I’ve experienced some of the things that were missing in our current workflows and this is something we could definitely try out to improve our process from ideation to app release to evaluation.

Read more

Pulse Beta: when the original app becomes unrecognizable

I use Pulse as a reader for a bunch of blogs that I follow. When I opened Pulse on my phone today, I was thrown into a downward spiral of confusion:

  1. The articles I see are NOT from sites I subscribed to.
  2. I could not find the articles and sites I subscribed to, even when I have an account and even after I logged in.
  3. Who are these people on my feed? Who are these LinkedIn Influencers!? I don’t know who they are, and I don’t care who they are. Why are their articles on my feed, and WHERE DID MY ORIGINAL FEED GO?

I re-installed the app on a new phone, so I backtracked to the Play Store to check if I downloaded the right Pulse. It seemed like I did, but it was not the app that I used to have. I tried to find where the blogs I used to follow were, and lo and behold, without asking, LinkedIn was using the Beta version on me.  Read more

Rethinking Searching for Rent

Listening to the search experience talk immediately made me think about my own moving-from-Philippines-to-Singapore experience. I learned that we are information seeking creatures, and there are search-situations where we find things to make a decision (or decisions). In this case: I needed to find a room to rent.

Read more

Notes from IxD session: Designing the Search Experience

IxD Meetup: Designing the Search Experience
Talk by Maish Nichani from PebbleRoad

Read more