Menu

Product design: a balance between vision, intuition, and data

I really liked this interview with Josh Porter where he talks mainly about good product design, and the importance of user feedback:

Good product design is the result of persistence as much as anything else. That’s why you hear companies like Airbnb and Evernote and others say that it can take years to figure out user onboarding or free trials or other sophisticated flows. It takes a lot of time to get your message right, get the user incentives right, get the interaction right, etc. It is easy to become impatient and throw out some great ideas prematurely.

And this:

The interplay between vision/intuition and data/feedback is that you need both. You need to be able to assess how you’re currently doing with data but also not let data stop you from taking risks with your product. Many teams become conservative over time as they rely more and more on data to make decisions. They ultimately become paralyzed and unable to build something really new.

Don’t fear the empty space

Lukas Mathis writes about our fear of empty space in visual design in Horror Vacui:

There’s a concept in visual art called horror vacui, or «fear of empty spaces.» It’s the natural tendency of humans to fill empty spaces with stuff. Your new shelf has some empty panels? Put something in there! Your flat has an empty corner? Buy a chair! Or a plant! Something! Anything!

Humans have the same tendency when it comes to visual design. No empty space! Your screen has a few white pixels? What feature can we put there! Quick! Find something we can put there!

There’s a problem with that, though. Empty space is not useless.

He goes on to explain that “emptiness equates to prestige.” In short, don’t fear the empty space!

Using Mail.app as a replacement for Outlook for Mac

The biggest problem that many Mac users struggle with is that we work for organizations that use Exchange for email and calendar management. This means that, in most cases, we have to use Outlook for Mac if we want the majority of basic tasks to work. It’s an application that is so ugly and bug-ridden that most people look like this every time they open it:

Outlook

The problem is that traditionally it’s been pretty difficult to make OS X’s Mail.app play well enough with Exchange to be a viable replacement. For my personal use case there were a few things that always held me back:

  • The default view settings are not conducive to effectively manage a lot of email.
  • No keyboard shortcuts to move messages into folders.
  • All other email programs display the default system font when it receives an email generated in Mail.app — in Office for Windows this is Times New Roman.

I think I’ve finally addressed these issues enough to make Mail.app my primary mail application and ditch the horrors of Outlook. But you’ll need a few settings and plugins to get that done.

View options

I like the simple, friendly list view that these options give me. Try it out:

View options

Shortcuts for moving messages

Mail Act-On 3 is an essential extension. It does a bunch of different things, but for the best feature is that you can map a key to moving messages to a different folder (I use “v” to match Gmail’s shortcuts), and then use type-ahead to pick the right folder:

Move messages

Changing the default font

Universal Mailer is another powerful plugin that just makes Mail.app work better, but its best features is that you can set a system font that is respected by other email programs:

Force font

Unexpected bonus features

Switching to mail brings a bunch of great things with it that you don’t get in Outlook:

  • Smart folders that can bring a bunch of different emails together based on specific criteria you set.
  • Great integration with iOS, since it takes advantage of handoff.
  • Fast email that’s not ugly.

All I’m saying is, give it a try. Your eyes will thank you.

The new obsession: daily news apps

Daily

Apps that provide daily news summaries are the current rage. It appears that we’ve moved on from our Weather app and Messaging app obsessions. It’s a worthy goal, though. We’ve created so much noise on the Internet, we owe it to people to build tools to help them navigate all the noise we made. It’s the only viable solution.

Cynicism aside, though, I download all these apps and try them out. Sometimes they rotate on to my home screen for a while. Yahoo News Digest lasted a while. Everyone loves Circa so I tried that for a while, but it was still too much for me. The problem with the news is that it never ends — there are no edges — which is the reason these apps exist in the first place.

The one that I keep coming back to is NYT Now. I really, really love this app. The morning and afternoon briefings are succinct, and give me the sense that I got the day’s most important news. And I can dig deeper if I want to. It’s on my home screen and will probably stay there.

The latest entry to this market is Flipboard’s The Daily Edition. I use Flipboard every day (hey, you should subscribe to my Flipboard Magazine!), so it’s a natural extension and one less app to follow. My only problem with it so far is that I can’t remove sections I’m not interested in (Sports, ugh).

Anyway, the reason I write about this is that there’s something I don’t understand about this space. All these apps were built from the ground up to do some kind of human curation and give people a sense of the most important news of the day. But the two companies that have all the data in the world to make this happen — Facebook and Twitter — haven’t jumped in. I guess you could argue that Paper is Facebook’s attempt at this, but not really because they hedged their bets by making it a full-featured Facebook client anyway.

I don’t know if this is Innovator’s Dilllemma or what, but it seems like these two companies could make kick-ass daily news apps with data they already have at their disposal. Why haven’t they done this?

Implementing Lean methodologies in large companies

Marysol Elorriaga discusses the challenges of implementing Lean methodologies in large companies in Getting buy-in while moving at rocket speed. One of the guiding principles is to “Release early and show results”:

To make the stakeholders feel like they are getting something equally valuable out of taking the “Lean approach”, deliver the MVP early and show results. Ensure that all features to be released can be measured and there is a proper feedback gathering mechanism in place. Ease the concerns of working under the Lean philosophy with weekly dashboards, including customer feedback, learnings from user validation/testing and analytics. Ultimately, having big data and skilled professionals to transform customer feedback and analytics into business insights is a pre-requisite for improvement and innovation.

From the same blog, Elizabeth White gives some advice on embedding a Lean team in a large company in Building the Right Culture in a Lab Environment. It’s especially important to understand that “We are Lean Enterprise – not Lean Start-up”:

Our room is lean but we are surrounded by a waterfall. While we are fully supported by TELUS, and most internal teams want to roll out what we are doing, we are a big company, depending on some serious backend systems. And while I can go on about our fantastic experience and the merits of working in a lean environment, it is important to note, waterfall shouldn’t become taboo either. There will be projects where waterfall methodology makes perfect sense, there are some – much like ours, where a hybrid approach is best and there will be some, where lean, in its purest form, is the correct path.

If you’re thinking of trying a Lean approach in a large company, there’s some great advice in these two articles.

Usability testing in Agile environments

There are some great answers in the Quora thread How do you prevent scope creep in agile projects when usability testing? From Todd Zaki Warfel’s answer:

Usability testing doesn’t have to be a formal 3 month engagement. There are plenty of resources out there for doing rapid testing, which can easily be worked into a typical 3-6 week sprint cycle. We do it all the time. Take a week out of the sprint to plan, test, compile recommendations and get to work implementing them. Or as Jeff Gothelf commented, just pick a single day each week to test. You won’t need may participants. If you test weekly, then 3-5 will show a pattern. And anything you don’t catch this week, you’ll catch next week.

From Jeff Gothelf’s answer:

Usability testing needs to be worked in to the sprint timeline. In fact, it should take place during each and every sprint. We test every Thursday. It’s never more than 3 or 4 people. We show whatever we have ready on that day. Sometimes it’s live code and sometimes it’s a paper sketch. Everything in between is fair game. The purpose of this is to get constant feedback, mid-iteration, on the work being designed. In many cases, developers and product owners view portions of these sessions and see the issues that arise. An expectation is built within the team that, based on how things test on Thursday, there may be some tweaks to the scope.

Do what you love?

My latest column for A List Apart is called How to Do What You Love, the Right Way, and it’s out today. It’s a response to that mantra we hear so often, and loosely based on a rant by Merlin Mann on one of his Back to Work podcasts. Here’s the gist:

Doing what you love doesn’t necessarily mean quitting your job and starting a coffee shop. Most often, it means building your own platform, and crafting your own work, one step at a time.

When makers and decision-makers are far apart

Marty Cagan wrote one of his characteristically great posts in Product vs. IT Mindset. In one particularly harsh section he describes what happens when the people who make decisions about a product are far removed from those who make the product:

In IT mindset companies, accountability frankly is a farce. The people actually working on a project typically have no real say in what they are building, and sometimes even in how it’s built, and even when it’s due. In theory, the leadership team could try to hold the requesting stakeholders accountable for the results, but if they do they immediately hear complaints that they didn’t get what they actually wanted, and because of delays and costs, critical things had to get cut, and so it’s certainly not their fault. So management writes it off as yet another failed technology initiative. In contrast, in a product organization, we are measured by results.

I’ve always felt that this is the biggest challenge to companies as they grow. The further away those who make decisions are from those who build the product, the harder it is to remain customer-focused in the long term.

More

  1. 1
  2. ...
  3. 88
  4. 89
  5. 90
  6. 91
  7. 92
  8. ...
  9. 201