I really enjoyed this most recent Under the Radar by Marco Arment and David Smith. It made me think of a lesson I learned earlier in my career as a developer/designer. When you are building an application that meets a need you have, it’s easy to use yourself as a proxy for the product user when designing/developing.
In the best case this approach helps you to develop an application that can delight users by meeting not just their vocal needs but also their unarticulated needs. Because you know yourself and your needs more intimately than anyone else, you can build really cool solutions to problems that your users wouldn’t be able to put into words. Your intuition will guide you to spend more time polishing areas that others wouldn’t and often times that pays off with a better product experience. This is possible for teams that are solving problems they themselves don’t understand, but it requires much more UX/UI spend, lots of prototyping and lots of user testing. Sounds expensive.
So while this approach can be a great time/expense saver for smaller teams or independent developers, it can unfortunately also lead you to a substandard product/market fit. It sounds obvious to say but it’s easy to forget that you aren’t the only type of user your product will have. I can hear echos of this in Marco’s description of his aversion to prompting users by sending push notifications to point out new podcast arrivals for new users. Marco finds those things annoying and maybe a bit needy. Do I find it annoying when a new app prompts me to come back and check out some feature I haven’t used? Yes, but that’s also because I’m a tech nerd and when apps try to tell me how to use them I get annoyed either because “shut up I already know that” or “You think I can’t figure this out on my own”. The much much more common user reaction to a helpful notification is going to be “oh, hey that’s handy I didn’t know that” or worse case “I’ve already given up on that app so this doesn’t matter”.
It’s very easy for us to transpose too many of our own needs and traits onto our pretend users if we aren’t able to be introspective about why we care about the things we care about in the products we are creating. A small amount of time creating personas for some of your anticipated users and where and how you fit into them can go a long way to improving your product.
Walt wrote an interesting line in a recent think piece on the Verge. He makes a lot of interesting points as usual, but one little quote got me thinking about an easy and frequent mistake we can all make. In the process of looking for solutions and making commentary we often times subtly redefine the problem someone else is having.
But there are other paths. For instance, that HP Spectre I mentioned earlier is actually a tad thinner, but manages to add a couple of additional ports on the back edge of the machine, and to use full-fledged processors, even if they required a cleverly designed fan.
In the emphasis I added above you can see Walt doing this with the design of the MacBook (non-pro) that Apple has been shipping for the last few years. I used the first design of that machine and agree with all of Walt’s criticisms.
What I don’t agree with is the idea that you can hold up another computer that makes different design trade offs as a direct comparison to the trade offs on this particular computer. The design brief for the MacBook probably read something like “needs to be able to email, browse the web, use office class applications, road warriors dream, long enough battery to last cross Atlantic flight”. Walt would rather have a computer that makes different trade offs. To call this a symptom of “overdesigning” a product isn’t really accurate. It’s a symptom of designing a product for a different set of trade offs than the ones you prioritize. Walt is right, this happens all the time, and I see it as a positive thing.
The uncharitable usage of the word Design implies frivolity. But I think what is happening more often is that companies are being very focused, and in the process eliminating a lot of use cases from their product. This isn’t a bad thing, it allows products to be brought to market faster and with less budget, however it does eliminate possibilities, and in my experience reading the tech press, there is nothing that riles a tech journalist up more than a product that could do something if only the product designer had made the product the way the tech journalist thought it should be made.
Technical Journalists do their best work when they put themselves into the role of a user of a product and seek to understand how the company creating the product has done the work of designing the product trade offs to fit that use case.
Product designers do their best work when they are able to capture a clear picture in their head of how a new thing can be created by questioning the assumptions under which we all operate, and integrate some novel thinking into a product in a way that feels like a natural consequence of problem solving.
Just had a thought that wanted to get time stamped so I can “I told you so” later.
When Apple updated the MacBook Air to the new haswell processors many were surprised that they didn’t also update the MacBook Pro line as well. Improved battery life with comparable performance is always great for laptops and the MacBook Pros are no exception so it was a strange omission.
My speculation as to why is because Apple plans on launching a major update in the fall that includes the following:
– new Mac Pro
– new MacBook Pro with retina display
– new 4k displays that are retina capable
The reason they didn’t update the pro laptops is not because they are waiting for haswell but because they are waiting for thunderbolt 2, which they need to support the new displays.
We’ve been using the following technique since shortly after Trello launched to accommodate our Kanban style agile development workflow.
Quick review: Kanban borrows from lean manufacturing principles and is a Pull based system rather than a Push based system. Team members “pull” a card into their todo list when they have a vacant space rather than having a manager or another team member “push” an item onto their todo list.
To facilitate this in Trello we did something very simple. On our board, when you pull a card onto your list, you assign yourself to the card to indicate you are working on it, when you are done, you remove yourself from the card and move it to the bottom of your current list. If you are blocked on a task but it isn’t complete, you label it with a red label which on our board means “Blocked”.
If you have an open slot on your list you look to the previous list for any cards at the bottom of the list that are not currently assigned. Unless they are blocked (red tag) they are available to be pulled.
The only list that breaks with this form is the “Up Next” or backlog list. That list is pulled from the top rather than the bottom, mostly so that we can easily visualize our top priorities that haven’t started implementation yet and can easily reorder the backlog when necessary. Same principals apply though, if the backlog has a person assigned to it, it’s not ready for development, and it it’s Red it’s blocked and can’t be moved forward. Developers skip over those cards when pulling from the up next list.
Simple and effective.
I think John Gruber has issued a somewhat oversimplified argument when he says:
…people want more different native apps than ever before. via daring fireball
I think any designer needs to be careful to not conflate the mechanism used to achieve a desired result with the result itself. Gruber’s assertion here is that users want native applications. I believe that what he is really saying is that users want responsive applications, that work while disconnected from centralized services, and that show up on their home screen. Those are not web apps as they are available to us today, but as in anything in the software world that is a flexible assumption.
My point here is a relatively minor one, but one that can be a common roadblock for creative problem solvers. If we don’t question the assumptions of the underlying mechanisms we will unnecessarily limit the potential solutions available to us. Sometimes the most obvious and straight-forward solution to a problem is found by questioning the underlying assumptions. Technology problems are sometimes solved by changing the personnel around them, or personnel problems can be solved by augmenting the situation with technology. Emotional problems can be solved with exercise, and your exercise limits can be overcome by understanding that your current limitations are psychologically imposed.
If we assume that the solution to responsive disconnected applications can be nothing other than compiled Objective C delivered through a curated app store we cut ourselves off from a wealth of potential solutions to the problem. Only in redefining and clarifying our users unarticulated needs are we able to break through creative barriers and deliver truly ground-breaking technological innovation. Granted I love native applications and “want more different native apps than ever before”. I think John’s statement is true for today, but that it’s an assumption that should constantly be challenged and revisited. We can’t simply condense the current failure of web apps to deliver on users needs to be a condemnation of the entire pursuit.
via flickr user origamijoel
Most folks have a preferred problem solving method. Some know this, and stick to those well worn forumulas. Some don’t, or forget, or let the fear of missing out trick them into going after opportunities they shouldn’t. One of the keys to successful problem solving is to understand your natural approach and when that approach does or doesn’t fit the problem you are considering addressing.
Let’s look at Apple Maps as an example. With almost unlimited resources and skilled/motivated workers why couldn’t Apple seem to make Maps just work? I believe the primary reason is that their culture doesn’t value the type of work it takes to create a killer solution to that problem. Apple is very good at giving designers time and space to come up with brilliantly innovative solutions to problems. Elegant solutions are coveted. Wherever possible a solution is simplified rather than made more complex.
Unfortunately Mapping is not a simple problem, nor is it one that can be reduced. (see the traveling salesman problem) Instead of one single elegant solution to a large problem, mapping requires many small imperfect solutions. Google is willing to embark on a massive, inelegant solution to a complicated problem. (Remember their company was founded on the premise of “downloading the internet” so you could easily search it)
Finding point A on a map and getting directions from point A to point B doesn’t need to be perfect or elegant, it just needs to work. Apple as an organization has never been satisfied with making something just work (ironic given some of their historical marketing efforts). Unfortunately the solution to make maps “just work” is to add a parenthetical “even if it’s inelegant like driving around taking pictures of every street in the world” to the solution.
The reason that Apple isn’t able to create a successful mapping product is because their culture won’t let them do the kind of work necessary to create a successful product.
Seth Godin chooses the same metaphor as I did in a recent post.
Attacking only steep cliffs where no progress is made isn’t particularly effective either. No, the best path is an endless series of difficult (but achievable) hills.
via Seth Godin
It’s all about the hills…
I’ve never bought a case for any of my personal electronic devices. One time a few years ago our IT manager required screen protectors for all of the phone we had recently purchased. I immediately took mine off (oh yes, quite the rebel here). The protectors were supposed to stop the screens from getting scratched up in our pockets, but the immediate result was a dark, scratched looking screen, the exact problem the plastic slip was trying to avoid in the first place.
I’ve had a few good sports injuries over the last few years, and sometimes the road to recovery can look similar. We avoid doing things that hurt because we are afraid it’ll set back our recovery, when sometimes we need to embrace the hurt and push through the limits to force our body to adapt to normal movement patterns instead of our injured ones. My trying to protect against injury leaves us more injured than we should be.
In a business setting, when trying to build resilience in a business model we sometimes build too much diversity in our plans. “If market A doesn’t work out, we can try B or C or D”. Havig a plan B is a good thing, unless you end up sacrificing your top priority in order to keep your backup plans alive.
This is a really common problem. Sometimes when trying to protect ourselves we actually sabotage ourselves. Seth Godin says entrepenuers sometimes succeed because “There are no life boats”. http://sethgodin.typepad.com/seths_blog/2011/11/surviving-google.html
Sometimes we need to burn the lifeboats, risk a little reinjury to prevent the long term decline, and risk scratching the shiny glass back of that brand new cell phone.
image via singlefin
Recently I’ve reached a plateau. Over the last month I’ve reached a certain level of competence as a snowboarder. Nothing amazing mind you, but I’ve reached a point where the blue runs tremble in fear at my approach. I would be hard pressed to say this isn’t a good thing, after all I am certainly enjoying my hat staying above my shoes for most of the day, but over the last few trips up to the mountain I haven’t really gotten any better.
Here’s the question. Should I start pushing myself to do harder things, or should I spend some time simply being content with the skills I’ve acquired so far?
I’ve heard it said that if you’re not getting better you’re getting worse. A lot of times it’s applied in the business world but there is truth to the saying in our personal lives as well. If we aren’t getting faster we’re getting slower, if we aren’t getting stronger we’re getting weaker.
The truth I think is less black and white and more gray. Plateaus are our greatest accomplishments and also our biggest barriers. Since we are infinitely adaptable (well ok, there are probably limits) we will plateau thousands of times throughout our life.
They key seems to be being able to live with a kind of cognative dissonance that both enjoys and appreciates the contentment of a plateau, while at the same time nurturing a sense of discontent with the status quo. To experience both feelings simultaneously.
We all have excuses. Sometimes they are legitimate, sometimes they aren’t. I’ve been trying a new technique to determine the difference. Rather than saying:
“I can’t <goal> because of <reason>.”
“I don’t want to <goal> because of <reason>.”
I find that reframing the excuse helps to break the pattern of feeling victimized or trapped by my excuses. By turning the self talk from a exercise in victimization into a statement of intent I’m rejecting the idea that it is impossible to overcome my excuse.
Truth be told, often times those limitations are not nearly as limiting as we think they are. People are capable of great things when they set their will to something. Often we can surprise ourself with the results of our honest efforts. We all have limits, but those limits are often a matter of quantity, not quality. Anybody can write one really good essay, but it’s much more difficult to write ten really good essay’s a month. Even more difficult to write ten good essays a month if you are also working a full time job and playing in the co-ed rec soccer league.
When faced with so much quantity of life to live, it’s easy to reply on the excuses to determine what we do or do not have time for. Something important to remember when faced with so many opportunties though. We get to choose what we want to do. Nobody decides for us, and when we make excuses we’re taking the easy way out. By giving the power to the excuse we’re minimizing our choice.
“I’m never going to be a great snowboarder because I started so late in life.”
“I don’t want to be a great snowboarder because I started so late in life.”
The first has a childish, impotent sound to it. I’m making up an excuse for my substandard snowboarding prowess. The second almost invites a follow up statement…
“I do want to be a compentent snowboarder because I enjoy it.”
Instead of being a victim of my age, I’ve instead reframed my goal to make it something more attainable, and attainable goals are more fun anyway.