Just-Eat spectrum-bottom spectrum-top facebook google-plus instagram linkedIn pinterest reddit rss twitter_like twitter_reply twitter_share twitter_veriviedtwitter vimeo whatsapp youtube error_filled error file info-filled info loading star tick arrow arrowLeft arrowRight close download minus-filled minus move play plus-filled plus searchIcon settings

Tag : product


Beautiful Rooms & Why Smartphones Are Too Dumb

Some time in the future, the age of the smartphone will draw to a close and experiences will become more in-tune with the way humans actually live. We need to be thinking about this new wave of interactions at a time when our customer’s attention is a premium. We need to be augmenting their worlds, not trying to replace them…

I’m Craig Pugsley – a Principal UX Designer in Product Research. Our team’s job is to bring JUST EAT’s world-leading food ordering experience to the places our consumers will be spending their future, using technology that won’t be mainstream for twelve to eighteen months.

It’s a great job – I get to scratch my tech-geek itch every day. Exploring this future-facing tech makes me realise how old the systems and platforms we’re using right now actually are. Sometimes it feels like we’ve become their slaves, contorting the way we want to get something done to match the limitations of their platforms and the narrow worldview of the experiences we’ve designed for them. I think it’s time for change. I think smartphones are dumb… I feel like we’ve been led to believe that ever more capable cameras or better-than-the-eye-can-tell displays make our phones more useful. For the most part, this is marketing nonsense. For the last few years, major smartphone hardware has stagnated – the occasional speed bump here, the odd fingerprint sensor there… But nothing that genuinely makes our phones any smarter. It’s probably fair to say that we’ve reached peak phone hardware.


What we need is a sea-change. Something that gives us real value. Something that recognises we’re probably done with pushing hardware towards ever-more incremental improvements and focuses on something else. Now is the time to get radical with the software.

I was watching some old Steve Jobs presentation videos recently (best not to ask) and came across the seminal launch of the first iPhone. At tech presentation school, this Keynote will be shown in class 101. Apart from general ambient levels of epicness, the one thing that struck me was how Steve referred to the iPhone’s screen as being infinitely malleable to the need – we’re entirely oblivious to it now, but at that time phones came with hardware keyboards. Rows of little buttons with fixed locations and fixed functions. If you shipped the phone but thought of an amazing idea six months down the line, you were screwed.

In his unveiling of the second generation of iPhone, Jobs sells it as being the most malleable phone ever made. “Look!” (he says), “We’ve got all the room on this screen to put whatever buttons you want! Every app can show the buttons that make sense to what you want to do!”. Steve describes a world where we can essentially morph the functionality of a device purely through software.


But we’ve not been doing that. Our software platforms have stagnated like our hardware has. Arguably, Android has basic usability issues that it’s still struggling with; only recently have the worse Bloatware offenders stopped totally crippling devices out-the-box. iOS’s icon-based interface hasn’t changed since it came out. Sure, more stuff has been added, but we’re tinkering with the edges – just like we’ve been doing with the hardware. We need something radically different.

One of the biggest problems I find with our current mobile operating systems is that they’re ignorant of the ecosystem they live within. With our apps, we’ve created these odd little spaces, completely oblivious to each other. We force you to come out of one and go in the front door of the next. We force you to think first not about what you want to do, but about the tool you want to use to do it. We’ve created beautiful rooms.

Turning on a smartphone forces you to confront the rows and rows of shiny front doors. “Isn’t our little room lovely” (they cry!) “Look, we’ve decorated everything to look like our brand. Our tables and chairs are lovely and soft. Please come this way, take a seat and press these buttons. Behold our content! I think you’ll find you can’t get this anywhere else… Hey! Don’t leave! Come back!”

“Hello madame. It’s great to see you, come right this way. Banking, you say? You’re in safe hands with us. Please take a seat and use this little pen on a string…”

With a recent iOS update, you’re now allowed you to take a piece of content from one room and push it through a little tube into the room next door.

Crippled by the paralysis of not alienating their existing customers, Android and iOS have stagnated. Interestingly, other vendors have made tantalizing movements away from this beautiful-room paradigm into something far more interesting. One of my favorite operating systems of all time, WebOS, was shipped with the first Palm Pre.


There was so much to love about both the hardware and software for this phone. It’s one of the tragedies of modern mobile computing that Palm weren’t able to make more of this platform. At the core, the operating system did one central thing really, really well – your services were integrated at a system level. Email, Facebook, Twitter, Flickr, Skype, contacts – all managed by the system in one place. This meant you could use Facebook photos in an email. Make a phone call using Skype to one of your contacts on Yahoo. You still had to think about what beautiful room you needed to go into to find the tools you needed, but now the rooms were more like department stores – clusters of functionality that essentially lived in the same space.

Microsoft took this idea even further with Windows Phone. The start screen on a Windows Phone is a thing of beauty – entirely personal to you, surfacing relevant information, aware of both context and utility. Email not as important to you as Snapchat? No worries, just make the email tile smaller and it’ll report just the number of emails you haven’t seen. Live and die by Twitter? Make the tile huge and it’ll surface messages or retweets directly in the tile itself. Ambient. Aware. Useful.



Sadly, both these operating systems have tiny market shares.

But the one concept they both share is a unification of content. A deliberate, systematic and well executed breaking down of the beautiful room syndrome. They didn’t, however, go quite far enough. For example, in the case of Windows Phone, if I want to contact someone I still need to think about how I’m going to do it. Going into the ‘People Hub’ shows me people (rather than the tools to contact them), but is integrated only with the phone, SMS and email. What happens when the next trendy new communication app comes along and the People Hub isn’t updated to support the new app? Tantalizingly close, but still no cigar.

What we need is a truly open platform. Agnostic of vendors and representing services by their fundamentally useful components. We need a way to easily swap out service providers at any time. In fact, the user shouldn’t know or care. Expose them to the things they want to do (be reminded of an event, send a picture to mum, look up a country’s flag, order tonight’s dinner) and figure out how that’s done automatically. That’s the way around it should be. That’s the way we should be thinking when designing the experiences of the future.


Consider Microsoft’s Hololens, which was recently released to developers outside of Microsoft. We can anticipate an explosion of inventiveness in the experiences created – the Hololens being a unique device leapfrogging the problem of beautiful rooms to augment your existing real-world beautiful rooms with the virtual.


Holographic interface creators will be forced to take into account the ergonomics of your physical world and work harmoniously, contextually, thoughtfully and sparingly within it. Many digital experience designers working today should admit to the fact that they rarely take into account what their users were doing just before or just after their app. This forces users to break their flow and adapt their behavior to match the expectations of the app. As users, we’ve become pretty good at rapid task switching, but doing so takes attention and energy away from what’s really important – the real world and the problems we want to solve.

Microsoft may be one of the first to market with Hololens, but VR and AR hardware is coming fast from the likes of HTC, Steam, Facebook and Sony. Two-dimensional interfaces are on the path to extinction, a singular event that can’t come quick enough.


The minimal form (part one – the explanation)

Before we start, you’ll notice I’ve named this blog part one – I plan to deliver a series of posts over the coming weeks, and this is primarily so you can see my progression and how my learning amplifies as I dig deeper into the topic of the minimal form. But, at this point you’re probably wondering what the minimal form is. So without further ado…

The minimal form (or single input field) is a new way to display and interact with form fields. It is essentially a single form field that switches and changes to suit the desired input once a user submits their information. It’s primary purpose is to simplify the form filling process, whilst keeping it engaging and less tiresome.

Here is a great example I’ve grabbed from the web, which outlines the concept in full.

These types of forms aren’t limited to capturing basic information like name, address or telephone number. They can be implemented to enhance the form filling process for far more complex information, such as credit card or payment information.

Furthermore, there are a few companies who are currently taking full-advantage of the minimal form to create engaging and easy form filling questionnaires, such as Typeform.

What’s the benefit for your users?

Sure, the majority of these forms dotted around the web are simply seen as nice to haves or delightful elements. However, there are certainly some initial wins from a user experience perspective when it comes to the minimal form, especially beyond first glances.

For example, the most tangible benefit of a minimal form would be for mobile devices. As you can see, I’ve included a screen that outlines the skeleton of a common mobile web form.

You can see the canvas space that designers have to play with, when they’re specifically considering form fields in the design process.

In 2016 it is considered common practice to simply collapse information to fit onto mobile. However, when you do this, spatial problems arise, and to maximise product objectives designers and engineers can minimise extensive clutter in multiple ways. For example, you can stack content below the fold, hide it amongst tabs, accordions or drawers. Ultimately, these solutions are seen as functional in most cases, which is great for mobile users across the web.

However, at JUST EAT, the UX team don’t just aspire to build experiences which are simply functional. As a collective team, we aim to build, explore and innovate these kind of experiences to help us empower our users to love their takeaway experience.

Ultimately, this means it’s our job to ensure we’re making experiences which are functional, reliable, usable, as well as pleasurable.

JEUXSubsequently, we’ve identified that minimal form is certainly an interesting area which could push the usable and pleasurable aspect of our product, whilst retaining that functional and reliable foundation.

There’s no denying that minimal form (for mobile, at least) has multiple benefits from a user perspective…

  • It allows users to concentrate their effort on one form field at a time.
  • Ensures the user is not overwhelmed with the sheer amount of information he/she may or may not be required to submit.
  • No/minimal scrolling required.
  • Less tapping/frustration.
  • We assume it will be a quicker experience for our users – although, it would be interesting to see if this is the case via user testing. Perhaps it’s actually a longer process, but is perceived to feel quicker?)


An assumption might be, if you’re only focusing at one form at a time, would the information submitted be more accurate from your user base? We’ll dive deeper into the kind of metrics a minimal form could improve in part two…

Some disadvantages…

There are certainly some disadvantages to the minimal form concept. For example, how would you display an error state? Would a user have to go back if their password confirmation was wrong? Surely that would go against the progressive motion of the minimal form?

Furthermore, it’s great not having to see all of the forms you have to fill, but how would you check to ensure all of the information was correct before submitting?

Also, what place does the minimal form have on desktop? What tangible benefits does implementing a minimal form have for desktop users? And finally, how many people using this form for the first time will know how it works?

I’m confident that these are problems that can be solved when implemented in a user flow with a bit of intuitive design thinking.

Ok, so where would you start?

Well, you’ll have to stay tuned for part two where we look at implementing something similar to the minimal form as we continue to enhance our product, and help implement a more usable and pleasurable experience for all things mobile.



Product management in country improvements

Product management can be a difficult role to define. Most companies have a slightly different view of what a product manager should do, and so the definition (and even job title) of a product manager will often vary between organisations. It is also the case that within the same organisation different areas of the business can evolve their product management positions in different ways, as is the way at JUST EAT. And this is fine, as product managers are typically people who are willing and able to adapt themselves to the needs of the team(s) they work with and the products they manage.

Technology at JUST EAT is split into eight core areas, one of which is International Product Development (IPD), which I work in. Each area has their own focus and each have evolved independently in terms of their requirements of product management. However, we’re all working towards a common goal – to build a JUST EAT experience for consumers and restaurant partners that delivers against our mission to “Empower consumers to love their takeaway experience” and supports our restaurants to become as successful as possible.

So what’s working as a product manager in JUST EAT like? As product manager of the International Advanced Market (IAM) team it’s my responsibility to ensure the team is supporting the group of advanced market countries (Denmark, Norway, Ireland, Belgium, Netherlands), together with my team’s technology manager. The support my team provides is underpinned by our mission statement:


All this sounds very nice, but what does it mean in practical terms? On a day-to-day basis my job as a product manager can be broken down into the following areas:

  • Supporting the team
  • Partnering with the countries
  • Looking to the future
  • Personal development

Supporting the team

This is what I would call fundamental product management. It’s the core task of requirement definition (in whatever form it takes) and prioritisation. In the IAM team we use the Scrum framework for development and this covers user story creation, backlog grooming, sprint planning and representing the user. It’s a privileged position, working between my colleagues in Tech (engineering, UX, QA), Business Intelligence and the teams in the countries, bringing together lots of different skills to create an awesome product.


With such a fast-paced environment at JUST EAT this aspect of the job is very demanding, but with such highly skilled people across all of Tech this is also extremely rewarding, and continually delivering tangible improvements gives me the drive to keep on pushing the bar even higher.

Partnering with the countries

Each of our businesses around the world are run independently, managed by local teams who understand their market and drive success. With all product development resource based in the UK and Kiev it’s critical that we stay closely aligned to their businesses and understand what’s happening in their local markets. We have regular calls with the country teams and collaborate on requirements and prioritisation (see my previous blog post – Tools for International Communication to Manage Technical Change), share market research and data analysis as well as experimenting with changes to the site/apps to see what works for users in different countries.

The remit of the team I work for requires additional responsibility of understanding and representing the countries I support. With so many teams across Tech delivering changes at breakneck speeds, I get called upon to ensure country specific requirements and nuances are not lost in the continual improvement happening across the platform. It’s an immensely satisfying part my job and comes with added benefits of regular travel to visit the country teams.

Looking to the future

It’s easy to fall into a trap of only focusing on what you have in front of you, fire-fighting today’s issues while forgetting you need to be planning what comes next. There are times when this might be the correct move but you need to be conscious of it and take action.  JUST EAT plan on a quarterly basis using the OKR methodology (we’ve even built our own tool for managing them – Managing OKRs at JUST EAT tech with our own web app) and so it is paramount that the product managers maintain that roadmap and vision for what comes next – not just the following quarter but for the next year or more. Of course your plans change, that’s the great thing about working in such an agile company, but having that draft plan to start with is key to figuring out what’s changing in the marketplace and how you should react.

We’ve adopted some of the templates created by Roman Pichler and adapted them for our own requirements – for anyone looking to instill some structure into their planning for agile teams this is a great place to start. We’re continually developing our templates and have established a great framework within IPD for planning and communicating our vision for the future.

Personal development

Personal development is a big deal at JUST EAT, and all employees are supported to create and maintain a personal development plan to achieve their career aspirations. The document leads with the question “Where do you want to get to?” and helps you create a plan to get there. This is backed up with personal OKRs and a training budget of £1,000 each year to spend on the resources you need to support your development plan. It’s great to work somewhere that values people development so highly, and backs that up by empowering you to take true control of it.

In summary

JUST EAT is a fantastic place for product managers – there is so much energy and enthusiasm, a ton of exciting work happening across the company, and it’s immensely satisfying to be working for a company that truly understands what product management is all about.


Designing at JUST EAT

A while back I joined the JUST EAT UX design department to work in the Strategic Projects team. Working at the world’s leading digital marketplace for takeaway, with 11 million active users, and generates around £1 billion for the restaurant industry, is definitely a huge responsibility and it comes with a lot of challenges.

We design experiences to shape the future of food and technology. Our main focus is empowering consumers to love their takeaway experience, and everything we do is revolved around this idea. Working here means that you have to be frank, innovative, hard-working, and most of all, passionate.

Now let me give you some more insights.


The design process

Here at JUST EAT we don’t do design just for the sake of design. Our job is to understand the user’s problem, propose a hypothesis, research and validate, establish a testing approach and deliver a solution. All these can fit into three simple questions — what, who and how?

  1. What problem are we solving?— Being a designer means that we have to solve user problems while generating real business value. In terms of JUST EAT, that means improving the experience, building new features or identifying new opportunities that are easy to scale.
  2. Who are we addressing? — Creating personas based on qualitative and quantitative research. This is helping us figure out how our ideas are gonna fit into the real world, and will make it easier to validate those, or prioritise features. (Such as helping time sensitive customers get their food faster.)
  3. How are we solving it? — The third step is figuring out a way to solve the problem. This means doing research, validating ideas, prototype, design, test, and deliver. We’re not just sitting in front of a computer, we’re ‘getting our hands dirty’ by analysing data, having focus groups, doing usability testing, and so on. Most of the times we have to take small steps — like releasing a quick fix for a much bigger problem, until we can actually gather enough data to solve it properly.

We’re not alone on this though. Some of the best product managers, researchers, developers and other UX colleagues are gonna have your back. After all, one of our four values is ‘team’.



JUST EAT is growing fast. In 2015 we hired actively on all fronts, with 156 new employees. The UX team is now formed of 11 designers working between London and Bristol.

Before showing how we nailed this collaboration, let me give you some insights on how we work:

  • Cross-platform — Every designer that’s part of our team knows how to work for web, iOS and Android. We try to embrace the platform, using the native behaviour as a starting point (based on the human interface/material design guidelines). Once in awhile we get overly excited and get involved in different small projects, like designing for Xbox or tvOS.
  • Vertical teams — We’re split between autonomous teams, focusing on different objectives (Customer Acquisition, Retention, Strategic Projects, and so on). Most of the teams are formed of a Technology Manager, Product Manager, Business Intelligence, UX and Development — all working together to achieve the team’s OKRs.
  • Agile — The same as most big companies, we’re guided by agile methodologies in order to allow incremental, iterative work between self organising, cross-functional teams.



Focusing on various objectives between two different cities makes it tricky to collaborate. There is no proper recipe on ‘how it should be done’ but along the way we realised it’s a mix of transparency, communication, and honest feedback.

  • UX sync — Every week we have a general sync with all the design teams at JUST EAT. Everyone has to share ‘what they worked on’, ‘what they learned from it’ and ‘what’s the next step’. This way we make sure there are no overlapping projects and that we can get feedback before sending things to production.
  • HipChat Room — We have a dedicated room for design conversations where we ask for feedback, share opinions, or post random gifs.
  • Short catch-ups — Whenever we feel like we need to get a better understanding of something, we have a short hang-out. These are regular things at JUST EAT and it helps smoother transition between two projects built by different teams.
  • UX guidelines— A short while ago we created our first JUST EAT guidelines (still a work in progress). Working across 15 countries on different features, and in separate teams, makes it hard to be consistent. These guidelines are helping us achieve that consistency — leading to a unified product.



All work and all play

JUST EAT has a reputation for being an fun and exciting place to work. Having a proper work-life balance is what helps us create a healthy environment, so finishing work at 4.30pm on Fridays, playing ping-pong, FIFA, or fussball are just regular activities here. And apart from the odd free takeaway, everyone brings cookies when they come back from holiday.

I hope this article gave you a bit of an understanding on what happens under the design curtain here at JUST EAT. And just so you know — we’re still on the look for great UX designers.


The road to responsive web

The benefits of moving JUST EAT International sites to a responsive web design are pretty clear. In a nutshell, responsive web design means that if a user switches between viewing your website on a Mobile device to viewing on a Desktop, the website should automatically adapt to cater for the different resolution.  This is all achieved through things like CSS media queries and fluid grid layouts.  

Screen Shot 2015-11-25 at 10.34.35

Responsive Web – a ‘fluid’ design means your site should adapt for different resolutions and devices.

But, as well as the customer facing benefits, responsive web also provides efficiencies of scale from an engineering point of view – by moving to one common code base for all our international sites means we can develop features and enhancements more efficiently.  

That said, rolling out a completely new version of a JUST EAT website is bound to cause some sort of nervousness and its down to the International Product teams to manage this to ensure that the countries feel confident about the change and supported at every stage.

As the Product Manager in the team that has rolled out responsive web in Denmark and is in the process of getting the Canadian responsive website live, I thought it was worthwhile to share the experiences I’ve had and the steps taken to make sure the roll out of responsive web was a success.

Gap analysis
The starting point is to identify the features or requirements for the country. Whether it be sales tax in Canada or integration with a specific delivery service in Denmark, the earlier you identify the unique requirements up front, the earlier you can consider them as part of your scope.

Story development and prioritisation
With our scope defined, we followed the principles of grooming the stories with the team and prioritising the stories based on what was the minimum required in order to get a beta version of the site ready and in front of staff to place real orders.

Automating the testing as much as possible
We created our acceptance criteria in the ‘given, when, then’ format, so the acceptance criteria could help form the basis of our Gherkin based feature files. Together these become our Executable Specification. We implement the feature files in .NET using SpecFlow and Selenium WebDriver to automate functional testing and identify regression issues more efficiently. Having experienced working in development teams where testing wasn’t automated, it can’t be underestimated how much time and effort can be lost without automation.  

Stakeholder engagement
Once we’ve developed the responsive web version of the site that meets our MVP definition, we will demo the site to the country. These sessions are really positive as the countries can start to see the benefits that the new responsive website will give them.  

After the demo, we will then get the ‘green light’ to launch the site to a group of internal staff members, eg beta and running through the process of collecting feedback

Establishing a phased roll-out approach
Our approach typically takes four stages, beta, 10% of customers, then 50% and 100%. Beta, involves launching the responsive website to a set group of internal staff from the country team, where we set up a feedback form for the country to feedback issues they’ve faced, or general comments. Moving beyond beta through to 100% of customers, is largely based on how quickly we resolve defects identified during beta.

Daily triage and defect prioritisation calls
When it comes to the point of trying to move from 10% to 50% to 100%, I’ve found it particularly useful to run daily triage calls with the country to help establish a priortised view of the defects and, most importantly, an agreed accepted level of outstanding defects before going to 100%.  When you have this agreed target, it’s far easier to motivate everyone to reach that goal!

Once we’ve gone live with beta, we verify that conversion events are being successfully recorded, but we are also make sure that we set up our reporting dashboards in advance so we can report back to the country about how the responsive website is performing versus the legacy website in each step of the funnel. Being proactive with this type of analysis also helps when pushing from 10% to 50% to 100%.  

Efficient defect resolution
To ensure clarity and expected resolution for defects, I would discuss the detail of the issue with the country and replicate myself. Then, by detailing the current behaviour and expected behaviour of the issue, the dev team team were able to rattle through the prioritised defects and in the majority of cases resolve them first time. This quality output also helped to give the country team confidence that we would deliver against our promises and suggested ETAs.  

Based on our experience with Denmark, from the start of the development process through to going live to 100% of all customers has taken 6 to 8 weeks. When you sit back and think about it, 6 to 8 weeks to roll out a completely new version of a fully functioning website across desktop, mobile and tablet, that’s pretty cool huh?! #minifistpump