After 5 App Design

After Five Cleaning — Introduction

After Five cleaning is a cleaning company whom do cleaning services for inside houses. They offer various types of different services and are available via their website. They needed an app designed that would allow them to add and edit the questionnaire that they would send their users to fill out when they want to request their services. This project differed in a sense from the websites and game UI that I normally designed. This was something considerably smaller, but because of that this also mean there was far less room for error. Simply put, I needed to throw a jab, but only a jab. This mean I can practice this to the maximum

After Five Cleaning — Mobile first design (Identifying the needs)

The first thing that was to be noted, that it was a questionnaire. This sounds pretty simple, but because of the application (to book appointments), and the fact that the app was actually very in depth, this needed to be laid out visually, in a way that made booking as smooth as possible. The one problem that I can easily encounter, is that with all of the questions that are required, is that it can get overwhelming. Imagine sitting for an hour, just answering monotonous questions, it may be necessary, but it isn’t exactly a good experience. Normally in UX design, you would want to identify the common pain points that someone using an app or a site would experience, but this sadly couldn’t be the case here, as there wasn’t any real previous reference to go off of. This presented a unique challenge for me, and meant that instead of simply “improving” off of what had already been done, I needed to effectively “shoot in the dark” (as at this stage I am still quite inexperienced)

After Five Cleaning — Wireframe layout

So, the first thing I did was pull out my pen and paper and got to drawing. I wanted to design something that can take advantage of the one key advantage mobiles have. Hand gestures, make things that would require scrolling on a computer or doing certain actions (such as closing or changing page) incredibly swift and easy. This is one of the main draws. My first worry, was making the app be a chore to scroll down, as you added more and more questions. The Sketch was just a good idea of what to do before the colour scheme was to be decided

After Five Cleaning — Colour Scheme

This was the likely the easiest part of the entire project. Because the company colours was green/white for their website, they wanted this to be used with the app to keep it consistent. This was perfectly fine by me, my work load was reduced. For me the only real choices that needed to be made was where the colour was to be placed. Green, especially dark racing green, can be a very overwhelming colour when used too often, whereas white, can be very “boring” when done

After Five Cleaning — Mobile Version V1

The sketch for the mobile version was quite a ways different from what the final product ended up becoming. If you’ve seen my portfolio at coroflot. You can immediately see that the sketch you’re looking at looks a lot more “phone” like, for lack of a better word. What I mean by this is that I have designed the interface to be able to take advantage phone specific features (in this case, swiping). This was where I learned about user testing. Once I designed the application (I could quickly mock it up with colours, as these had effectively been decided for me) I immediately received the following question;

“what would I do if I wanted to edit a question I already submitted”

And right there the design fell apart. Effectively, I had no real answer for this. So, immediately it was back to the drawing board.

After Five Cleaning — Mobile Version V2

So, it was effectively. Back to the drawing board. For the next one, I looked towards different inspirations for the layout of the mobile version of the app. This time instead of trying to design what I “think” would work, I instead wanted to go and see what similar apps there was on the market place that was currently being used.

Survey Monkey

The app layout of this was pretty solid, it was easy to use familiar, and it actually reminded me quite a bit of google forms. The only problem was. One of the key requirements was that each question was to have “sub questions”, as due to the layout of the question, there also needed to be sub questions related to it, to them determine what sort of equipment would be used (e.g. if you have a room with windows, how many windows?). So this presented a different problem. This effectively meant that I needed a way to “group” a question for ease of use for the employees. The reason for this was that the cost, hours and equipment they would visit the house with, was determined by what answers were given.

Google Forms

This is partly what the first version was based on, as this is software that I use often, So I decided to take another look at the layout and analyse it once again to see where I went wrong. As you can see, the similarities between that two, is that there is a “panel”. This is where the idea to have employee’s “swipe” left and right came from (this is a desktop screenshot). The problem that I encountered here (again) was simple

How does one keep track of all of the questions they have added? And how do you make this straight forward to view and modify?

Tree List Layout

This was something I actually found upon by accident. The tree list layout is when you have a parent and child relationship layout. The parent is the main object on the screen, and the child are the things that are related to it. This sort of structure is used often in the programming space, as someone who has done computer science in the past, I am very used to using it conceptually whilst doing object oriented programming

As a result. I decided to try out this layout for an interface. Instead of making question a “question”, it becomes an “Object”, the sub questions merely become the “child” of the “parent”, this isn’t UX related per say, but this is programming related. This effectively describes how the programmer would need to implement this method, which is important because I was actually working side by side with a programmer as I was implementing the interface (he was the one that asked the question) This line of thinking, resulted in the following sketch

Low Fidelity Sketch

High Fidelity Sketch

This is the result of the sketch. The idea was to have one main menu which allowed you to add “parents” (questions) which automatically gave you answers (the child). This structure would then be delved upon via the sub-questions. Which lets you do the same thing (add a sub question). The one problem that could still be present with a view like this is overwhelming amounts of information, or having to constantly scroll through layers upon layers of information (especially when the questionnaire gets large) To somewhat resolve this, I put in a collapse all or expand all button, something which is fairly common when working with folders in applications.

Things to improve upon

One of the key things that I actually missed out, was a search button. As it stands, even with everything “collapsed” there would still be a fairly large amount of questions to look through. This can easily be cut through if the user can manually search the question itself that they are looking for. The thing to remember is that the main user base will have upward of thirty to forty questions at a time, each with their own sub questions. I also intend to make the each “object” numbered. Where you can see the “type your question here” section, should have a “1.” annotation, to let the user know. I consider this a mere quality of life change, but an important one nonetheless

But even with that particular problem, the UX of the app, is something that is

Originally published at https://www.tumblr.com on April 7, 2019.