The Cloud Community application for iPhones is an app which is designed to be a social network for all who have an interest in learning about clouds, and wish to explore and learn more from a worldwide community.
The goal of this project is for me to learn how to begin designing a medium sized app, while taking into consideration different aspects of mobile through location based abilities and iPhone affordances such as a camera. Although websites and apps are very different and are used for different reasons, I believe that there is enough overlap that many things which would work for one can also be applied to the other.
Now I want to make it clear that there is no immediate plan to finish a fully functional app that will be on the market in the near future. If there is an opportunity for someone who sees potential in this app, I would be willing to work with them, but primarily, I wish to focus my attention on this project strictly to designing the user experience through flowcharts and wireframes. With these created, I will be able to create a prototype that can be used on an actual iPhone to get more feedback on what works and what doesn’t work. Then a redesign will be appropriate to create a better design and user experience if this app were actually created for public use.
I described three main ideas that will be used in this project. They are first, a flowchart, next a wireframe, and finally a prototype. Before working on this project, I felt like I understood the basics of each of these sections, but I still lacked some common knowledge and experience when working with each of these. The following sections will go over what I have learned with each of these, and how I applied it to the Cloud Community app. There are specific tools that I have chosen for each of these, namely Lucidchart, Sketch, and InVision. I will also go into detail about which tool I used for which step, and why each is an appropriate tool for that specific step.
While at work one day, I noticed one of my co-workers using a flow chart tool called Lucidcharts. I was intrigued by how easy it looked to use. He used the Lucidchart to lay out the navigation for a website so the client would be able to understand how the website would be used. I thought that it would be a very appropriate tool for this project. Even though it was a small scale app, I felt that using a flow chart would make it easier for me to understand how everything would work, and give me the flexibility to rearrange ideas on the fly. This worked incredibly well.
The first flowchart I created was on a whiteboard. I had my ideas in my head, but I needed to get all of my ideas out of my head. The more I drew the idea out, the more problems I began to see. For example, I noticed that there was a lot more happening than I had envisioned when it came to searching for different cloud posts. I thought that people would simply search for a type of cloud, but what if they wanted a more detailed search? They should be able to have an advanced search option. That in turn opened up a whole new line to what I had originally created. I also had created a Home screen where the user could go and get the current weather condition at their location. I also came up with the idea of having a “first time” tutorial that will explain how to use each feature of the project. You see that commonly with apps anyway, so I feel like it would be appropriate for this case as well. I did this step pretty quickly, and hoped that when I went to digitize the flowchart, a few more ideas would come up, and they did.
This next flowchart I created using Lucidchart. It is a web based software that allows you to create flowcharts, wireframes, and much more. As a student, you can get this software for free. If you are not a student or educator, you have limited access to it. It didn’t take too long to work it out. Basically, you drag shapes in, change the text, and pull arrows from one shape to another. It is really convenient when you want to change things around. On a whiteboard or a paper if you need to rearrange sections, you would need to erase it and draw new lines. I have heard that you can make this a little easier with post-it notes which I am open to trying.
While I was working on this section, there were some things that I noticed that didn’t make sense from my original sketch, so I re arranged those things around. Once I felt like I had a pretty good idea of how I wanted the app to work, I showed my flowchart to about 3 people asking for some input about the organization. Sometimes they would give good feedback, and some wasn’t too helpful. I think in future projects that is something that I can work on; asking the right questions to get the best feedback possible. I did learn a lot from verbally describing my app, and brought me to realize some potential issues that would arise.
Once the general flowchart was finished, I worked on getting some wireframes. Again, I learned that wireframes and flowcharts are not the same thing. Wireframes actually look similar to how the app would look in a very low fidelity appearance. An image would be represented as a box with diagonal lines from the corners. My wireframing tool of preference for this project is a program called Sketch, which I have used on multiple occasions, but have used for very little mobile development.
One suggestion made through my research was to make what is called a paper prototype. This is where you get notecards and sketch out with a pencil a rough version of how the app will work. I used about 40 different notecards and drew a quick 1-2 minute version of how I thought the app would look. If I didn’t like how it was looking, I threw it away and started over. It was good way to get my thoughts out on paper. I like diving right into designing on the computer, but in my experience, making something twice is much easier than making something once and re arranging it. After thinking some things through, I realize that the more things that you try to fit in the design after the fact, the messier the design will be. Anything that is disorganized is bad user experience design. With these wireframes, I tried really hard to make sure that the elements that I was putting into the app would leave room for future developmental growth within the app. I was able to merge two fields successfully together. On the flowchart you will notice that there was one section for “Browse” and another for “Search”. I combined these two so there would be 4 navigation items in the menu bar rather than 5, giving the users more space to tap the buttons. The paper prototypes were very successful in my point of view. Another quick tip I made up was to write what the screen was about on the back in case it got mixed up. I also showed these wireframes to 3 different people and got some additional feedback.
Next, I used Sketch, the design tool of choice for many UX/UI designers. As I have mentioned before, Sketch is a tool similar to Photoshop and Illustrator which also can create visual graphics, but is designed for web and mobile development. Some features of it are multiple artboards, exporting images and icons for final production, an infinite canvas so you can design whatever you want on one page, and a simple to use interface. With Photoshop and Illustrator there is so much going on that sometimes it can get really confusing.
Meng To in his blog post gave a very helpful wireframing UI kit for this project. There are 3 types, and each of them are in a monochromatic, neutral color. As he mentions in his article, it is important to use these colors so that the visual design doesn’t detract from the experience of using the app. I chose to use the dark blue version for my project.
I created 5 different pages with multiple artboards for my design to keep things organized. Each page contained each of the menu items (Weather, Search, New Post, and Profile) then I made one for the beginning screens. I had about 40 pages of paper prototype screens, and I figured that with some changes I might be creating about 10 additional pages within the app. From here, I just started with the first page, which was the loading screen. I copied over my ideas from the paper prototypes one by one, making small modifications to each of them.
Something else that has been incredibly helpful with this wireframing is Sketch’s ability to work with what they call symbols. Symbols can be whatever design element you choose to use, and repeat frequently over the design. An example that I can give is for the menu button. There are over 60 artboards in this project, and most of them have the menu on the bottom of the screen. What would happen if I realized that I spelled something wrong, or wanted to change one symbol? You would need to do that on every page that menu is on. With symbols, there is a separate page where if you change the design on one, it will change on every instance where that symbol is on the artboard. All of my menu groups on the artboards are symbols, so to change the magnifying glass icon to something different would be a one time thing for every artboard. You can even nest symbols, and have symbols of symbols which is also very convenient. With these symbols, you can also override text if you need to. I was very grateful that Sketch integrated symbols in that way. It is easy to use and has many possible applications.
Now even though I didn’t want to use images, I wanted to use some general icons that would be helpful for people to glance at when testing the prototype and be able to recognize what they were tapping on. I found another helpful resource that works well with Sketch called iconJar. The app does exactly what it sounds like it does, which is holds icons in an easily searched app. You do need to go out and find the icons and import them to iconJar, but from being a graphic designer, I had quite a few of them saved up. From this app, you can just drag and drop them in Sketch, change the color, and your done!
Getting the first couple of screens worked on was a little bit of a challenge. I had to remember how to do simple things in Sketch, and remember different shortcuts on the keyboard, but after a while, I got a lot faster the more I created. The UI kit was very helpful for creating the wireframes since I was able to simply copy and drag the new UI components to the artboard I was creating.
Invision was my tool of choice for prototyping. Most of the reason behind this is that when I started getting interested in Sketch, looking into tutorials and options, I ran into a lot of tutorials put out by Invision Labs. They advertised a plugin that they had for Sketch that I wanted to try out (called Craft), and it worked pretty well. I couldn’t figure out why they did so much work to help people use Sketch and their plugin, so I looked into how they make money, and it turns out that they are a growing company that will allow you to test your app prototype on your iPhone with clickable links. It seemed like a pretty good idea. Later I did a short tutorial on using Sketch with Invision, and I liked it. Now about 5 months later I worked on my own, personal project with 60 unique artboards.
Invision is a prototyping tool, and it gives you the ability to mimic buttons that are designed in Sketch. Simply drag a marquee around the button, and give it a link to a destination on a different artboard. You can even create templates for common elements, such as menus, so you don’t have to go through the whole process on each page. Another benefit of Invision is not only the ability to link buttons with artboards, but you can say how you would like to animate the change between the artboards. You can specify the page change the animation to pop, slide, fade, and more. This gives the app a little more interest when using it, and leaves a better experience using an app, even if it is just a prototype.
I started out small. When I got the first 6 screens done, I exported them to my computer, then to my Invision account and played around with the interface. I didn’t have to look up how to use Invision very often as it is a very user friendly program. Everything is very well organized, has good navigation, and shows you what is possible at pretty much any given moment. It worked very well for my purpose. The feature of using the prototype on a phone was especially useful when it came to checking sizes. It is nice to look at the computer screen when designing, but when you have the app in your hands, you can be more accurate about font size and placement of buttons. The earlier you correct problems like that the better off you will be later on. Once I felt like those first screens worked well, I moved on to designing more screens in Sketch.
As I created more screens I was able to use the Craft plugin, which is made by Invision, to upload and update artboards quickly to my account. This is a huge selling point to me. It was so seamless to transfer Sketch artboards directly to Invision. It saved a lot of time where I could focus more attention on the design of the app. With the artboards in Invision and correctly linked, I could connect my phone for testing. I tried really hard to find out where people might get stuck and correct it before I hand them the phone. Sometimes I would get so caught up in finishing that I would forget to make links on an artboard, which would not let the user go to any other screen, so they would have to manually change the screen.
Usually, my first app tester would be my wife. I would give her the phone, and she would often tap somewhere on the screen where I wouldn’t expect anyone to tap. In my head I would think “Why would you press there. Obviously that is not where you press.” Then the more I would think about it, users really would press in that spot, and I was the dumb one for thinking that they wouldn’t. It is helpful to be able to step back from the app for a while and take note on how others use the design. With all 60 artboards designed and fully linked, I felt ready to give a presentation on my work surrounding the Cloud Community app.
There are so many options to create something spectacular with the technology that we have. Even if it takes a bit of effort, little by little it all comes together. I feel like I only hit the tip of the iceberg with what each technology has to offer. I am excited to continue learning about each of these programs, and many more that are out there. I used LucidCharts, Sketch, and Invision for my project, but there are multiple versions of each software that will do similar functions in their own intuitive way. I hope that by reading this design rationale you would have a better understanding of what it takes to get started creating a simple mobile app. If I learned any one thing from this project that I would take the rest of my design career, it would be that designing an experience is more than having cool equipment and software. It is for making the interface as easy to use as possible for the end user.
If I wanted to spend even more time on this project, I could have formulated in-depth questions to ask users when testing the product, and tested 5 people with more frequency. Some of the further steps I would have taken would have included another round of wireframing (keeping a lot of the same material, just modifying some flow), more testing, and getting some mockups done to show how the app would visually look. I enjoy visual design but I really enjoyed taking a user experience designer’s standpoint in this process. I see a lot of potential for this app, as long as there are people who love to watch clouds and hold conversations about them there can be many learning opportunities.
This is the Cloud Community app. Whether the app becomes a realization someday or not, there has been a lot of learning from it in many forms. Although technology can be frustrating to use at times, I believe that learning can be achieved in a mobile setting, especially in a way where the user can feel engaged in learning.