Camille Blogs a Bit

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

Menu Close

Tag: worky worky (page 1 of 9)

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.

From an iPad to an Android tablet

It was pay-day last week (MONEY!!!!!) so I bought myself a mid-to-low range tablet (not that much money!!!): a Cherry Mobile Bolt (rebranded from Ainol Novo 7). I was thinking if I should get the 2nd generation Nexus 7, but I’m actually waiting for the new iPad Mini to be my main tablet so I decided to get a cheap one I can root and play with. I saw some reviews online, and the CM Bolt seemed to fit my budget for a test device (below 5k, specs not so bad, and the OS is barely skinned/themed). I already have the larger iPad, which was why I got the 7-inch one.

Spec list for the curious:

  • OS: Android 4.1 Jelly Bean
  • CPU: ATM Quad Core CPU 1.2GHz
  • GPU: GC1000+
  • RAM: 1GB?DDR3
  • Storage: 8GB
  • Shell Material: Plastic
  • Screen: Capacitive Touchscreen, 1280*800 High-resolution Screen
  • Size: 7 inch
  • Resolution: 1280*800 Pixels IPS Screen G+G
  • Gravity Sensor: Yes
  • Visible Angle: 178°
  • Display: IPS
  • Dual Camera Front camera, 0.3 Megapixels

(Things to note: no bluetooth, GPS, 3G/sim slot.)

As a designer for various platforms (with Android projects coming in as well), it felt important to have more experience with other OS and not just iOS (though hey, I’m not complaining). I’ve recently switched back to the iPhone after a few months with the Windows Phone 8 (the novelty of ‘something different’ wore off, and with iOS 7, its good to be back), and now its time to try Android more regularly.

First Impressions

Charlie was with me when I bought it and he was really skeptical. I don’t blame him. We’re both on iOS devices (he had an HTC once, which slowed down a bit too soon) so we’re kind-of spoiled by speed, smoothness, design (hello iOS7!!!!) and general user experience goodness of the OS.

But I really needed to interact more with Android stuff for work.

Cherry Mobile isn’t exactly there when it comes to visual design and branding (at the very least they have a simpler logo than MyPhone!) so once you get past the default, ugly, pixelized wallpapers, it starts looking acceptable:

Not bad, eh? Got the wallpaper from Pattrn

(Thank you, Pattrn)

I used it all day on Sunday and at first it was quite buggy. I wasn’t so sure if it was broken, or if it was a prime example of low-end tech. The keyboard would double-press keys, and sometimes touch would do the same (touch huge areas on the screen even when I’m not actually pressing on the other areas). I did a factory reset twice, and somehow it stopped being weird on a normal basis (it still happens but only when I try to multitask between apps, or send a number of attachments over email). So I’m just going to assume its not because its broken, but maybe because the specs are quite low. I notice this happened more often when quite a few apps that need internet connection are all on (messaging, fb, tw, email, etc).

Simplenote

The way the resolution renders apps and sites is a bit annoying because even if the tablet is a smaller size, it shows a desktop view (or 10-inch tablet size) so most things are too small to be comfy. Had to go to Accessibility options and change the overall font size Large to make it readable.

It heats up a bit too fast and the wifi range is pretty weak (the wifi nearly ends at the edge of my bed at home, which is maybe 10 meters away from the router, hahaha), but IS only PhP 4.5k (from Cherry Mobile in Robinons Galleria even if other bloggers have gotten it for just 4k)!!!! I’m more surprised it works this well given the price point.

Since I have an iPad 3, I compared the experience of having a larger tablet, and for me pocket-size is easier to use. It feels easier and more natural to bring around for reading, browsing, reading emails, social networks, and the like. Landscape typing is harder on the smaller tablet though — it feels like I’m meant to type with my thumbs on it, the same way that thumb-typing feels awkward when holding up a big and heavy iPad. Being a cheaper tablet though, typing isn’t very smooth on the Bolt so autocorrect always saves the day 😛

Android Tablet App Market

I downloaded and re-downloaded a bunch of apps and the first thing I noticed is the lack of tablet-optimized apps in the Play Store. Even Path seemed to be for the phone-only. It’s been a while since more Android tablets have come up though. Maybe Google needs to be a bit more aggressive with encouraging Android app teams. One of my main objectives in getting this Android tablet was to study the UI design, and very few stand out. I even ended up spoiling myself over Downton Abbey in my search for good tablet apps (because I haven’t watched the Christmas special and CLIFFHANGER spoiled it for me when I wondered if Season 4 was on).

Yeah, good job curious self!

“WTF MATTHEW IS DEAD!? THEY SPENT 3 SEASONS TO GET HIM TOGETHER WITH MARY AND THEN HE JUST DIES?????” — spoiled — Yeah, good job curious self!

My only complaint at this point: the Amazon Kindle app keeps crashing when I load it so I can’t load my Amazon e-books. Uploaded some books to Google Play (Books) instead (which weirdly enough you can only do online and not via the app) and it was pretty alright (page-turning smooth enough, given the specs. I’d want better reading fonts though, but it’s not so bad). I also started trying out Google+ again, but I need to figure out a way to cross-post the status messages to Facebook or else I’m talking to a mostly silent audience. The App market is definitely better than Windows though so, hahahaha. Given that Android’s tablet apps already felt lacking, I can imagine how populated the Windows tablet app market is.

I’ll share my list of apps in a future post.

I’ll be on Day 3 of testing the Bolt today (in which at the end of the week, if I don’t need to get the unit replaced, I’ll update the firmware). I left my iPad at work yesterday so I’ll be forced to rely on the Android tablet and aside from the annoying keyboard lag and touch inconsistencies, its pretty OK (I’m writing the draft for this post on the Android as we speak). I even managed to do some responsive web design work (!!!) via Adobe Edge Inspect. It was not as smooth as Safari/iOS (but that’s Android browsers for you).

wooo yeah, that worked

wooo yeah, that worked

Here’s a recap of the pro’s and con’s

 Pros:

  • cheap (PhP 4.5k is cheap enough)
  • not much skin/bloatware
  • I can update the firmware to speed it up
  • I can root it and play with it and if it gets broken, I’d only have lost PhP 4.5k
  • 7″ is a good size

Cons:

  • heats up quickly
  • battery lasts maybe 4-5 hours in full-use
  • wifi range is weak
  • no bluetooth (I didn’t really initially think I’d want it, LOL)
  • heavy for the size, but not for its price

Set expectations to a low/mid-range Android device and the lag/slowness will be ‘OK’.

I have a lot to say about the Android user experience compared to iOS, but nothing other people haven’t already noticed and proven. Will write more in the next few days!

no longer the first day of september

sort-of start of september

It’s sort-of the start of September, and I may have not done everything I said I wanted to do back in July, but this week has been a week of learning new things, so time hasn’t been completely wasted.

I managed to try out and install Jekyll, and I’m still evaluating how convenient it is (if it is actually convenient) for front-end prototyping. Since Jekyll seems to be primarily used for static blogs, the projects I’m prototyping are more of customized content management systems, so it’s not always easy. I managed to edit a sample plugin someone had put up on the internet and made it work to my needs despite never writing Ruby before (though the changes are minor), which gave me a bit of a push to read up more on Ruby programming.

Perhaps my biggest distractions when it comes to work and programming are: (1) books and (2) GW2. I find Fiction insanely more interesting than design and/or programming books so when I occasionally find a good story to read, I end up doing a book marathon for around six hours before I could do anything else. I have a huge list of design and a couple of Javascript e-books I’ve been meaning to read, but I just had to find a lovely fictional novel to make myself giddy and happy.

And such was my circumstance last night when I started (and finished) reading The House at Tyneford. I’m easily a sucker for romantic novels, much more when they’re set in various time periods, and this being set pre- and during WWII was no different. My inner romantic properly satisfied, today I can focus on work again.

It’s the weekend again, and although I’m cramming some work for Saturday and Sunday, it’s not so bad.

 

Intro on Task-oriented Information Architecture

I’ve been looking for some online articles to read up on task-oriented IA for a project, and haven’t found many.

The first blog post I saw, and that have been linked by others, was Michael Andrew’s short introspective entry about it. Here he says:

When experimenting with task-oriented IA, here are some issues to keep in mind:

  • Activity structure. Are tasks batched around a group of items, or around a sequence of events? Interestingly, the same mix of objects and processes may be done in different ways, depending on who is doing the work, and what the context is. How a customer representative processes a form will be different depending if the customer dropped in his local branch to deliver it, or whether it was mailed in and is sitting on a stack with other people’s forms.
  • Inputs. How is information received and entered? Does it come in a clump, or in dribbles? Are inputs calendar-driven, so you can predict when you will receive them, or can they arrive at any time?
  • Time dimension. Are tasks done in parallel on the same timeline, or do they go on divergent timelines? Are sequences of activities fixed or flexible? Sometimes activities start at the same time, and get processes concurrently, though the services themselves involve different durations.

Some other interesting reads:

Task-Oriented and Modular Design: The solution to improving the quality and efficiency of documentation

Task Analysis: Topic-Based Writing in DITA

Commute.ph improvements I’ve been working on last night. With the help of smooth-scroll. Simple things. 

I used this code to append the fieldsets: 

$.get(page, function (data) { $('.route-building').append(data); });

Tooltips and Popovers not working on Bootstrap

For a while I couldn’t make Bootstrap tooltips and popovers work. I had all the necessary js and css files, with the right js code. Been googling the issue and found this ticket: Tooltips custom selectors does not seem to work.

I’m not using custom selectors, but for some reason I just couldn’t make the default code work. So I followed the suggestions on the git thread. I changed [data-toggle=] with [data-tip=] and [data-pop=] and added a bit of .js: 

$('[data-tip]').tooltip();
$('[data-pop]').popover();

Finally! That seemed to solve it!