Subscribe: Bokardo - Social Design by Joshua Porter
http://bokardo.com/feed/atom/
Added By: Feedage Forager Feedage Grade B rated
Language: English
Tags:
appeared bokardo  appeared  apple  bokardo  care  design  designers  experience  feedback  make  new  people  product  time 
Rate this Feed
Rate this feedRate this feedRate this feedRate this feedRate this feed
Rate this feed 1 starRate this feed 2 starRate this feed 3 starRate this feed 4 starRate this feed 5 star

Comments (0)

Feed Details and Statistics Feed Statistics
Preview: Bokardo - Social Design by Joshua Porter

Bokardo



A blog about interface and product design by Joshua Porter



Updated: 2016-09-20T17:12:43Z

 



1 hour of research saves 10 hours of development time

2015-04-30T12:46:26Z

I was recently talking to a developer who was building out a new stream view for a web app she was working on. She was in the middle of getting infinite scrolling to work, which isn’t very hard for developers these days but it does take a significant amount of time to do elegantly. My […] The post 1 hour of research saves 10 hours of development time appeared first on Bokardo. I was recently talking to a developer who was building out a new stream view for a web app she was working on. She was in the middle of getting infinite scrolling to work, which isn’t very hard for developers these days but it does take a significant amount of time to do elegantly. My experience has shown me that in most cases streams are not the best way to present information. In fact, outside of social apps streams are rarely useful. So I started asking questions about what the stream view was for. Who was going to use it and what would they do with it? Very basic questions. It turns out that the stream view was just another view the team thought might be useful, but they hadn’t actually talked to any users to confirm that. I asked why. After a few minutes of my badgering the developer looked at me and said “You know, I think we just are assuming it’s valuable”. Now, it’s possible that the stream view is a good addition to this app. That’s not the point. The point is that a very small amount of research could have confirmed whether or not this was a good idea. As it was, the team was spending 20 or 30 hours building this screen….a significant amount of developer time! And for startups it’s an even more critical amount of time…because it is potentially taking away from some other growth activity. Not only that, but there are other costs. The time to maintain the screen going forward is not trivial. And any associated support time as well. But the biggest cost is probably the most hidden, and that is the cost of additional overhead in the product for the people who use it. Every feature adds complexity to your product. Even if you hide the new feature on its own tab it is taking up valuable space, not only in the UI but in your user’s heads. You’ve added another option that they now have to decide between. For the first feature added…not a huge effect. Over time, however, enormous. Every subsequent feature adds more and more friction. It’s not scientific at all but I’m now thinking that: 1 hour of research ~= 10 hours of development time. Or, in longer terms if more people appreciated how one day of user research can save weeks of coding I think they would do it more. It is remarkable what you decide to not build after talking to a few people closely. And it is remarkable how much you can learn from just asking a few questions or showing a mockup to a couple users. I have a background in usability and design, so I’m biased, but it’s basically just being curious and asking questions. Anybody can do it. So if your hammer is the ability to code, don’t just hammer everything in sight. Ask a few questions first. Take an hour or two to make sure you’re building the right thing. FYI: I’m writing a new book on how to communicate your product or service called Make them Care!. If you would like to be reminded when it comes out, sign up here. For an excerpt, check out Designing for the Next StepThe post 1 hour of research saves 10 hours of development time appeared first on Bokardo. [...]



Tips on how to hire a good designer

2015-04-15T18:38:48Z

It seems like everyone is hiring designers! They’re hiring product designers, UX designers, creative directors, directors of design, UI designers, visual designers, etc. There are even acquihires of entire design teams! So…how do you find a good designer? First, a quick backstory for people who have never read my blog before. Until this past August […] The post Tips on how to hire a good designer appeared first on Bokardo. It seems like everyone is hiring designers! They’re hiring product designers, UX designers, creative directors, directors of design, UI designers, visual designers, etc. There are even acquihires of entire design teams! So…how do you find a good designer? First, a quick backstory for people who have never read my blog before. Until this past August I was the Director of UX at HubSpot, a SaaS marketing company here in Boston that went public in October. So for three years (in which HubSpot was growing quickly) I was the hiring manager for product designers and UX specialists. There is nothing I did at HubSpot that I am more proud of than the team I hired there. This article contains a bunch of tips from that experience. Always be building relationships. The best strategy to take when looking for designers is to always be building relationships with the best designers you know of. This is not typical “recruiting” (which is too often about trolling LinkedIn and sending cold emails). This is building relationships through personal interaction with designers. I know…I just made the task way harder! Always be recruiting, even if you don’t have an open job posting. Go to design meetups and just talk to designers about what they’re working on. Email someone with a killer shot on Dribbble a heartfelt compliment without expecting anything in return. Ask who is doing great work. Ask for intros to friends, etc. Portfolio, portfolio, portfolio. Education is fine. Experience is fine. Job titles are fine. Talk is cheap. The portfolio is what really matters. Can this person do the work you need? If your goal is to hire a junior designer and grow them you can overlook a smaller but promising portfolio if they have everything else you want. But if you want someone to step in on day one and get the job done, you need to see something in their portfolio that is already at the level of what you need. Have they built a similar product before? Don’t let someone with a great personality fool you…if they cannot show you great work and tell a compelling story about it then they will not be able to do that on the job. Frankly I don’t care if you have any education or degree…if you have the chops it doesn’t matter how you got them. My favorite portfolio ever was a single white page, beautifully designed, containing only text and an extremely focused message about why this person was the right fit for the job. They had thought about exactly what that page was for, how it should be designed, what it would be used for and by whom, and was just as effective as a dozen screenshots on some portfolio site. Can they tell a story? Storytelling is a crucial skill for designers. First, can they tell a compelling story about the pieces in their portfolio? About why a design is a certain way and not another? Can they connect the design they ended up with all the way back to an initial problem they’re trying to solve? This doesn’t mean that they’re captivating soothsayers with amazing voice inflection, but they need to be able to narrate the lifecycle of their users and show how they solve for it in their design. Or do their stories fall apart and have logical gaps? This is important in hiring but also on the job…if a designer can tell a story then they can convince others that their design is the right one, that research is important, that they’re solving the right problem. I’ve seen some fantastic visual designers who just couldn’t tell a story and who ended up always designing for themselves…beautif[...]



Does Apple care any more?

2015-01-07T15:17:25Z

Marco Arment, in his recent post Apple has lost the functional high ground: “But the software quality has fallen so much in the last few years that I’m deeply concerned for its future. I’m typing this on a computer whose existence I didn’t even think would be possible yet, but it runs an OS with […] The post Does Apple care any more? appeared first on Bokardo. Marco Arment, in his recent post Apple has lost the functional high ground: “But the software quality has fallen so much in the last few years that I’m deeply concerned for its future. I’m typing this on a computer whose existence I didn’t even think would be possible yet, but it runs an OS with embarrassing bugs and fundamental regressions.” After hypothesizing that Apple’s priorities are out of whack, he writes: “I fear that Apple’s leadership doesn’t realize quite how badly and deeply their software flaws have damaged their reputation, because if they realized it, they’d make serious changes that don’t appear to be happening.” Marco’s post is remarkable, for several reasons. First, he says he regrets writing it. I know how he feels…I’ve written posts that had too much bluntness and not enough tactfulness and felt bad about it. But I think there is a deeper story here that is about more than software vs. hardware or even reputation. I think it’s really about trust. Forget for a minute whether there are more bugs than usual in Apple software or if things just don’t work seamlessly. Those are merely symptoms of the real issue…people equate product quality with how much a company cares. Think about it…the vast majority of our experience with Apple is through our experience with their products. That’s the bulk of our relationship with the company and so when those experiences aren’t as great as we expect we can only conclude that people at the company don’t care as much as they used to. Apple is a complete anomaly in this regard. They have built such good products for so long that people just assume that they care. You can’t build such beautiful things without caring. Good design is no accident. This is so, so different from almost any other company out there! If any respected writer were to write posts about how Comcast or Monsanto or Microsoft doesn’t care there would be zero controversy (even though I’m sure there are people who care at those companies). But their voices aren’t heard because our experiences with those company’s products speak instead. Those companies haven’t put customers first for years and we stopped caring a long time ago. Marco gives Apple the benefit of the doubt and suggests they just don’t see how bad it has become (and if they knew they would change course) He’s assuming they care. I think they care, too. But the possibility that they don’t care is the real fear here. We want Apple to care. We know they can care. We want a company who actually cares because almost every other company doesn’t. But if our experience is deteriorating…does that mean they don’t care anymore? Here is the takeaway: Your product communicates how much you care. The user experience people have with your product is translated in their minds into how much you care about them as a customer. And people want to do business with companies who care. We look for signs that they care, whether it be how we’re greeted at the coffee shop, how a company packages their products, how salespeople treat us, how their Genius Bar geniuses help us, or how easily our Apple TV works with our iPad. The entirety of the user experience matters because of this. The best feeling is knowing that even if a product doesn’t work 100% you’ll be taken care of because you know the company cares. That is what is at stake here: the erosion of trust. I’m not just hypothesizing. I recently learned this lesson the hard way on [...]



In detail: Designing in context for mobile

2015-01-03T16:08:02Z

I’m noticing an interesting practice emerging when designing for mobile: in-context messages that help you learn or give feedback about an app. Here’s an example: In this example from the New York Times Now app, the designers have dropped in a “quick tip” to let you know that you can swipe left to discover new […] The post In detail: Designing in context for mobile appeared first on Bokardo. I’m noticing an interesting practice emerging when designing for mobile: in-context messages that help you learn or give feedback about an app. Here’s an example: In this example from the New York Times Now app, the designers have dropped in a “quick tip” to let you know that you can swipe left to discover new content in the “Our Picks” section. Swiping in this way does the same thing that tapping on the arrow in the nav bar. This is a really nice way to let people know something, in this case that an action is available. (That said, I think it could be argued that this action should be more easily-discoverable in the first place. It’s not clear that the arrow at top is a tab…the shading is very subtle and the arrow icon seems more like a share button. Simply labeling the tab “Our Picks” would be helpful) In this example from the Circa App the designers have embedded a feedback question directly in the news flow that is the main interaction in the app. This is a great way to gather feedback from people who use the app *while they’re using it*. This gets around several problems with gathering feedback, namely the problem of asking people outside of their normal use or at the wrong time. That said, I do find myself not answering the question in many cases, however. I wonder if engagement would increase with a non-committal answer like “Meh”. I find that lately I’ve been pretty feeling Meh about the app…not a real strong feeling either way. I think it could be argued that asking for a binary answer will give cleaner feedback, but a feeling of “meh” is still very instructive…it means that the person is only have a mediocre experience. The Circa designers follow up an answer by asking for more feedback, and then make it clear that they won’t ask again, a nice touch. There are several caveats when thinking about this type of UI element. First, this technique can be easily overdone. If you inundate users with this technique it will quickly take away from a positive experience with your product. Best to use this technique sparingly and only when you’re sure you’re adding value. (Twitter, for example, is getting close to this threshold by embedding unexpected content into your Twitterstream annoyingly) Second, this technique shouldn’t be a crutch used to overcome some UI or product deficiency…if you can solve it by designing something more clearly (which may be the case in the NYTimesNow app) then try that first. I wrote more about gathering feedback in my most recent post on Square: In detail: Square’s email receipt and feedback flow FYI: I’m writing a new book on how to communicate your product or service called Make them Care!. If you would like to be reminded when it comes out, sign up here. For an excerpt, check out Designing for the Next StepThe post In detail: Designing in context for mobile appeared first on Bokardo. [...]



In detail: Square’s email receipt and feedback flow

2014-12-29T15:35:37Z

Since paper receipts aren’t very useful these days, I’ve been choosing recently to have my receipts emailed to me. The other week I filled out my email address on a Square checkout device at my local coffee house (Atomic Cafe) and didn’t think much of it. But when I read the email receipt later I […] The post In detail: Square’s email receipt and feedback flow appeared first on Bokardo. Since paper receipts aren’t very useful these days, I’ve been choosing recently to have my receipts emailed to me. The other week I filled out my email address on a Square checkout device at my local coffee house (Atomic Cafe) and didn’t think much of it. But when I read the email receipt later I noticed that the Square designers had very nicely embedded a feedback flow into the email. Nice UI details: Feedback is embedded into the receipt. This has several positive effects. First, it ties the feedback to the actual transaction that the person just had and not some amorphous “experience with the company”. This will get you much better, detailed feedback because it focuses on a specific experience with the company. Second, it asks you at a time when you might be ready to give feedback, after you’ve had the experience. For experiences that take time (like enjoying a coffee or sandwich) there is no perfect time to ask. Attaching the question to the receipt seems like as good a time as any. The copy is friendly and efficient. How many surveys have you been solicited for that start out with something like “Would you like to take a survey? It would help us blah blah blah”. Most survey copy is not approachable and focuses on the hurdle of interrupting people for an answer. (it’s right that it is interruptive, but not helpful in copy). Instead, because this copy is in context, they skip right to the question: “How was your experience?”. It’s obvious that this is a survey! The smiley faces are approachable and obvious. The receipt looks like a receipt. Paper isn’t useful to have, but it makes sense to make this email look like a paper receipt to help communicate what it is just slightly more quickly. This takes advantage of our experiences with receipts. As paper receipts go away, one day this might not work. The company is primary, not Square. Square’s branding is very minimal here which reinforces my relationship with Atomic Cafe. I could easily see Square or a similar company mentioning themselves in order to build mindshare that they are the underlying technology. By keeping the focus on my relationship with Atomic Cafe the experience is better. Problems with typical feedback surveys Gathering feedback by embedding it into the receipt gets over a couple familiar problems with surveys. The most typical problem with surveys is that they are one-time mechanisms…they are typically sent as blast emails to a large group of people at a single point in time. They can gather extremely valuable feedback, but tend to have low response rates because they aren’t in context like in this receipt. And because they aren’t in context, it quickly gets annoying to send survey requests often…customers quickly tire of being asked. The data is also less useful in a typical survey because it’s usually generalized to your “overall experience” with the brand…not the experience of a specific transaction. Typical survey feedback is also tied to where your product or experience is at the time of the survey. By tying the feedback mechanism with the receipt and making the feedback about this transaction, the data received with Square’s flow is more valuable than a generic survey because you know when the moment the experience happened (date/time of the receipt). Gathering ongoing feedback in this way is much more valuable than one-time surveys. You always have new feedback to respond to that is[...]



The problem with “we’ll fix it later”

2014-12-23T14:59:47Z

I was talking to a design team yesterday and one of the team members casually mentioned that they were launching something new. I took a quick look at what they were planning to launch and it was clear that something wasn’t quite right…there was a weird UI bug and some data looked off. So I […] The post The problem with “we’ll fix it later” appeared first on Bokardo. I was talking to a design team yesterday and one of the team members casually mentioned that they were launching something new. I took a quick look at what they were planning to launch and it was clear that something wasn’t quite right…there was a weird UI bug and some data looked off. So I pointed those things out and was told “Oh yeah, we know. We’re going to fix it later”. Those words, so subtle. I’ve said them many times. I’ve had the exact same attitude at a release. But the more I hear them the more I realize they’re deadly. Consider the negative effects they have: Your customers get a lower quality product. You know it and they know it, and so what are their expectations going forward? They’re going to be lower, and that’s a slippery slope you don’t want to start down. Release quality sets expectations. Almost as importantly you send the wrong signal to the product team. By putting out less than your very best product, you’re saying it’s OK to do less than your best work. This is poisonous. You might not see the effects in the short-term but the long-term effects of this sentiment cannot be understated. In effect you’re creating a culture where it’s OK to do mediocre work. You’re accruing product debt. No product team that I know of gets done a release and doesn’t have a whole list of things to work on next. There is always at least a backlog of next features to work on so it’s never as simple as fixing the things you couldn’t before release. And many, many times the small things that were released with the promise of being “fixed later” don’t actually get addressed at all…some issues never get fixed! I’m a big believer in the power of words and the words “we’ll fix it later”, while seemingly innocuous, are actually preventing you from releasing the very best product you can. So the next time you hear them push back hard and realize that if there is something worth fixing it’s always better to fix it before release rather than after. The real signal that you’re following this idea is when you actually delay a release because your product is not the best it can be for your customers. FYI: I’m writing a new book on how to communicate your product or service called Make them Care!. If you would like to be reminded when it comes out, sign up here. For an excerpt, check out Designing for the Next StepThe post The problem with “we’ll fix it later” appeared first on Bokardo. [...]



Growing from 10 to 100 to 1000 users

2014-11-12T15:03:50Z

Lots of folks I talk to about building products want to know how to grow from a tiny initial user base (10 people) up through 100 to 1000. It certainly seems like each of these stages is different, but it’s not clear why. I recently thought a lot about this when interviewed by Jay Acunzo […]

The post Growing from 10 to 100 to 1000 users appeared first on Bokardo.

(image)

Lots of folks I talk to about building products want to know how to grow from a tiny initial user base (10 people) up through 100 to 1000. It certainly seems like each of these stages is different, but it’s not clear why. I recently thought a lot about this when interviewed by Jay Acunzo of Nextview Ventures. My take is that the reason why these are fundamentally different stages is because of the relationship you have with these people…in short it comes down to bias:

“Initially when you start, you can talk to friends and get them excited about what you’re working on. These people are your co-workers, friends, and family so they’re easy to find and talk to. But they are also completely biased…”

We also touched on a lot of other topics like what features to build, when to focus on product vs. growth, etc. Here is the entire interview.


FYI: I’m writing a new book on how to communicate your product or service called Make them Care!. If you would like to be reminded when it comes out, sign up here. For an excerpt, check out Designing for the Next Step

The post Growing from 10 to 100 to 1000 users appeared first on Bokardo.

(image)



Great idea, poorly designed

2014-09-20T12:56:45Z

Rob Go of NextView Ventures makes a great point: saying “It’s been tried before” is a bad excuse to dismiss a product or startup. Rob says: “I’ve said those words before as well, both directly to entrepreneurs as well as in our internal conversations about companies. But I’m convinced that “it’s been tried before” is […] The post Great idea, poorly designed appeared first on Bokardo. Rob Go of NextView Ventures makes a great point: saying “It’s been tried before” is a bad excuse to dismiss a product or startup. Rob says: “I’ve said those words before as well, both directly to entrepreneurs as well as in our internal conversations about companies. But I’m convinced that “it’s been tried before” is a terrible way to dismiss a startup idea. The reason is that this statement allows you to be way too intellectually lazy. It essentially says “… I’m just going to assume it won’t work because others before it failed.” Rob says that there are two reasons for not dismissing companies like this: technology changes over time and most companies fail as a rule. I’ll add third reason to the list: Many ideas fail because of poor design. There are countless great ideas out there that never see the light of day because they have never truly been realized in a product. Take, for example, 95% of the mobile apps you’ve ever downloaded. A promise of a good idea got you to download it, you may have even been excited to download it, but when you actually used it it was disappointing. Design is hard. There are always constraints, trade-offs, and choosing which ones to hold to is extremely difficult especially in the startup environment where you just don’t have a lot of time. You’ve got investors and friends urging you to go faster, you’ve got customers who are asking for the world, and you’ve got your own pressure to be a success as fast as possible. Sometimes great design just takes time. Sometimes it takes looking at an existing market and redesigning it right. The entire Apple product line is a testament to this. MP3 players existed before the iPod. Mobile phones existed before the iPhone. And many digital watches existed before the iWatch. Apple is never first into a market, they are always late. They come in with great design and get an immediate foothold. Apple is just one example. Look at Slack and the communications apps. Look at Instagram and picture sharing apps. Look at WhatsApp and texting apps. Look at Sketch and the UI design apps. Look at Evernote and note-taking apps. Look at Dropbox and backup apps. Etc… All of these categories are littered with failed startups who created clunky, poorly designed user experiences while working on what turned out to be good ideas. Apple is different of course because they have time on their side…they can R&D as long as they want to be sure that their product is amazing at launch. This is the greatest benefit of having so much money in the bank…they can release products on their own schedule. Startups do not have this luxury. The big challenge for startups is time. Startups are under extreme pressure to make something work quickly. That’s why so much discussion about product development is about learning from customers and not wasting time marketing until you have product market fit…because until you do it means that your design is failing…even if you have a great idea. FYI: I’m writing a new book on how to communicate your product or service called Make them Care!. If you would like to be reminded when it comes out, sign up here. For an excerpt, check out Designing for the Next StepThe post Great idea, poorly designed appeared first on Bokardo. [...]



Three important points about listening to your customers

2014-09-10T13:50:36Z

Great list by Braden Kowitz on why you should listen to your customers: Several important points: 1) People love to say they talk to customers but rarely do. And some people talk to a couple customers, feel good about it, and assume their job is done. But the fact is that you have to go […]

The post Three important points about listening to your customers appeared first on Bokardo.

(image)

Great list by Braden Kowitz on why you should listen to your customers:

Several important points:

1) People love to say they talk to customers but rarely do. And some people talk to a couple customers, feel good about it, and assume their job is done. But the fact is that you have to go after feedback with a club. How do you know if you’re talking to your customers enough? Easy: You’re not surprised by what they say anymore.

2) Hiring a designer will not make you a design-first company. I’ve known lots of business owners who want to “get some design in here” by hiring a designer. This almost never works because that owner isn’t thinking about design in the right way. Being a design-first company means to actually change the process of product design to one that starts with users actual goals or a known problem and working outward. If you are hitting a wall and hoping a designer can get you out of it, it’s probably not going to work without a fundamental change to your product development process.

3) Customer research will actually speed you up. This is the most counter-intuitive one but is also true and probably the most important point Braden makes. Doing customer research seems like it will slow you down because it doesn’t feel forward-moving. You’re not actually building anything yet. But if you think about it as learning what to build then you can see how valuable it is.


FYI: I’m writing a new book on how to communicate your product or service called Make them Care!. If you would like to be reminded when it comes out, sign up here. For an excerpt, check out Designing for the Next Step

The post Three important points about listening to your customers appeared first on Bokardo.

(image)



Tips for doing Lean Research

2014-09-03T13:53:40Z

A nice set of notes here: The Right Way to Do Lean Research, curated from a discussion panel of several folks who really know their stuff: Christina Wodtke, Laura Klein, Todd Zaki-Warfel, and Mike Long. Right questions: Ask the right questions and save a tremendous amount of time by knowing what you want to learn […]

The post Tips for doing Lean Research appeared first on Bokardo.

(image)

A nice set of notes here: The Right Way to Do Lean Research, curated from a discussion panel of several folks who really know their stuff: Christina Wodtke, Laura Klein, Todd Zaki-Warfel, and Mike Long.

  • Right questions: Ask the right questions and save a tremendous amount of time by knowing what you want to learn before doing research.
  • Right people: Talk to the right people about your product: the people would actually pay for it.
  • Right test: The research method you choose depends on what you want to learn and where you are in the product development process.
  • Right place: You try to put yourself in the right place to do the best research on the budget you have…whether you’re in or out of the office.
  • Right attitude: Having the right attitude when doing research is extremely important…are you really in a listening mode or are you selling?
  • Right documentation: Doing a bunch of research is valuable but you can quickly lose important insights if you don’t record everything well.

FYI: I’m writing a new book on how to communicate your product or service called Make them Care!. If you would like to be reminded when it comes out, sign up here. For an excerpt, check out Designing for the Next Step

The post Tips for doing Lean Research appeared first on Bokardo.

(image)



How architecture can inform UI design

2014-09-08T13:13:49Z

It is said that all designers wished they were architects…or something like that. Over at the Percolate blog former architect Melissa Mandelbaum has written Applying Architecture to Product Design: Lesson 1 in which she points out the architectural principle of circulation is pretty much the same thing as navigation in UI design. Mandelbaum writes: “The […] The post How architecture can inform UI design appeared first on Bokardo. It is said that all designers wished they were architects…or something like that. Over at the Percolate blog former architect Melissa Mandelbaum has written Applying Architecture to Product Design: Lesson 1 in which she points out the architectural principle of circulation is pretty much the same thing as navigation in UI design. Mandelbaum writes: “The circulation of buildings not only affects your perception of them, but also your usage and behavior within them. Continuing the apartment example, stairs would likely lead you to go home less frequently than you would if you had an elevator in the building. The presence of an elevator would likely lead you to carry home bigger, heavier items. The lesson learned is that we make a lot of choices based on available circulation systems.” I think about the commonalities between virtual and physical spaces and the movement between them a lot. One of the big differences is that in virtual space we conceptually move around (as opposed to physically move around). So when a user moves we as designers need to change the conceptual space, so to speak, so that it’s clear they’ve changed “places”. Tabs for navigation often do this well, but sometimes they don’t work in cases like when someone wants to deep link within one tab to another. And often times it’s enough to use copywriting to do the conceptual change, like when you change nouns and verb tense to suggest that something has happened. In this way UI elements are doing the same thing as physical elements of design…opening passageways, blocking people, suggesting routes, slowing and speeding people up, etc. It’s a never ending problem that I find fascinating. I’m looking forward to the other installments of Mandelbaum’s series. FYI: I’m writing a new book on how to communicate your product or service called Make them Care!. If you would like to be reminded when it comes out, sign up here. For an excerpt, check out Designing for the Next StepThe post How architecture can inform UI design appeared first on Bokardo. [...]



Why Apple doesn’t do MVPs

2014-09-02T16:19:02Z

The Biggest Lesson I Learned as an Apple Designer is a thoughtful piece that pushes back on the standard advice given out today of creating an MVP (minimum viable product) and learning as you go. It comes from a former Apple designer, Mark Kawano (who also wrote about Apple’s design culture), and suggests that MVPs […] The post Why Apple doesn’t do MVPs appeared first on Bokardo. The Biggest Lesson I Learned as an Apple Designer is a thoughtful piece that pushes back on the standard advice given out today of creating an MVP (minimum viable product) and learning as you go. It comes from a former Apple designer, Mark Kawano (who also wrote about Apple’s design culture), and suggests that MVPs just don’t make sense within the Apple process. Instead of “launching and learning”, Apple waits until their products are much more mature and offer a more complete experience: “Waiting to launch a product until its “magical” moment goes against the concept of MVP, or minimum viable product, which has become so trendy in business over the past few years. It’s part of the lean startup mentality that became mainstream with Eric Ries’s best-selling book, The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses The idea goes something like this: Build a product to the point at which it’s good enough, launch it quickly into the marketplace, and then make iterations as you go while learning from your customers. Though there is wisdom in Ries’s ideas, entrepreneurs need to be very careful in their interpretation of what a minimum viable product actually is. If you’re launching something in a space where there are a lot of people trying to do something similar–for example, a consumer product–then the bar for MVP should be ridiculously high. I think the pendulum has swung too far toward the “launch to learn” end of the spectrum of product releases. You can and should learn a lot before you launch. Frankly, many of the pieces of software that I love best have not been built in a launch and learn environment and instead were refined internally by a thoughtful and critical team of designers. That’s not to say that the products aren’t iterated on, all products are, but they aren’t iterated and released continuously in public for the means of “learning”. Now I’m sure you’re thinking “but Apple is Apple and nobody else is”. Yes, that’s true, but consider that this is just another process, albeit a different one. At Apple they have internal checks-and-balances about when to launch a product or not, and it stands in stark contrast to the lean approach. That’s what I find interesting here, and I think there are merits to both processes. At the very least, the definition of “viable” should change depending on the maturity of competing software. FYI: I’m writing a new book on how to communicate your product or service called Make them Care!. If you would like to be reminded when it comes out, sign up here. For an excerpt, check out Designing for the Next StepThe post Why Apple doesn’t do MVPs appeared first on Bokardo. [...]



Secret, you keep using that word…

2014-08-28T14:16:27Z

After calling the app “Secret”, letting everyone who uses it think it’s secret, the founder of Secret now acknowledges that the information you submit is not, in fact, secret: “The thing we try to help people acknowledge is that anonymous doesn’t mean untraceable,” David Byttow, chief executive and co-founder of the Secret, told Wired in […]

The post Secret, you keep using that word… appeared first on Bokardo.

(image)

After calling the app “Secret”, letting everyone who uses it think it’s secret, the founder of Secret now acknowledges that the information you submit is not, in fact, secret:

“The thing we try to help people acknowledge is that anonymous doesn’t mean untraceable,” David Byttow, chief executive and co-founder of the Secret, told Wired in an interview this week. “We do not say that you will be completely safe at all times and be completely anonymous.”

I used Secret for a day, submitted one “secret”, realized it’s not good mojo and then assumed that in fact everything was traceable like everything else that’s digital, and so “deleted” my account. Who knows if it was really deleted.

Make no mistake…Secret is one of the darkest of the dark patterns.


FYI: I’m writing a new book on how to communicate your product or service called Make them Care!. If you would like to be reminded when it comes out, sign up here. For an excerpt, check out Designing for the Next Step

The post Secret, you keep using that word… appeared first on Bokardo.

(image)



Is your product a Hafta or Wanna?

2014-08-22T14:55:58Z

In his insightful article, Why Behavior Change Apps Don’t Work, Nir Eyal brings up a crucial point about the habits we form (or fail to form) around the products we use. “Unfortunately, too many well-intentioned products fail because they feel like “haftas,” things people are obligated to do, as opposed to things they “wanna” do. […] The post Is your product a Hafta or Wanna? appeared first on Bokardo. In his insightful article, Why Behavior Change Apps Don’t Work, Nir Eyal brings up a crucial point about the habits we form (or fail to form) around the products we use. “Unfortunately, too many well-intentioned products fail because they feel like “haftas,” things people are obligated to do, as opposed to things they “wanna” do. Schell points to neuroscience research showing “there are different channels in the brain for seeking positive consequences and avoiding negative consequences.” When faced with “haftas,” our brains register them as punishments so we take shortcuts, cheat, skip-out, or in the case of many apps or websites, uninstall them or click away in order to escape the discomfort of feeling controlled. I think this explains a lot about products in general, and specifically why app categories like todo list apps mostly go unused…they inevitably end up feeling like “haftas”. I distinctly remember that feeling the first time I used a todo list (Remember the Milk) that carried over undone todo items from one day to the next. At first it seems like a thoughtful touch…to automatically bring items from one day to the next. But after a day or two it becomes a burden…your list grows and grows because other tasks inevitably crop up during the day. It quickly became a management situation…I had to manage my todos rather than just keeping light track of them. It turned my todo list from a wanna to a hafta. Note that any product person would love their product to become a “hafta”. That’s the lock-in you want…that your product is so valuable that it becomes something that people feel like they have to use to be successful. That’s why this is counter-intuitive and important. You want the product to be a “hafta” but feel like a “wanna”…to have your product be essential to their daily use while following the important design principle: keeping people in control. Nir sums this up nicely: “When our autonomy is threatened, we feel constrained by our lack of choices and often rebel against doing the new behavior. Psychologists call this “reactance.”” So people don’t resist a new behavior just because it’s hard to do (in fact new behaviors are often easy to do) It may be more about autonomy…by forcing a new behavior on people we suggest to them that they have less control over the situation than they had previously, creating a “hafta” situation where there was none previously. Read the whole thing: Why Behavior Change Apps Don’t Work FYI: I’m writing a new book on how to communicate your product or service called Make them Care!. If you would like to be reminded when it comes out, sign up here. For an excerpt, check out Designing for the Next StepThe post Is your product a Hafta or Wanna? appeared first on Bokardo. [...]



Go after feedback with a club

2014-08-16T15:05:45Z

Jack London, the author of The Call of the Wild, was talking about writing when he said “You can’t wait for inspiration. You have to go after it with a club.” The product design equivalent is: You can’t wait for feedback. You have to go after it with a club. If you’re waiting for feedback, […]

The post Go after feedback with a club appeared first on Bokardo.

(image)

Jack London, the author of The Call of the Wild, was talking about writing when he said “You can’t wait for inspiration. You have to go after it with a club.”

The product design equivalent is:

You can’t wait for feedback. You have to go after it with a club.

If you’re waiting for feedback, you’re only going to get 5% of it…as only a tiny proportion of people reach out unsolicited. It’s the hard conversations you need to have…like with your friends who don’t want to tell you the truth, that you need to hear.

Example: recently I was talking with a friend about how they use What to Wear and it occurred to me that her use had actually fallen off and so I asked why. Her response was interesting…something I could immediately fix (and subsequently did fix). I asked why she didn’t tell me and she said “I didn’t want to make you mad”.

Wow…I was floored. I couldn’t believe my friend had suppressed the most important feedback I needed to hear just so she wouldn’t hurt my feelings. I told her that I was actually more upset she didn’t tell me and that I want more than anything real, honest feedback about what’s working and what isn’t working. I can fix anything that’s wrong with the product…but I need to know about it! So that was an extremely important lesson for me to learn…I’ve got to go after feedback with a club.


FYI: I’m writing a new book on how to communicate your product or service called Make them Care!. If you would like to be reminded when it comes out, sign up here. For an excerpt, check out Designing for the Next Step

The post Go after feedback with a club appeared first on Bokardo.

(image)