How To Design A Weather App
The Process Behind Creating the App Hello Weather
For this interview we're joined by the awesome designer behind the fantastic weather app, Hello Weather. Jonas is also the senior product designer at Basecamp and has been creating interfaces for well over a decade.
In this interview Jonas talks about the process of creating the ideal weather app, how he and the rest of the team did it, along with what it's like to run an app as a business. We wrap up the interview discussing tips on how to break into product design as a career.
Jonas Downey: Hi everyone, my name is Jonas Downey and I'm the designer behind the app, Hello Weather, which is my side project. My day job is to be a product designer at Basecamp, for the last 7 years.
Billy Carlson: Great, it's a very cool side project. Let's tell everyone a little background about what the app is.
JD: In 2014, Trevor and I were both web people and we'd been working on rails apps and websites and things like that for years. And around that time —- and it didn't really pan out this way —- there was this fear in the web community that native apps were going to eat the web. It was a moment where I thought maybe we ought to know more about this native app thing or just get some experience with it. So we were both kind of hungry to do it.
There were no positions for us at Basecamp. We already had a native app team and we didn't need that many people on the team. That wasn't gonna happen. So we were like, why don't we make an app on the side. We'll just goof around and make a thing. We had both been complaining about the weather apps available at the time, which is hilarious because there's like literally 10,000 of them. Everybody makes one, and well, they're all terrible.
We wondered, why is this hard? It wouldn't be hard to do better or better than the ones that we've tried. We'll just make a weather app that just shows you that the damn forecasts straight up, no messing around. And that was the philosophy for it to begin with. Let's do a clean, readable, very straightforward forecasts weather app on one page. You can just load up and read, and be done and not have to fuss around with gimmicks.
How it started
JD: We began by making a web version of it first because we didn't know how to do native programming and we were lazy. We were like, why don't we do what we know how to do and test out if we even have an idea. If we don't have an idea, we won't continue wasting our time on this.
We prototyped a bunch of things for a long time, for like a year, just in a web view on an iPhone. And at some point we liked it enough that we were using it and it was like, this is bad implementation wise, but we're using it so it must be at least good enough. Only then did we finally decide to make it into an app.
We did a lot of iterating on the design through real world experience, which was I think why it turned out well. The other thing was that we didn't know anything about the weather either. So we were entering into 2 domains we knew nothing about. I don't know anything about meteorology or weather forecasting. I also don't know how to make an iOS app. So we had to spend a lot of time learning and figuring out what data is available, how do you show it and how do you do it in a way that's understandable.
In Chicago, the weather is just a mess constantly. There are all these bizarre situations. One day the wind is 75 miles an hour, but the app didn't show that. You should know the wind. So we just checked off more and more different scenarios into the app and pretty much covered most of them.
BC: That's a really interesting way to do a project. I guess a smart way. You don't have to throw out there right away and get feedback. You can be the feedback provider by yourselves for awhile.
JD: Yeah. I think the thing with the weather apps, a reason there's so many of them, it's a very attractive visual design problem. Lots of people say, Oh, I have a clever idea for a visual display of weather data. And designers always need something to show, right? So, just give me stuff and I'll make it look beautiful. There's lots of apps that do that and doing great job looking nice, but don't do much functionally. Actually try to use them day to day to figure out if you're going to get blown over. Most of them wouldn't even be viable apps. You couldn't even build them. We took the opposite tactic, which is, let's make a thing that's functional, when it works and then figured out the best way to show it.
What was the process behind creating it?
JD: I remember we had an idea for the philosophy of the app that it would be all the forecast information on one page so you wouldn't have to scroll around to different detailed views. We didn't have much in the way of design direction at the beginning.
There was some project I did a long time before this — I used to do data visualization stuff — and spent some time mocking up this idea for showing the temperatures and precipitation along the same axis, as mirrored data points.
I had that in the back of my head and I was like, why don't I fiddle with that idea? So I sketched a few things like that on my iPad and just goofed around and came up with the idea, which was originally a line graph. We eventually switched to a bar chart. I think I sketched the mirror where it's the temperature on one side and precipitation on the other side, with the data in the middle really early on. I think it was the first week we started working on it. It held up.
BC: That's crazy.
JD: Yeah, the app morphed into a bunch of other things. Yeah, that's still of the core of the app, which is the basic chart.
BC: That's awesome. Very cool. So you created this lower effort MVP (Minimum Viable Product), then it became an iOS app and like you said, you keep iterating on it.
"We worked like copy editors, carefully selecting what information was essential. Our mission was to show the most contextually relevant info on one screen, and shove everything else off to a secondary view, or cut it altogether. Each data point had to fight for its life."
— from the Hello Weather website blog post, "How we made an iPhone app on the side"
What's your process for creating new additions?
JD: The first version of the app that we launched was not a very good app. Candidly, it was fairly terrible. It was a web view that didn't do much. It had a location picker I think. It was bad enough that we thought, we'll just make this thing free because we don't feel good at even charging for it. So that's where it started. It started very humble and we built it up.
Even with the bad version we got some nice reviews. Places like Macworld and App Advice discovered it early and featured us in a little review. With enough people using it we felt it warranted more effort. If we're going to have a few thousand users then we should iterate on it and make it a thing that we're not embarrassed about.
Part of that process was that we had to get better at doing native app development. Since we don't do it as our main jobs, we'd come to it in the evening, poke around, but it's hard to get a solid block of time. Well, we've been doing this for enough years that we've continually gotten better and better. Now we feel like we're close to professional quality.
The app has continued to evolve as we've discovered new weather forecast scenarios that we hadn't addressed, or new design ideas that we wanted to try. We get tons of customer feedback. An unbelievable amount of people write emails and tweets suggesting ideas or they'll point out a bug. So a lot of the work has been fixing every imaginable scenario. If it's negative 52 in the Arctic, there's some guy in the Arctic who says, "Hey, this looks wrong, it's negative 52". And we say, all right, we'll fix it.
Apple also continues to iterate their products. As native app designer, you have to keep up with what they're doing if you want it to stay relevant. Every year or so they announce the new iOS and then typically they bundle in 2 or 3 new features with that. Or they'll do Apple Watch or whatever it is. If you can get into their system and do what they're pushing that year, they'll feature you on the app store. They've been really supportive of us and put us in lots of cool places. So it's kind of a combination of all that.
We still like working on it. It's fun. We're learning a lot still and there's more to do. There's always more to do.
BC: When it comes to building new features and designing new things do you primarily work in Xcode or do you do work outside in a design tool and then bring it in?
JD: I do a lot of the UI in Xcode. At this point I think I do most of it actually. There was a while where I would do some and Trevor would come around and fix it. His time has been really tight lately, so I've had to just get better at it and muscle through to get better. I mostly work in Xcode, but we still have a hybrid app. We still use a web view, so I'm doing some stuff in Rails, HTML and CSS, and stuff directly in Xcode.
How do you run an app company?
JD: There's no way to do an app that is not an entire business onto itself. If you're going to do an app, you also are now running your own company more or less. And it can be a shoestring company, we're fairly little, but you have to report tax income. You're going to sell the thing, you get income, you have to have somewhere to put that. You put in the bank, right? Then you have to report that to the government. You have to file as a company. You have to certify yourself with Apple and meet all these requirements about legal and what territories you are allowed to sell it in.
It's a significant undertaking just to even get the app in the store. And then on top of that you have to tell people the app exists and market it. Do the App Store listings and ads and things like that. You also have to decide, what's the business model? Are you gonna give it away or are you going to charge, you know, $3 bucks? Are you going to do a subscription? There's all these different choices. That whole side of it is almost a project in itself.
How do you start the design phase?
JD: It varies a little bit depending on what we're doing. In general, I think the process that I follow is similar to the 37 Signals / Basecamp process that we've written about in books and stuff, which the main point is, to make something real as soon as you possibly can so you can understand more about what you're making.
Whereas, I find that the longer you stay in a hypothetical, mockup kind of scenario, the slower it will be that you make progress to something that's ship-able. That's partly why I like working in bare metal tools. I work directly in Rails. I work directly in Xcode. It's the shortest amount of work to go from an idea to a working thing, without something in the middle.
But there are times when you can't. You have a new app idea and it's totally raw and you don't have the resources to be able to build it immediately and start fiddling around for a year. Or you have a few different ideas that aren't fully formed and you feel like you need to see them and experiment a little bit before you're ready to get down to details and stuff. Those are the times I'll spend more time prototyping with static mockups, I'll draw stuff in Sketch, I might draw stuff on my iPad, whatever's available. And then basically once you build up enough confidence to say, okay, I've been through a few iterations on this and I feel like I have a sense of it, then you can start getting into the implementation. But in general it's getting something built as quickly as I can.
What does your wireframing process look like?
JD: I don't really do formal wireframing in the traditional sense. I have done that in the past when I was doing more client-centric work. Where in those cases a lot of times clients want to have a reasonable understanding of what they're paying for, in advance of paying for the whole thing. Those were cases where I would like to add wireframes or maybe a higher fidelity mockup as a deliverable to try and convince someone, here's the plan, here's the information architecture for this website we're going to make. Here's where all your things are going to go. We haven't flushed it out completely yet, but this is the idea.
In my current line of work, there's nobody I really have to convince other than either myself or people at my company. We can do that in a more low fidelity way, even with just broad marker sketches for a few screens, then stitched together roughly without having everything sorted out to the degree of a wireframe. I haven't really done real full tilt wireframing in a while, but what we do is a variation on that… you can kind of see behind me. That's a very low fidelity sketch.
BC: And the reason is, I imagine, because you've worked on the same products. You helped design it from the beginning and pretty much the entire team that's worked to create it would know if you made one of these sketches, what you're talking about visually.
JD: The sketches like the ones behind me are more about communicating the root of an idea without getting into the weeds on the actual final visuals of it. We have an idea for a screen and we think it's going to have 2 buttons here and when you click one of these, it's going to do this and then there's gonna be some text in this area or whatever. We can sketch that out literally in 3 seconds and have a sense of it without really knowing what it's going to look like.
But at least we've communicated, "this is the concept". And then one of us designers can take that rough concept idea and go bring it to either our prototype phase or to a HTML, CSS kind of thing and build something on pretty quickly. In a day, we can go from that rough chalkboard sketch to on a screen that's not done, but you can look at it and start to iterate, make assessments on it.
I really think it really depends on what you're making too. When we were redesigning Hello Weather for the iPhone 10, that was a case where I did a bunch of Sketch mockups because we weren't sure if we had a good enough idea to justify spending a bunch of time during the redesign.
I wanted to see what would this screen look like if we took all the ideas we have now and built that on top of what we already have. And at the end, is it going to look like we care enough about it to spend the next 2 months building? And that's something you need to do periodically. But if you're building a small feature or a single screen in a flow or whatever, those tend to be things that are easier to start and communicate with these chalkboard sketches.
When you're creating something new, how do you know you're on the right track?
JD: It's difficult. So one way is to have done your research in advance of the work, so that by the time you're doing the work, you're confident in it because you have enough information up front that you believe you are right about. That's generally what we try to do at Basecamp. We try not to embark on projects that are maybe not defined well enough or are still fuzzy enough that we don't have the confidence that we can launch this thing and feel that we nailed that.
Part of that is doing a lot of background work in advance of assigning design teams to projects. Talking to customers and using the product ourselves and sort of poking holes in what works, what doesn't and why people buy this thing and why people use this thing. All that kind of background knowledge keeps accruing and you get feedback from customers and you can assimilate all of that into ideas.
Now, if you're starting something completely new, as we did with the weather app. There's really no way to do a lot of research. If you're new to a field, you don't have any customers, you don't have any people who want to talk to you about it. Which is why we spent a lot of time using it ourselves, to learn the domain. Then at that point you're sort of back in the safer scenario where now you've used it and you have some knowledge and you can keep iterating.
What advice do you give to people who are trying to get into product design?
JD: I took an extraordinarily roundabout way into product design. I think part of the reason it took us weird ways to it, was that the field had not been properly defined when we were coming up. I didn't know really that product design was even a job I could get until I was already in college. It's not like there wasn't software and web products and everything at that time, but I just didn't see that as a job for some reason. I didn't know. I did a bunch of stuff prior to this. I started in journalism and doing writing. Then I got a degree in computer science and then I went to graduate school and got an MFA in new media, which is weird, because I don't think it's really new anymore.
And then I did a lot of web design, web mastery jobs for a few years and eventually found my way into doing apps. Then got the bug and realized, oh actually what I wanted to do all along was make software. I didn't realize that I've been doing things around software for a decade and then discovered, oh actually software is a thing. Now I think it's more obvious that it's a profession.
It's hard to break into the world of design. Do you have any advice for ways that could help?
JD: The main thing is just producing work that you care about, whether someone tells you to do it or not. I feel like that's the one thread, if I trace back my entire career, the things that have progressed me to the next level were always things I was doing outside of what my job at the time had been. For awhile I was doing network administration and I was a webmaster for a middle school and college and those are fine jobs to do and I was getting paid, but it wasn't fulfilling my creative itch.
So I was doing websites on the side and I was experimenting with little projects on my own and putting that out there and writing blog posts that nobody was reading, just doing stuff. And I still do now. I can very easily just work at Basecamp and take home my salary to be fine with that, but I still have this nagging, possibly annoying, personality flaw thing where I just need to be doing something that's my own. That I own and get to play around and do experimental stuff that's outside of what somebody else told me to do.
I think my one point of advice is if you're trying to get to product design or you're trying to do software, whatever it's too keep poking at it as much as you can and you'll get there, you'll get there eventually, but it'll take awhile.
BC: That is great advice. I think that's it. Thank you so much.
Jonas has written a few excellent blog posts about designing the Hello Weather app. They are worth checking out and learning even more in depth on how he approached many different design and software challenges.
--
For further reading:
https://balsamiq.com/learn/articles/mobile-app-wireframing-guide/ https://balsamiq.com/learn/articles/wireframing-mobile-applications/
How To Design A Weather App
Source: https://balsamiq.com/learn/videos/the-process-behind/app-hello-weather/
Posted by: hatcherdeconsenry.blogspot.com
0 Response to "How To Design A Weather App"
Post a Comment