Making takeaway ordering responsive

One of my first projects when I joined Pretty as a junior designer back in the mid-noughties, was to work on UI designs for an online takeaway ordering site. Years before the big names hit the big time, my client had a great idea. Small takeaways without the budget or know-how for how to organise their own online ordering system could use their offering to provide their customers with food that they could order without having to pick up the phone. Years later they returned to me and my team with a new brief. The age of the smart phone meant that they needed a new responsive solution, to cater to an audience that expected to be able to order from their mobile devices, from the comfort of their sofa.



I took a leading role in this project, working together with a technical lead to ensure ideas were realisable.


"Before Just Eat and Hungry House even existed, they were offering a complete service to take-away owners."

My client were revolutionary. Before Just Eat and Hungry House even existed, they were offering a complete service to take-away owners. The whole system, the website front-end, even flyers and marketing advertising the restaurant's new online offering. Their clients loved it, and loved the fact that it was customisable. So unlike others in the same field, take-aways could have a site that looked like their own, with their own branding. And users loved it too. The client had had some fantastic feedback on the original offering, with customers loving its ease of use. But times had changed since we worked with them first, and people expected the site to work on laptops, tablets and mobiles, as well as on desktop computers. So we were asked to take what we had done originally and use it to build upon to create a responsive experience, taking this as an opportunity to re-address usability and functionality.

Detailing existing information architecture

Detailing existing information architecture

From here, myself and my team undertook a period of research. The client had documented some excellent user insights - as a small company they had one-on-one contact with many of their clients and customers so were able to come to us with a host of information that we could sift through. It became clear after our conversations that the current system had a good balance of useful functionality with intuitive journeys, and they were keen not to overcomplicate things.

"One of the biggest insights they gave us was that a large proportion of their users were older and less digitally savvy."

One of the biggest insights they gave us was that a large proportion of their users were older and less digitally savvy. They knew the takeaway down the road that they liked, wanted to use that, looked it up and there it was online, available to order from. They didn't want anything flashy, just a system that let them order without fuss.

Further research enabled us to divide the core audience up into two distinct groups:

The 2 audience groups

The 2 audience groups

We discovered that they main things both audience types wanted from the offering were for it to:

  1. Be faceless
    On the whole, users don't really want to interact when ordering takeaway online. They want to get in and get it done, without having unnecessary barriers or questions asked. And they certainly don't want to have to be in a situation where they have to ring the takeaway with queries or to confirm anything.

  2. Be easy to browse
    Up-front, easy to view choices are what users want from their takeaway website. True, they may know what they want to or usually order, but they also want to browse and see what the options are. They want to be able to see a running total and, when they are done, to be able to check out without fuss.
  3. Be quick to use time and time again
    With a large proportion of users returning time and time again, checkout should be as fast as possible, with the option to save details for the next visit.
  4. Be customisable
    People's food likes and dislikes are a very personal thing! Users want the option to add notes to their order specifying changes, dietary requirements, or just how to find their address.


"The main thing was to simplify the flow for mobile - it needed to be single featured because visually it’s very different to desktop."

Having delved into the research, some key points became clear. The main thing was to simplify the flow for mobile - it needed to be single featured because visually it’s very different to desktop - there’s less room and it requires a completely linear flow to work seamlessly. It needs to replicate the existing process on a mobile device, with features that work specifically on phones and tablets. With this in mind, I set about drawing up low-fidelity wireframes detailing concepts and flows, which brought up some specific ideas that I thought could work well. These included:

  • Geo-location based 'do we deliver? functionality'
  • Recommended takeaways if delivery is unavailable
  • Alerts when a takeaway starts delivering in your area
  • 'Have your forgotten?' prompts
  • 'Other customers have also ordered' prompts
Assessing low-fidelity wireframes

Assessing low-fidelity wireframes

Going back to the original brief of keeping it simple, we decided that we'd had some interesting thoughts but many were distracting, so they went!

Drawing up concepts as quick sketches is never wasted time, doing this allowed me to work ideas through fully and quickly. It also meant that I could discuss them with my team, keeping those we thought worth presenting, chucking out those that had problems or weren't necessary. Many of the ideas were ditched! Going back to the original brief of keeping it simple, we decided that we'd had some interesting thoughts but many were distracting, so they went!


With a clear idea of what we wanted to prototype, I set to work building and interactive wireframe version in Axure, with key functionality and journeys detailed. Drawing it out on paper is one thing, but once it's working on a mobile and in your hand, it's quickly clear what tweaks need to be made to things like navigation, button sizes and flows. Together with my team, we discussed the prototype at every stage, ensuring things worked from a usability and technical point of view. This agile process meant that we could iterate quickly, and led to us realising a few things:

  • Geo-location was an unnecessary feature as users know their postcode and are generally know their local takeaways
  • Forms and button labelling needed streamlining
  • Language and actionable steps needed making clearer
  • Navigation needed reviewing
  • Some added features were a good thing, like having saved orders up front when logged in

This prototype was then presented and discussed with the client, who took it to further testing, internally and with some users. Further revisions and an agreed prototype later, I set to developing visuals.

Interactive prototype

Interactive prototype

Testing the interactive prototype

Testing the interactive prototype


Developing visuals for the site was quite a specific task. As each takeaway could customise their site, I had to develop up-to-date visuals that could work across the board. And as we were creating responsive templates it made sense to work mobile first.

Mobile visuals

Mobile visuals


With a happy client, they went away to implement my work into their offering in order to test with users.