Hey there - we’re Hipmob. We help you communicate with your mobile customers and provide amazing marketing and customer support. You can learn more here.
In our first interview with a software services/Saas company, we talked to Ryan Singer, Product Manager at 37Signals. Ryan writes about user interface and product design at feltpresence.com - it’s worth a read.
Ryan drove the development of the official Basecamp iPhone app, the iPhone app for 37Signals’ popular project management and online collaboration software. Our discussion turned out to be more philosophical than usual, as Ryan shared an interesting & unique perspective. As such, we’re presenting it in QA format. It gives some insight into the design thinking behind the official Basecamp iPhone app, as well as Ryan’s approach to designing for mobile, and a bit about how 37Signals is approaching mobile. The transcript has been edited for length and clarity.
Designing Your App To Do A Job
Ryan: We waited a long time to do a proper iPhone app for Basecamp. We didn’t want to start until we had a real concept of “what is this app" on its own terms. A lot of third parties built Basecamp iPhone apps, and the intention behind their design was to give access to everything.
If you give equal consideration to every feature and build a hierarchical drill down system that can access everything, then what’s the main purpose of the app? Whats the job?
We decided that the app should be a source of news. You’d pull your phone out and check to see progress on the project(s) you’re working on; did anybody post anything new, is there anything new to look at, is there any progress on the project that I’m managing, or did anyone answer this important question that I had?
Once we decided to orient the whole design around streams of events, the whole app concept clicked into place, because it had a structure about what was the main thing vs. the side thing. Initially, we didn’t know if our customers would feel the same way. Now, I do have the impression from the appstore reviews and from speaking to customers since we released it that we made the right bet.
Streams of events
From Web -> Native
Q: How actively are you developing the app? Are you thinking of extending the Basecamp app or of applying the same philosophy to other 37Signals apps?
Ryan: We have all kinds of ideas, but I’m mostly interested in “Where are the glaring omissions?”, and the calendar is on the top of my list for that right now. Besides that, we built the Basecamp iPhone app in Rubymotion and it’s mainly made out of webviews. I’ve made it a priority for us to learn native app development, to get more comfortable with Objective C, and to step out of our comfort zone. Rubymotion and webviews are fully inside of our comfort zone, but it’s going to be a constraint on how innovative we can be. So I have a number of projects that I’m working on starting up; some of them are in progress, some of them are coming next, where we’re doing things that are completely native, and we’re also building them out in Objective-C, so that we kind of dive head first into that world, and develop that capability in house.
Q: So the decision to go with webviews for the first app was driven by just staying in your comfort zone and getting it done quickly?
Ryan: We saw too much value in getting the app to customers. It wasn’t worth delaying release in order to do a lot of R&D, when we saw a way to accomplish our goal. I’m happy with the results, and I’m hearing that customers are happy with the results, so it was a win. But now the question is 'Well what next? Are we going to keep going for marginal wins like that where we get the most bang out of the smallest buck?’ If we keep doing that, we’re going to be moving in small increments, and get caught at a local maxima. We wont be able to make a major leap into something else if we keep doing that, so that’s why we shipped it, but now I’m trying to put more energy into doing things that are more new for us.
Putting Customers First
Q: What has surprised you as you’ve released and gotten feedback? What are some things that you didn’t expect to happen that ended up happening (or vice versa)?
Ryan: We made, I made a mistake, actually, when I was planning the design and release of the app. We have two versions of Basecamp - we have Basecamp Classic, and we have a new version of Basecamp; a separate app that we released in 2012. We had it in our minds that this app was just going to be for the new Basecamp. And we kind of took that as a decision and then built it, but I neglected to think about the fact that a lot of our customers are still on Classic, and they’re going to hear about this app, or they’re going to search for it on the AppStore, and whether it has a little “asterisk” on it that says “Doesn’t work for classic” or not, people just think that they have Basecamp, and a lot of people who’ve been happily using Classic for years, may not even know or care that there’s a new version, they still think that they’re using Basecamp. What actually happened was, we didn’t take care of explaining that properly or addressing it properly, and we ended up with a lot of unhappy classic customers, who were trying out the app and it didn’t work, and then they were posting really negative AppStore reviews. So our AppStore score was very low for a while - 2 stars or something like that. We ended up kind of hacking in classic support, which I’m still not totally sure what I think about, but either way we did it.
Basecamp Classic Now Supported
The other thing we did was, we put in a “Rate This App” nag, and that really helped us out, because it turned out that there were lots of people who were really happy with the app, but who just weren’t rating it. After we put the prompt in, we saw a very nice bump in ratings from people who were really using it and enjoying the app, and since then we’ve been above 4 stars consistently.
Basecamp Appstore Ratings
AppStore Reviews As A Primary Source Of Feedback
Q: Was there a reason you didn’t have any other avenue for feedback or it just wasn’t a priority?
Ryan: I didn’t really know what else to do. I suppose we could have had some sort of email us or feedback button inside the app; I’ve seen some posts online that suggest that your app should have some sort of talk to us button as a way to capture peoples frustrations. However, in terms of my own personal style, I have an aversion to putting something like that prominently in the app interface, because I think the interface should be about the work you’re trying to do, and not about the communication with the developer. Thats just a personal decision; I would really just rather not go there if I can avoid it. I’m just inclined to try and use the channels that we’re already seeing people use and then just improve it there first before we do something else. So we were getting the feedback on the AppStore - we were getting the message, so I said lets do our best to address that based on the feedback that we have, and I think we saw a decent turnaround based on that.
It’s one thing to put an email button somewhere, but its another thing to take that feedback and act on it. You can’t just divert that to support because their role is to solve people’s problems - they’re not really a channel for product direction feedback. We’ve learned that over the years we haven’t done very well with turning feedback sent to support into product changes. We’ve done it, and we do it when it becomes really clearly important but it really needs to reach a high level of criticality before it bubbles up from support into product. That’s something that I’m aware is a sort of weakness in our organization right now, so I wouldnt want to put more product feedback into that channel because it’s not the right channel, and I don’t feel like I have the time or the headspace to create a new channel and to put a new system for a feebdack into action, while somethign like the AppStore review is already working.
Immersing In Mobile
Q: What else is important in this area that you’re thinking about that we haven’t discussed?
Ryan: The biggest challenge for a company like ours is to change our way of thinking because, we grew up when the web was just a laptop thing. We learned on laptops and we defined our notion of what software is on laptops and desktops, and it’s really changing. The degree to which consumption is moving away from laptops to mobile devices is incredible. One of the biggest challegnes for me is to really immerse myself in it and make it part of my own experience so I understand it.
Challenge number 1 is to actually experience it, because it would be very easy for us to do what we’ve always done, while the rest of the world moves on.
My way of immersing is this:
'I don’t open my laptop until I have to every day. When I start my day, I start it on my phone and my iPad, and I try to do the things I need to do, as much as I can on those devices. So I'm using the Campfire app on my iPhone to check in and talk to everybody at work over coffee this morning, and then I'm on the iPad and I'm looking at Basecamp projects and responding to things.'
I’m actively trying to stretch, to see how much can I do on these [devices]. I’m also watching for new apps that are coming out; seeing who is doing things well, and I have a couple of ideas I’m working on, with the phone or the tablet as the starting point, instead of thinking that first we’re going to do the web app, and then we’ll do a mobile version, it’s more like; whats the situation that I’m in where I’m using this device, and then how can I use that as my starting point.
The second thing is that once I have a clear idea (or whoever else is doing it at the company has a clear idea for what we should do), getting the company to a point where we could implement it is another thing. Learning a language is not hard, it’s more about being able to think in terms of the APIs that Apple gives you and having this sort of muscle memory about what is possible and what you could put together. Thats the other part of the challenge right now; picking off projects that are going to teach us, where we’re learning things and getting more comfortable with the design and development process on these devices. I think as far as product design, it’s not really any different - it’s just a different starting point with some different constraints. As far as deciding to start there and then developing the capability in house, those are the bigger challenges right now.
The Trouble With Android
Q: One thing I’ve noticed you not mention at all is Android - what do you guys think about that? Are you doing anything in Android? Are you seeing activity in Android at all?
Ryan: It’s one of these things where, I think depending on your own personality, that affects how you answer this. Just the way that I operate - even if I see data that tells me that something is real, like even if there was data telling me that there are tons of people on Android and tons of people trying to use it - if it’s just data and it’s not an experience for me, then I don’t find it very interesting. On paper I can see an argument for us doing Android work, but I’m not personally motivated. My way of dealing with that is that I try to keep the door open to anybody in the company who is using Android - if one of those folks feel like there’s something missing in Android or there’s an opportunity because we’re not there, then I would like to see them lead because they’re the ones who live in that world and understand it, and feel it in their hearts and so on. Versus me trying to lead something on Android because "we should do it, because the numbers say so".
Thanks to Ryan for sharing the Basecamp story. You can see more about his work at http://feltpresence.com/