Updating an App: UI Design Breakdown

We are currently in the process of updating an existing application that is used by our staff members backstage. It is an iOS app, but both technically and visually it had a lot of things that needed to be improved so we decided to scrap the old, unstable version and create a fresher, tidier application. The application is native iOS and the only device it is needed for is an iPod Touch, however we have optimised it so that it works on all iOS phones too.


The basic user journey is that the user will enter their store ID number as an identifier and see a list of ‘picks’ that they need to complete (items to take off the shop floor to ship to customers). They need to complete as many picks as they can and submit them when they are all completed, within a timeframe. There will be several time cut off points throughout the day.

This application had a lot of technical debt, so we began the process completely from scratch again including the UX, UI, front-end and back-end development. We researched the current journey with our users, found pain points, wireframed and tested, then began the app development in XCode.

My sketches were very rough and messy, filled with notes and originally not even using a proper iOS phone template. To get the sizing right later on, I used an iPhone5 template from marvelapp.com to draw ideas for my screens and get a better idea of composition and layout, but I will only show my digital designs here as I have a massive pile of sketches on my desk and can’t find many good ones (and yes I can draw, honest!)


The next stage saw my designs digitised in Illustrator. I had many designs for certain elements of the app (submission button and its journey was the main one, and it’s still up for debate during our Android process now!) but this shows the main screens for phase one. There was a big use of filters and the user having control over the journey themselves, as well as the main point of being able to submit picks individually rather than having to submit them all in bulk, saving time and allowing the app to update in real time. However there was a bit too much control in terms of views and buttons, so we decided to relook at this slightly. When testing, the user had a bit too much control and although this might be empowering for some, it was a bit too overwhelming for our core group.

Users were also struggling with the use of two fonts. Sometimes this can be effective (we also have two company fonts) but it was unnecessary for this particular app, so we stuck to the clearer of the two fonts and just played with the size and styling instead.

The display of information also changed during this stage. Key information was shown in the main cell and additional data hidden under a subtle button. The most important information was also overlaid with the image on a darker background to draw the eye, which also saved on screen space. The display of information worked really well and the user was always able to access what they need, so it was an immediate win for us that just needed some slight fine tuning as the layout changed later on.

We had a shift in priorities shortly after this stage and the project got put on the back burner for many months. When we got back round to re-visiting, more research had been done and the priorities themselves had changed.


We then went back to the project and the next stage helped pave the path for our final design. We wanted users to be able to still have control over their own pick list, so the main page got given even more selection options. This empowered the user by adding the ability for them to select their own departments (e.g. T72) within business units (womenswear, menswear etc.) and customise their workflow according to their store.

The third page showed more details about each item, along with an enlarged image that is zoomable to make their life generally easier, especially for those less familiar with the products and those with vision difficulties. We had a shift around with the placement of key information in the final stages of design but apart from that the screen remained more or less the same.

The second page displayed key information, showing more of a distinction between sections which has been achieved through the clear black labelling, making parts of the app easier to read and separated. However this page as a whole wasn’t interactive enough with our more experienced pickers, so this was again something we had not gotten quite right. We re-thought this page once again, as it was one of the most cost-saving parts of our new app.


Users could now easily scroll through their own customised picking list, have all the key information they needed and be able to submit all on the same page. However, the problem now became screen real estate. We wanted to have the ability to display at least four picks on the page so that scrolling wasn’t too much of a chore (they could potentially have over a hundred items on this page at once). The only way to free up the space was to get rid of the submit button, which we needed to meet the goal of the page anyway. The solution: condense the key information within the button.


This was the outcome for our final design. The first screen now displays only the available departments and has related images to help the user learn their product codes too. It’s also much clearer when a department has been selected/how many picks are needed by the extra information added in several places throughout the page. Terminology was a very important factor in this application, so it was important that we used the correct wording for things that all stores had the same definition for. The phrasing of buttons also had to remain consistent throughout so that the action of the button didn’t confuse the user.

The app has been coded and is being trialled in stores now. The three screens I have covered show the core screens for our user journey. There are a couple of other parts I could show (settings page, dialogs, error messaging etc.) but these were the key parts of the journey and the ones that needed the most improvement from the original app.

As well as this, visually colour has been taken into account for interactive elements too. Anything that is green is interactive and performs some kind of important action for the user. However we don’t want to rely on colour completely (a big no no for accessibility), so there are standard iOS conventions in place that portray interactivity; such as cells and multi-selection buttons. All buttons have also been designed in this app so that they are big, bold and obvious, using a positive green colour. We have managed to use less buttons than the previous version too. Now, the user can tap the ‘quantity’ button and this will display a keyboard where the quantity can be submitted, rather than having three separate buttons requiring multiple presses to get the same job done.

I mentioned earlier about terminology being an important factor. The wording of actions throughout the app and having key information displayed in headers is also extremely important. We have used buttons that say what they are going to do, as well as actions and dialogs that don’t beat around the bush and use unnecessary text. Some tips: use actionable verbs (don’t use ‘OK’), simple language (sometimes conversational, depending on your audience) and use language that the user is familiar with.

The typography has also improved. Text size and style has been used appropriately for the most important information, as well as taking into account element size to accommodate this information. Elements are either dynamic or scrollable to account for long strings, whereas before anything over a certain character length would simply break the layout. Fonts (and colours) have also been updated with the latest internal brand guidelines in mind.

For the technical part (for you coding people out there), the app is much more stable, the code is organised nicely into separate folders and class files, it has full test coverage and is future proof. It has been written in Swift compared to the old app being written in Objective-c, and it worked in the most recent version of XCode (time of writing this is XCode 6). Continuous integration is used and the app is deployed to users using Fabric, along with informative release notes. The app is adaptable and ready for change, with room allocated throughout for new features if they need to be added. The designs are scalable and adding a new label would no longer break the layout as it did before.

Throughout this project, we have taken the approach of design > build > test > reiterate for all features, with a lot of time being spent across many stores with different users. We have even coded small changes while on the tube between stores so that we can see the difference that small changes make to our user groups! Every feature has been deployed in this way and the majority of them have been successful without a need to reiterate for too many cycles. This approach has been efficient, agile, useful and really fun so we now adapt it to all of our projects. We used it in a previous project before this one as a test and now it is one of our main ways of working, with the whole team getting involved in the process.

We also had the whole team getting involved in giving feedback throughout the project. Everyone had an opinion on everything throughout the design stage, and although it is important to get feedback from colleagues, don’t let it steer your design direction too early on. It got very silly in the end where even the colours I chose weren’t agreed upon. We had a small conflict in the team at one stage when they didn’t like what I was doing and were actually suggesting ways that the user experience could be improved without an actual user testing. When we design, it is all based on assumptions until the user gets their hands on the app. We know our user, but we are not our user.

Overall, the experience of the app as a whole has improved drastically due to re-thinking the UX and this has shown through the app’s analytics and the timings taken to complete their picking. We have met our requirements and users and stakeholders alike are happy. It’s been good fun re-creating an existing app rather than starting from the beginning by being given a business problem to solve through technology (which usually involves making an app from scratch). We would like to add a few more features (such as a ‘new in’ label), but these are either limited by our back-end systems or aren’t our top priority right now. We have recently shifted over to Android and we are currently in the process of building this natively in Android, so another blog post will be posted when this process is complete!

Note: If you’re interested in my workflow, the tools I used for this project were Illustrator (with the use of lots of symbols), Photoshop, Marvel and XCode.

This has been a bit of a long post, so if you got this far thanks for reading and I hope it helped with your own workflow! 🙂


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s