My First 3 Months In A Startup

So I have now reached the 3 month mark at my not so new job and passed my probation! It has been wonderful so far and I am learning so much – not regretting moving on from my last place at all now. So I thought I’d give a few points that I have learned from my experience at corporate vs startup.

  • Things get done a lot quickerIt used to take months and lots of cross-team communication to try and get a project off the ground, usually with many conflicting opinions about what should be prioritised, timescales etc. Now, we decide on what we want to be designed and developed, with just a quick discussion to decide what is most important, I begin designing and the specifics get confirmed later.
  • Job roles cross over a lot more. This is quite an obvious one: teams are smaller, there are less people to do certain jobs. When someone goes off sick, it is now noticeable. I was off sick for almost a month at corporate and everyone managed fine, while if that happened now with no planning, I think chaos would ensue. Someone on my team was off sick for 2 weeks and we learnt from it, but not in the best way. Now, designers in my team get to own more of the process and planning behind a product, so that when someone is off sick, we all have the power to get things moving. This would be something that I think would be extremely beneficial to corporate too, however many ‘higher-ups’ would not approve. But I love having greater visibility of more areas of the team and being able to work on the planning, designing and guiding developers.
  • It’s more relaxed than I thought it would be. Now this may not be true for many startups, but everyone gets their work done and goes home. There are no 11pm pizza runs when everyone is working all night long, not on my team anyway. If anyone needs a change of environment or wants to work from home for the day, that’s good too. I had this freedom at corporate, but sometimes it was frowned upon if you left too early or worked off site.

I really prefer the startup ways of working. It’s more agile, you feel more valued and you get to broaden your horizons in work. This was attempted to be achieved within my corporation, but unfortunately failed in the end due to corporate politics. I look forward to learning much more in the future!


Leaving M&S

Today, I am leaving Marks & Spencer. My first job out of university, and an amazing one. It is a very sad time for me, as a company that I loved so much changed completely. I won’t go into details, but it was time for me, as well as many others, to leave. I will continue my career as a UX Designer, a role that I have been striving for for years and am very excited to prove myself in.

Screen Shot 2016-11-07 at 13.01.11.png

These are some of the people who have made my 3 years at M&S so amazing, and I am truly gutted that I don’t get to work with them anymore. The majority of the people in this picture are moving on too but I hope we will all stay in contact – there is such talent at M&S.

I have had the privilege to not only work alongside and work with a bunch of brilliant individuals, but we have built some awesome apps together too. I feel so proud when I walk into a store and see staff using an app that we created, some of which have been a complete game changer. I also was lucky enough to work on the consumer facing M&S app, which I use regularly myself. I look forward to seeing how it progresses in the future.

Overall, the point of this post really, is just to say thank you to all the wonderful people I have learnt from and to the business as a whole for giving me an amazing start to my career. M&S will always be special to me.

Onwards and upwards, as I start at Jinn on Monday! Check ’em out: I am soon going to make their website beautiful.

Github Branch Strategy and Solving Merge Conflicts


I haven’t written much about tech in a while. As I am still in the process of transitioning from a software engineer to a UX person, I thought it would be good to share a bit about how we use Github to work as a team.

I personally feel that designers that work closely with engineers in a team is a great thing. Designers should learn the basics of how to add assets to projects and how to upload files into Github for collaboration, as well as some basic coding. However, this isn’t always the case, but that is a discussion for another post. I really enjoy having a  mix of both jobs, not only as it’s fun and very rewarding being able to focus on design and still code as well, but it’s also a massive benefit to the team and saves developers time on menial tasks, overall resulting in a better product.

Anyway, I digress.

Our strategy (I’m not sure whether it has a name) helps us as a team collaborate with each other, stakeholders and our users. Our main branches are develop, staging and production. All of these branches have fully functional production code with test coverage and CI. We all get a new build release when any code is pushed to any of these branches.

Develop – Developer code. Developers use this as our base branch – this is where we will branch off from when beginning a new feature. Developers only get notified when code is pushed into this branch. Develop is then pushed into staging.

Staging – Stakeholder’s view this branch. When our feature(s) are in develop and ready, they are pushed into staging and a new build is released for stakeholders to view, where they can check everything is as it should be. Staging data is used. Once approval has been gained, staging can be merged into production.

Production – Our master branch. Full production code, released to users and uses live data. Devices with an existing version of the application will be prompted to update (if native), else changes will be seen on web-apps instantly. Developers, stakeholders and users all get build notifications from production.

When all of this has been setup for a project and we get new features in to produce, we begin by branching off of develop. We name our branches according to whether our tasks are features, chores or bugs. Multiple tasks can be worked on at once across the team, but regular pulls from develop are needed to minimise build conflicts. Rarely, if multiple devs want to work on the same feature, a feature branch will be created and this can be branched off (see diagram). This can be useful if someone is halfway through a feature branch and something else is needed from another team member to complete the feature. Of course, multiple developers can always work off the same feature branch, but I prefer to branch off to minimise problems.

Before any branch is put into develop, a pull request is submitted and (a) member(s) of the team will review and then push to develop. Sometimes there can be merge conflicts, but these can easily be solved using git mergetool.

Rarely, we will have a problem with merging staging into production (native Android has been giving us this problem mainly due to conflicts in the manifest file with version numbers). It can seem daunting when having merge conflicts going into production/master, so here are the steps we use to solve this:

  • Make sure staging and production are FULLY up to date with their remote branches (git pull origin).
  • Pull production INTO staging.
  • Open up git mergetool when prompted and fix the merge conflict in the editor part of the program (if version number, when in doubt use a higher number).
  • Commit changes to staging.
  • Pull request from staging into production: all should be able to merge automatically.

I am aware that many dev teams use different strategies in git but this is the one that works best for us. I recently worked in a team that used git flow and found it not to be as effective, but each to their own. Also, always remember to use git prune 🙂 too many branches gets confusing!

Digital Stores Hackathon

For three days, the engineers in Digital Stores worked out of office in our Retail Academy above the Pantheon store to do a team hack. We broke off into four small teams, each with members of varied skill sets. We were all assigned a problem that either staff or customers would have while in store. Some problems included:

“Customers often want to buy products that are now no longer available.”

” Staff have to use multiple systems to update their store opening hours.”

Having a variety of skills in our team, we played on each other’s strengths and wrote a native Android application to help customers find similar products to ones that are no longer available.

We began by creating personas and investigating what our customer journey currently is when coming into store.

Alto App copy.003

From this we concluded that to increase the likelihood of a customer buying an item, we needed to provide a quick and easy way for staff to assist customers in finding a relevant, alternate item. From this we came up with the solution of a staff assistant to either scan a code or enter a t number, which would then pull relevant data such as size, category etc. and display similar, available items.

The customer could then be shown the available products and then view and filter down what they would like. They could see if the product was available in store and if not order it online.

We managed to get all of this functionality working in Android within three days: from choosing the solution to full functionality along with presentation materials. This wasn’t only a valuable experience from a product point of view, but it gave us some insight into some of the struggles that store staff and customers face on a daily basis. It also gave us the chance to work with people that we haven’t worked with before (including a non-technical team member) and to learn about everyone’s skill sets.

One of the other projects was store opening hours. Store opening used Django based implementation of the current store opening hour system. It was designed to allow the user to update or search for store opening hours. However, there was no single point of truth for the data. A stakeholder was contacted and communicated with throughout this hack, so the project could be driven from her needs and experience.

Python was then chosen as the technology stack, mainly due to a team member being very confident and strong with this language. We implemented a simple Django API with a plugin front end. Due to time limitations of the hack week we decided that this was the best choice.

Although not all of the innovations turned into full projects, creating a solution for store opening hours was so successful that it went onto become one of our main projects and we spent several sprints creating a system that is now complete and being trialled in stores today. For this project, there were a few blockers but these were mainly ironed out during the hack, paving the way forward for the full project.

If you like the sound of what we are doing, then head on over to to see our blog and current job openings. Join us!

Techie Tea Party

Every year, I organise for myself and a team of volunteers to visit a local elderly people’s home in Paddington for a day to help the residents with their IT problems. We are allocated one day of volunteering a year so I choose to use it working with the elderly, who often get forgotten about. A few of us from the Digital Stores team were able to utilise our skills to really help make a difference in people’s lives. We brought along some M&S cakes and sandwiches to make it into a ‘I-Tea Party’.

12646612_1199973720029970_583390018752028716_o 12622458_1199973836696625_164010367630087385_o

I had some help setting up the day from the charity ‘Time for Paddington’, who do some excellent work in the local community helping all sorts of people with the aid of volunteers.


The range of technological issues ranged from things as simple as sending a text message, all the way to creating and editing a video using specific software. All of the residents were thrilled with the day and in the end we managed to help over 40 people. Some people just came in for some cake and a chat, but when so many elderly people are isolated with limited social interaction, an event like this really made their day.

One member of the team also went the extra mile: a gentleman came in with an iPad outside of warranty and with an extremely outdated iOS. We tried to update the iOS but the iPad kept crashing and it was very puzzling why. As we couldn’t figure it out during the day, one member of the team took the iPad home with him, fixed it up in his own time and delivered it back to the gentleman at his flat the next day. Talk about top notch service!


This was also a great way for us to understand our core customers. Being able to observe the way they operate technology and understand the way they think is vital for us to improve our products through technology to make them more usable.

A big thank you to the team who volunteered. We have now set a trend since our first year and other companies have also started holding techie tea parties for the elderly. Was a wonderful day as always and we will hopefully be doing the same thing again next year!


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 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! 🙂