Episode Transcript

Ethan:

Hi, this is a responsive web design podcast, where we interview the people who make responsive designs happen. I’m your host, Ethan Marcotte.

Karen:

And I’m your other host, Karen McGrane.

Ethan:

And this week we are positively overflowing with delight to speak with Sophie Shepherd and Brandon Rosage from Ushahidi. Guys, thanks so much for joining us.

Sophie:

Thank you guys.

Brandon:

No problem.

SMS is just a huge deal in the developing world, as a lot of us know, and so opening up the lines of communication and letting anybody participate in storytelling has been a big part of what Ushahidi does.

Ethan:

Sophie, Brandon, why don’t you guys tell us a little bit more about Ushahidi and tell us a little bit about what you’ve been working on.

Brandon:

Ushahidi is a nonprofit company that was born out of a crisis in Kenya, in Eastern Africa, in 2008 when things got violent in the wake of their elections. So, a group of bloggers actually threw together a PHP website to collect text messages and reports through the website and map them so that people on the ground, or really just anybody living in the area, could get a real time crowdsourced sense of what was going on. Out of that has come an open source application built on the same spirit, and then a number of other applications that solve similar problems but in different ways. SMS is just a huge deal in the developing world, as a lot of us know, and so opening up the lines of communication and letting anybody participate in storytelling has been a big part of what Ushahidi does.

It’s grown over the years from just a few bloggers to twenty people a couple of years ago, to fifty today, which really accounts for organizations that have spun out of Ushahidi—a hardware company called Brick at Brick.com that does rugged routers that use cellular data and everything; initiatives that fund other people who have ideas for innovating in their community. It’s a far-reaching company today but it lands about fifty people.

Ethan:

Sophie, tell us a little bit about what you do there.

Sophie:

I am relatively new, I started a few months ago. I’m working as a senior designer. So far in my time here, I’ve been specifically been working on v3, which is the third iteration of the main platform, known as the Ushahidi platform. So, this is what was created originally, there was a v2, and now v3 is going to be a similar thing where it collects data and people can submit things. It’s just modernized and has a lot more functionality than it ever did in the previous versions. I’ve been working on the design with Brandon and then also building out the front-end for that.

It was a practical way of efficiently using our small team and our small resources to work on all devices.

Ethan:

That’s fantastic. Tell me a little bit more about the decision to go responsive. How did you convince the stakeholders and some of the business owners at Ushahidi that this was the right way to go? Related to that, were there any questions or concerns about responsive design when you were having those discussions?

Brandon:

Ushahidi started building its products and designing in a responsive way about two or so years ago. There really wasn’t a selling of that approach that needed to happen internally. For Ushahidi, it was a desire to reach as many people as possible. While that may have meant “We want native apps,” as I mentioned that story coming out of 2008, the proficiency and the expertise of the team was very web-focused and so that was the most efficient way to reach as many people as we could without hiring a bunch of Android and iOS developers. It was a practical way of efficiently using our small team and our small resources to work on all devices.

The design approach, where we haven’t even really written much code yet, has been difficult because it’s a very engineering-focused company traditionally, although less so today. So, this notion of thinking small screen first has been tougher. But there hasn’t really been much of an internal sales process. I’ve been with the company for a little bit longer and I’d actually be a little interested to hear what Sophie’s experience has been in trying to work her process in.

Here, I think it’s just a given that there isn’t really another option because of the way people use this product and the accessibility that they need to have to it.

Sophie:

For clients, which is what I worked with in the past, there was a little more selling that we had to do with responsive because they were balancing costs. Whereas here, I think it’s just a given that there isn’t really another option because of the way people use this product and the accessibility that they need to have to it.

Brandon:

There’s also a lot of autonomy in every group. Developers, to a fault—and designers too—pick the approach that we’re either most interested in or feel the most strongly about at that time. I say it’s to a fault, but there’s benefits to it as well. If the folks that are doing the design process and even the front-end implementation of that value it, there’s not a lot of concern about “Well, what are they going to say down the line?” There’s just a general respect within the company for the decisions that came before. Again, there’s an upside and a downside to that, but it’s worked for our responsive web design anyway.

For us as making promises as designers, the big part of scoping it and offering accurate estimates has been to set down some rules from the beginning—or at least expectations.

Karen:

When you were thinking about planning this responsive design, how did you scope the first project? How did you know how long it was going to take, and how much it was going to cost, and where some of the risks might be in planning the project?

Brandon:

With the platform, the project is really the focus of both Sophie’s and my time today. Because of the history and that this is the third version now, scoping it has actually been very difficult, even aside from just budgeting design time. For us as making promises as designers, the big part of scoping it and offering accurate estimates has been to set down some rules from the beginning—or at least expectations—and one of the big ones that has helped is getting out of graphic design applications very, very early so that there’s less time spent communicating over email, or over Skype, or what have you about “Look at this picture of what we’re doing and now imagine it this way,” and instead saying “You’re going to know what this design is by feeling it.” That offers a little bit more time. I think both Sophie’s and my experience with client work is “Well, if there’s a design phase that includes graphics, we can expect to see graphics in a week or two weeks.”

Setting expectations with the approach and what that’s going to mean for the tools we use and how we communicate our design decisions has made a big difference in making everybody happy and keeping things running smoothly.

Sophie:

“And we need to approve those before you can do anything else.” We don’t have that anymore.

Brandon:

And by saying “You know what, the first time you guys touch this or see this, it’s going to be in the browser,” I think that immediately is welcomed with “Alright, you guys are going to need a month or so to work that out.” This is different than client work, it’s not like down to the hour. But I think setting expectations with the approach and what that’s going to mean for the tools we use and how we communicate our design decisions has made a big difference in making everybody happy and keeping things running smoothly.

Sophie:

We’ve also pulled out a lot of the design in front-end from the back-end, so we’re building it completely separately on two parallel tracks. While a lot of the back-end developers are working on building that side of things, we’re building a pattern library that, at some point in the future, will get merged together. But by keeping that separate, we’re not holding each other up. We can just work as we see fit and then figure out a good time to meet in the middle.

I’ve started—and I think this is a result of doing more front-end code—to think small and build out from there.

Ethan:

Sophie, I really enjoyed your article about that pattern library and using it and style guides as a design tool. Could you guys talk more broadly about how your design process has changed over the last couple of years? Not just the applications and tools you use, but how you think about beginning a design when you’re thinking responsively.

Sophie:

I’ve started—and I think this is a result of doing more front-end code—to think small and build out from there. So, designing certain elements of the page and thinking about layouts, rather than in the past where I would probably design a layout and then design another one that would match visually but I’m not really thinking about the little elements that make that layout. By thinking in that way, we’re able to move into code much faster. As Brandon was saying, we’re still using Photoshop to design some things but at this point we probably have about sixty percent of the pages designed, but within that maybe eighty percent of the elements for them. From here, we can just do anything that’s left over using the elements that have already been design and coded, and then we can build out pages from there.

Within Ushahidi, the pattern library, it’s also become a powerful communication tool all the way up to folks who aren’t thinking about code or anything.

Brandon:

Within Ushahidi, the pattern library, while it serves many functions, including what Sophie alluded to earlier about it being a workflow thing and a framework for thinking about it, it’s also become a powerful communication tool all the way up to folks who aren’t thinking about code or anything, who are just project management or even sales roles. It’s a great tool for them to show progress, to give people a sense for the system that’s being built. The internally of course I think it’s been great. When a developer asks “How is this view?” which we haven’t even built, and by view I mean what the entire picture is going to look like in the browser, “How’s that going to work?” Rather than saying “Oh, let me mock it up” or “let me build the whole thing,” we can say “This pattern A, and pattern B, and pattern C, they’ll fit together in such a way” and put these building blocks together. It’s just so much more efficient and intuitive than for the follow-up questions, the “What about this view?”

Sophie:

Going back to the scope question, it makes communicating a lot faster. So, because we now have this tool to use, it’s easier to estimate how long things will take to communicate.

It’s in one place and if you update one pattern, then that will get updated throughout the entire platform for anyone who’s using it.

Ethan:

How do you guys manage revisions to the pattern library over time? Obviously the Ushahidi platform has undergone a couple of revisions now. Now that you have this pattern library, do things need to be reworked after release? How do you actually manage and track that process?

Sophie:

It’s going to be great because we have this one central place where we can revise things. We haven’t done any large public releases of versions yet with this, but I’d guess that we’ll tag things in GitHub so that if you wanted to look back at past versions, you could. But ideally, there’s going to be, and always will be, one pattern library and that’s the latest, and there aren’t mock-ups that need to get updated and there isn’t documentation elsewhere—it’s in one place and if you update one pattern, then that will get updated throughout the entire platform for anyone who’s using it.

Brandon:

Sophie’s hinting at two strategic aspects to having the pattern library abstracted from the app itself, which is what she just said, where you have an environment in which to work with the presentation of the app. So, if somebody wants to “theme” their version, their website that uses the platform, they can have an environment to do that and then drag and drop those assets, meaning style sheets and JavaScript and what have you—drag them back into the client and it mostly just works. The other one is that going forward if the developers want to change frameworks—go to Ruby, go to Ember, Angular, whatever changes they make—the front-end is so agnostic to all that that they’re not liabilities to one another. I’m pretty confident that’s going to work and I think it’s worked thus far as they’ve run parallel together. So, we feel good about it.

I feel very lucky in this position because in the past a lot of reviews were with clients and now it feels like our clients are our users.

Karen:

How do you manage reviews with the team or with other stakeholders or constituents? How do you communicate with them about how the responsive platform works, how the pattern library works, or how things work at different breakpoints? Are there any challenges in communicating with the outside group?

Sophie:

I feel very lucky in this position because in the past a lot of reviews were with clients and now it feels like our clients are our users, and there are a lot of different types of users out there and we’re in the process actually this week of testing the designs for the first time. So, we do internal reviews but we’re all fairly on the same page about how things should work and I guess we’ll see from here on out how users are responding to this stuff. Also, since this is open source, we get feedback all the time of users of v2 requesting certain functionality in v3, which for me is really cool that there are people invested who want to see this become a lot better.

Having the open review at a public URL has had enormous benefits.

Brandon:

To underscore too the pattern library’s role in review: because reviews in client work often tend to be screensharing, a little bit of a presentation, and a walkthrough where everybody is seeing the same thing, which has its benefit, but they’re seeing it as it pertains to responsive, at whatever screen size and what have you.

It forces us to be good about documentation, which is a good habit to get into and only strengthens the work that we’re doing.

Whereas at Ushahidi, a lot of solicited feedback is “Here’s a URL to the pattern library and some layouts to check out,” and then they see it in whatever environment that they happen to choose, on their phone or anything, it’s at a public URL. So, we do get a much more thorough round of “This isn’t working for me” or “why did you make that decision?” from all kinds of situations. Having the open review at a public URL has had enormous benefits.

Sophie:

A lot of the time we don’t get to present things to people, which is difficult because I enjoy presenting work to people. But at the same time, it forces us to be good about documentation, which is a good habit to get into and only strengthens the work that we’re doing.

How can we think about the path that that SMS message follows from this user’s phone into this visualization? It’s tough, but I think it’s made the app much stronger.

Ethan:

One of the reasons I’ve been so excited to have you guys on the podcast is something that’s been interesting me over the last couple of years is thinking about mobile through the lens of less developed markets and thinking about designing in adverse network conditions. How, if at all, has working at Ushahidi changed the way you think about the quality of the design that’s being delivered to different classes of browsers? How do you find support for the experience that you’re actually designing?

Brandon:

That’s actually been a struggle. It’s an unresolved thing at Ushahidi because on the one hand we’re so familiar and close to those constraints, and yet, something that’s a hot debate in our industry, the platform is being built with a front-end JavaScript framework that has its liabilities and is slow, and you know without JavaScript you don’t get anything. So it continues to be a struggle.

I think where it’s impacted design decisions really positively and interestingly for me is how people get information into it. It’s really easy when we’re going through a UI and the flow of “People of course make this assumption, of course people are going to see our beautiful website, and there’s where they’re going to enter this information using this beautiful experience we’ve provided.” But being reminded again and again that not only in 2008 when this app was first built in v1 but today an overwhelming amount of user-generated content for the Ushahidi platform is going to come from an SMS message, and we’re only going to maybe their phone number and it’s not going to be structured and it’s going to have all these constraints. So, how can we think about the path that that SMS message follows from this user’s phone into this visualization? It’s tough, but I think it’s made the app much stronger.

But with this it feels very kind of life or death, and we’re really providing something important for people where it can really, really make a difference.

Ethan:

You mentioned the JavaScript potential liability. Have you had conversations internally about performance in general? Sophie, I know we have a colleague, Yesenia Perez-Cruz, who’s been doing a lot of work around using performance as a design tool. Is that a conversation that started at Ushahidi?

Sophie:

We’re somewhat lucky in that by default, other than these JavaScript issues, it’s a fairly light site. It’s not image heavy and we’re coding it as much as we can in a way that allows it to be that way, so we’re continuously testing it to make sure it doesn’t go off the deep end. For me, a lot of the things that I’ve been thinking about are more, as Brandon was talking about, in design as well as performance. But these are people who are in a situation where they maybe don’t have a lot of time to submit things and to find what they’re looking for on the site, and how do we work with that?

Brandon:

With this product in particular, Sophie and I live here in Austin, we’ve got a colleague and a bunch of people in for SXSW, and for the first time, at least during what you might call the design phase of a project, we have a day dedicated to exactly that—a performance audit. What we want to get to is a budget. “We can’t exceed this number of HTTP requests and this much page weight.” We’re not quite there, but with this product, with the platform, I think for the first time it’s very much a requirement.

But there’s a good chunk, if not half of the team, that lives in Kenya every day and will tell us “Well, this blows.” So, that’s nice—well “nice,” but it actually sucks.

Sophie:

Yeah, I like it because in the past we’ve worked on projects with performance budgets but they’ve always felt a little bit arbitrary. It’s been like “This person should be able to read this not-crucial article really fast,” but it’s more so we can pat ourselves on the back and so a few people don’t drop off. But with this it feels very kind of life or death, and we’re really providing something important for people where it can really, really make a difference. So, I feel definitely more motivated with this one than I have in the past on other projects.

Brandon:

It’s funny, we all just spent a week at the beginning of February in Kenya together, and a few of our products had the goal of “Let’s actually dogfood it and use it for some of the stuff we’re doing together,” and there were some epic failures. And it’s awesome, because it’s not just like “Oh, well I did a diagnostic test and it failed my…” It’s like you have actually felt the frustration of “This app is not good enough because I don’t even want to use it.” So, that kind of stuff, being there, which for us is only a week or a couple of weeks a year on our iPhones… But there’s a good chunk, if not half of the team, that lives in Kenya every day and will tell us “Well, this blows.” So, that’s nice—well “nice,” but it actually sucks. [Laughs]

Sophie:

It’s helpful.

A measurement for success is the majority of users on small screen devices, or let’s just say devices where the user can choose between their native app and the web client, actually choosing the web client.

Karen:

How do you measure the success of this responsive redesign or the success of this platform? What kind of metrics do you have in place to know whether or not it’s working?

Brandon:

For one of them the platform is API-First as an app, there’s a web client which has traditionally been a big focus, but there’s also an Android and iOS client. For us internally, if the native client is Android and iOS, the functionality is much more limited and constrained—things like configuring and customizing and managing users. A big part of this product is not just taking in user’s content but processing it. As a really quick use case, if I’m running a website, or a deployment as we call it, I get antenna SMS messages, it’s not just going to go up on a map. I might need to call the police and verify that that happened, I might need to translate it into English, these type of things. Right now, the best and maybe only way to do that kind of processing is in the web client.

A measurement for success is the majority of users on small screen devices, or let’s just say devices where the user can choose between their native app and the web client, actually choosing the web client. Up to v3, there was very little usage on small screen browsers and I think it’s because it’s just a lousy experience and they don’t have all the capabilities. It’s just easier to manage their stuff in those native apps. I think that would be a big victory if people actually got the power and got things done that you can do on the web client on their phones. That’s not to say that they use their phones more than desktop, it’s not about browser usage, but just if you’re on a small device, how do you manage your deployment.

This is the first time that I’ve really worked with this pattern library-first concept, and I’ve been finding over and over again that it’s saving me a lot of time.

Ethan:

Given the work that you’ve done at Ushahidi, do you have any advice for other organizations who are listening to this podcast and who are thinking about going responsive? What are some of the lessons you guys have learned?

Sophie:

For me, this is the first time that I’ve really worked with this pattern library-first concept, and I’ve been finding over and over again that it’s saving me a lot of time. I thought at first that maybe it would, if not take longer, at least be equal in terms of time and effort. We knew it was going to work well, but I think that as we’ve been actually doing it in practice, we’ve found all of these other positives that we didn’t predict would be there. We had a conversation about theme recently because it came up a little up a little later after the design had begun that people may want to have themes for their deployment and users may need to be able to choose themes. That was kind of a big thing to drop on a designer because it changes everything. But then we were like “Oh, they can just use the pattern library and take that repo and change a couple of variables and that’s a theme.” So, it’s things like that that over and over again we’ve been noticing the efficiency of it.

It’s okay to let go of that fancy animation that you had in your head. It’s okay if there’s no parallax or anything, because it’s more important that it be super fast.

Brandon:

Yeah, that’s a great one. Another one for me is outside of the context of Ushahidi, I’ve always had a sense that all of the rethinking we’ve done about what web design is, as responsive web design becomes more clearly synonymous with just web design, is that web design may not be as whizbangy and super animated and splashy and fancy because it has to work in so many different contexts. And that that is okay. I’ve struggled with it outside of the context of Ushahidi because—back to the “Well, my iPhone on LTE—I demand these things!” So, it’s very easy as a company to be like “This is going to be splashy and sexy and we’re going to put a lot of energy into our website, and there’s all kinds of JavaScript solutions and we’ll get there, so let’s not give up.”

It forces you to really think through every single decision you’ve made, which in the end will make for a much stronger product.

Inside of the context of Ushahidi, my sense has been a little bit validated because there’s already a built-in sensitivity and empathy for constraints on the web, and a web experience that’s all ready from the get go by virtue of their device and their connectivity, hard to even take advantage of that experience that you’ve spent so much time sweating over on your iPhone in an LTE network. That’s not for me to say that you should assume much greater constraints. I think those are great goals but I think there’s a certain amount of embracing, at least in web design, that we can and probably should do. It’s okay to let go of that fancy animation that you had in your head. It’s okay if there’s no parallax or anything, because it’s more important that it be super fast. It’s going to be worth it when people actually choose your website over your native app.

Sophie:

I’ve never worked on a project that has more constraints than this. If you had told me that a year or two ago, I would have been like “Nope, I’m out.” But I think that it forces you to really think through every single decision you’ve made, which in the end will make for a much stronger product.

Karen:

Brandon, Sophie, I share Ethan’s interest in building mobile applications for markets that aren’t served by the same kind of connectivity or iPhones that we are, and I genuinely have so much respect for the work that you guys are doing at Ushahidi. Thank you so much for taking the time to talk with us today. This has been fantastic.

Sophie:

Thank you for having us.

Brandon:

You’re very welcome.

Ethan:

Thanks to everyone for listening to this episode of a responsive web design podcast.

If your company wants to go responsive but you need help getting started, we offer a two-day onsite workshop to help you make it happen. We also offer these workshops to the public, so please go to responsivewebdesign.com and see when we’ll be in a city near you.

If you want even more from us, you can sign up for our newsletter, subscribe to this podcast, and read full transcripts of every podcast episode at responsivewebdesign.com.

Thanks for listening, and we’ll be back next week.