2021-04-06

Creating a great UX & Design case study

This post originally appeared on FanDuel Life blog.

Photo by Daria Nepriakhina on Unsplash

When you apply for a position on the UX & Design team at FanDuel, we ask you to send at least one case study with your application. (Things are different when we hire for entry level positions, more on that in the future). While the specifics of the work will depend on your role as a product designer, UX researcher, or UX writer, the principles of that case study are the same.

What is a case study?

It’s an explanation of a real project you’ve completed. It frames the problem or opportunity, explains your approach, process, and involvement, and showcases the solution.

But I have a website/portfolio/Behance…

Great! If that portfolio has case studies as part of it, send that. However, sometimes we see great solutions-only portfolios from candidates that don’t show all the important details and process of the projects. All the disciplines in the UX & Design team — product design, UX research, and UX writing — require a lot of collaboration, choosing the right tools for a given project, and execution far beyond just a visual element to be successful.

Why do you ask for one in my job application?

It helps us understand your role in the projects you’ve worked on. What did you contribute, what are your processes and understanding of those processes, and how successful was the solution? More on the details later.

Our hiring process has three stages and we assess different skills and experience levels at different stages. As part of the first stage where they review your application,four team members will look at these areas, which form part of our career path framework. One of our hiring principles is We hire at the right level and know that very few candidates are the finished article, so we want a strong framework to assess that level.

  • Functional knowledge — Can you demonstrate high quality work?
  • Process — Do you have an understanding of standard industry processes and when to use them?
  • Complexity — Do you understand the constraints and outcomes of the project?
  • Scope — Did you have the appropriate level of involvement in the project for the experience level we’re hiring for?
  • Presentation — Can you clearly communicate your projects and how you did your part, while explaining your decisions and constraints?
  • Suggested experience — Do you have relevant experience at the level we’re hiring for?
Digestible sections from Uber Scooters case study by Bre Huang

What makes a successful case study?

The short answer is a study that helps us see the best of your skills and experience based on the criteria above. There’s no one template for a successful case study, and it will depend on the project you’re showcasing. We find that the information below forms the basis of a lot of successful studies:

  • What was the problem/opportunity/brief/reason for the project?
  • Who were the users?
  • What was your role in the project?
  • What were the processes you used from start to finish to deliver your solution?
  • What were the decision points and how were decisions made?
  • What were the constraints and limitations of the project?
  • What was/would be your next step?
  • What did you learn and what would you do differently next time?

We often get asked about formats, too. To us, a successful case study is a successful case study, regardless of format. Send us a PDF, a website, a Behance page, a Medium post or whatever presents the work best for you.

Show your process — Promo.com case study by Sascha Yeryomin

Got any examples?

Of course! Here’s some inspiration hand-picked by members of our team. Please don’t just copy these though. Every project has its own unique challenges and solutions, and your case study should reflect that.

Product design

Uber Scooters by Bre Huang
“This a great example of documenting an end to end process in a clear and legible way, demonstrating that design thinking was undertaken. There is real attention to detail throughout — the animated interactive screens are the icing on the cake!” — Jonathan Wilkinson, Lead Product Designer

UX research

Sex and/or gender — working together to get the question right by Jane Reid
“This does a good job of giving a bit of depth without being too long. Also appreciate the visuals to help envision the process better.” — Yasmin Amjid, Senior UX Researcher

UX writing

Contributor Style Guide by Nikki St-Cyr
“I think this is a good example of a case study where the output isn’t actual UX copy, but a content style guide for all the UX writers. Like a design case study, it’s solution-oriented, presenting the problem, solution, process, and implementation in a plainspoken way and concise way that makes the writer’s impact pretty clear to me.” — Melissa Warren, UX Writer

iTunes by Darci Groves
“Darci’s site showcases really juicy problems as short case studies (removing the U2 album from iTunes!). As a UX writer and team leader, she offers clear, concise language and empathy to advocate for both the business and the end user.” — Natalia Lavric, UX Writing Manager

2018-11-19

Design, systems, people

I was very pleased to be asked to speak at World Usability Day 2018 in Poznań, Poland. I was asked to speak about design systems, but with so much information already out there about the theory and technical points of creating and maintaining a system, I wanted to talk about how those systems affect people. The people who use the products that we build using our design system, but also the people who use the system to build the products. The customers of your design system product: designers, developers, third party suppliers, and more. How can we maintain a system that's usable by those people, so they can and will use it to its full extent? My slides are above. 

2014-12-12

Web designers: consider using a bad monitor

This post originally appeared on the Storm ID blog.

That's an odd thing to suggest, isn't it? We digital designers love us some shiny tech. From Retina MacBook pros or the new 5K iMacs to the latest hi-res displays from Samsung or Dell, what we view our work on is important to us, for better or worse.

There's only one problem: most people don't have fancy monitors like ours. The majority of our users have average-to-bad screens to view our beautiful designs on. That subtle grey you've used is lovely, but on that 5 year old, burned out, 19" Dell monitor that John in Accounts has, the grey looks white like the background, and your carefully planned visual hierarchy can fall apart and become confusing.

My nice screen and my bad screen, together forever

A few years ago I acquired an old 16" monitor from a cupboard, to be a second monitor for my 27" iMac. I tell people it was a place to put my email client and browser's web inspector while I worked on my main screen, but I think I actually wanted to stream the Ryder Cup while I worked one Friday. It is a handy place to put my email, web inspector, Twitter, Spotify and all that other stuff that helps me work but isn't actually work.

More than that though, I very quickly learned it was a great way to test designs. This monitor is small, low resolution by today's standards, has never been colour corrected, isn't nearly as bright as it once was, and has a couple of dead pixels. It's crap. But if I can put designs (created on my lovely iMac screen) onto that crap screen and they still work, then maybe they have a good chance of working for a lot of the users, too.

So if you have one or two big lovely screens to design on, consider running another bad screen too. You can probably find one at the back of an office cupboard somewhere, or pick one up on Gumtree for almost nothing. I guarantee it will improve the experience for your users in the long run.

P.S. This also goes for mobile screens. Add a small, low-res Android device to your test devices, or use a Device Lab. Most of your users don't have an iPhone 6+ or a Nexus 5.

2014-11-28

On Adaptive Design

This post originally appeared on the Storm ID blog.

There's some confusion from some of our clients about what adaptive design really is and if, when and how it should be used. Responsive design is all but the industry standard at this point, but what about adaptive?

Originally the term adaptive design was used to describe layouts which were very similar to responsive layouts, but with fixed widths instead of fluid widths. Some designers really liked that as it meant you could control line lengths and image sizes and that was handy when the industry was starting to get to grips with how all this new stuff worked. The main downside was that if you viewed these layouts in a browser window which was in between these breakpoints, you could have a lot of 'wasted' screen space. The experience didn't feel native to the device you were holding, which is the whole point of responsive design. For example we saw some tablets that were less wide than an iPad and the designer had only added breakpoints for iPhone size and iPad size screens, so you saw the 'mobile' sized site with lots of space either side. This method didn't lend itself well to the fluidity of the web and the mass of different device sizes. You had to use breakpoints that made sense for your current traffic which may not make sense in a few months when Apple or Samsung or Amazon bring out their new device with a different screen size.

The adaptive design that is talked about in many articles at the moment largely relies on Javascript (JS) to add in components to the document based on what it thinks it knows about your device. This can work, but has a couple of possible problems that are showstoppers for me.

Some articles advocate using JS to find your screen size. This is generally fine technically, but there can be problems with that. Screen size ≠ browser window size ≠ context ≠ device type.

Some advocate browser sniffing, where JS detects parts of the user agent string of your browser. This can cause huge problems. For various reasons, browsers often lie about what they are. This method doesn't allow for new classes of device either, without development updates.

OkCupid have a different use for browser sniffing.

Another big problem with many of these articles is that these techniques absolutely require JS. That's not too bad if it's server side (run on the website's server before sending the page to the browser), but if it's client side (run by the end user's browser as the page is delivered) then this can and will cause problems. Web browsers operate in a fundamentally hostile environment. If the end user's browser has JS turned on, and if JS runs successfully and in a timely fashion, then they may be delivered a relevant page, with the caveats above. If JS is turned off (unlikely but possible) or JS fails to run (device is struggling, internet connection is slow or fails) then, in many cases the user will be left with a sub-standard experience, or no experience at all in some cases. And slow connections are not just for mobiles. Think cafes with 50 customers and a weak router, or small internet cafes, or some rural areas, or people who have to deal with ISP problems all the time. Our company build large scale, award winning digital products, but we can't get decent wifi in one of our meeting rooms, and we spent the first week in our new office with a connection that was only okay if no one started a YouTube video or Spotify.

This is what squarespace.com looks like if JS is turned off or fails.

Running this stuff on the server and delivering components according to what it thinks it knows can be good idea in theory, though. Capital One talk about doing this with their sites, promoting different products to different device classes and locations. If you have a strong in-house team, both in development and marketing, and can tweak that regularly and test heavily, you could have . This can also have downsides. Many people will try to tell you that on a small screen you should change content because small screen = mobile = on the go. We know from (bitter) experience that this is not necessarily true any more, as more people move to not owing a traditional computer at all. On many of the kind of sites we produce, all content is as relevant on small screens as larger screens, so messing with that seems like a bad idea. Make an element less prominent, but removing it all together will just frustrate the people who need that element and only have mobile device (at least at that moment). How many times have you sat on your sofa and looked for something online on your smartphone, only to give up because the feature you need is missing, and getting up to switch on your laptop seems like a lot of effort?

Be careful about SEO. Google is putting less importance on content which is not visible by default on a page, such as tabs and 'read more' content. This could easily be applied to content that doesn't appear for all users. So be careful about selectively adding content that might be important.

Delivering different assets from the server depending on screen size is also a good idea in theory, as it means your browser only downloads what it needs to which cuts down on bandwidth, increases page speed and in turn engagement and sales. However, there are new HTML image specs which are usable in Chrome, iOS, Safari and Opera now, and are polyfill-able in other browsers, which basically do the same things with a bit more flexibility. They take away the need for fancy server configs too, which is especially great for prototyping.

The last, and perhaps most important point: What these articles talk about as adaptive design could fit into responsive design. The two are not mutually exclusive at all. Responsive design goes way beyond just fluid layouts that change at different screen sizes. It's also about performance and progressive enhancement, both of which are part of what they talk about adaptive design being. But that's another big blog post in itself.

The main thing is to use common sense and think about all kinds of users. Use progressive enhancement to first make it work, then make it work better. Don't rely on a user having all the technology that you hope they do, and have it working fully every single time. Be inclusive.

2012-12-06

Flash support on mobile devices

This post originally appeared on the Storm ID blog.

Most people who build for the web agree that trying to use Flash on anything to be used by mobile devices is a bad idea. Most people, however, don't keep up with the state of the web as closely as we do. In the last few weeks we've had a couple of clients ask us about adding Flash content to a site that will be used by mobile devices as well as traditional computers'. I have collated some information on the subject which might give you a better understanding of the current situation, or help you explain it your clients.

Mobile Flash Support

Mobile device use is on the rise, which means most websites are being visited by mobile users to some extent. Using Flash content in these situations should be avoided if possible, or at least used with an appropriate fallback.

Some stats from our clients' sites

International sport organisation's e-commerce site, last month

  • Mobile visits with Flash installed: 2.25%
  • Mobile visits without Flash installed: 97.75%

Large UK retail chain's e-commerce site, last month

  • Mobile visits with Flash installed: 5%
  • Mobile visits without Flash installed: 95%

 

Besides, animated GIFs are more fun anyway.

2012-02-23

Responsive wireframing

This post originally appeared on the Storm ID blog.

There has been a lot of talk recently on the web about the best responsive design workflow, and part of that is the best way to wireframe for a responsive design. We've been wrestling with these topics at Storm ID too, and I wanted to share a little of how we're working on it at the moment.

What I describe below won't work for everyone. It may not work for us 6 months from now, but it's working well for us just now.

Sketching is a great way to get ideas flowing, to quickly illustrate those ideas to colleagues and to get things straight in your own head. I still start with paper and a pen, roughly sketching things out. I probably always will.

It’s useful to remember that we can use traditional tools (if necessary) to generate ideas internally, and then use ‘new’ methods of presenting ideas to clients. Not everything has to be a deliverable; we just have to present deliverables in the right way. Use whatever you want to get the ideas going: paper, Visio, Axure, Balsamiq, Photoshop. It really doesn't matter. Just remember that it's okay to throw it away afterwards.

So after I've got things a bit clearer in my head by sketching, I move on to HTML/CSS wireframes.

You would be hard pushed to find many web designers today who would argue against HTML/CSS being the best way to present wireframes to the client, but many feel it's too time consuming. I disagree.

It can be done quite quickly with a system in place

I've been developing a system while working on a couple of responsive sites that makes it much faster to create HTML/CSS wireframes, almost like static prototypes. I start with a basic HTML file which we have developed, a bit like HTML5 Boilerplate but tailored to our own needs, including a reference to wireframes.css, a stylesheet I wrote.

View our current starting template and view source
View wireframes.css

This stylesheet contains a few basic styles for header margins, link colour (just adjusted the shade of blue) and the main thing: styles for [data-wf="block"] and [data-wf="nugget"]. This allows me to add data-wf="block" or data-wf="nugget" to any element and have it display as a traditional-looking wireframe grey box or white box with grey border. After the wireframing stage I can easily remove the stylesheet and the data- attributes and all the grey styling is gone but the structure remains, ready for the visual design phase. I've used data- attributes instead of classes as I found them easier to find and remove.

To add height to blocks without full content yet I just add <br /> tags (don’t panic, these won't make it to production remember).

Then I start adding layout structure CSS to my other stylesheets. This structural CSS can form the basis for visual design in the browser later. You can use something like Bootstrap if it helps keep things speedy, or you can roll your own grid, as I prefer to do.

At this stage (and most of the way through development) I reference a stylesheet for each media query, instead of combining them. I find it much easier to work with a few files open in tabs than to endlessly scroll up and down one huge stylesheet.

I don't find that all this takes me much longer than figuring out how to use Axure or Visio or something similar.

The extra time spent is worth it

Yes, it can take a little longer to wireframe in HTML/CSS. But what you lose here, you make up for later by having a solid foundation already in place to start the visual design phase. Some of your output is already done. Some of it you might need to strip out. It also gives our developers something to work with when developing the site while I work on visual design.

Building out your wireframes like a prototype allows you to work out exactly how the layout changes according to different devices. It lets you see if your thinking on paper was correct. It lets you quickly adapt when you find out you're wrong.

It's going to give the client the clearest possible picture of what you are proposing. They can view and test a usable web page, with links, javascript and/or CSS3 based interactions, and test the flows through the site. They can test this on any number of different types of devices they can lay their hands on. There is no guesswork needed. This is incredibly important as we support clients who are new to creating for the web, let alone experienced with responsive designs. Often, the best way to explain something is to demonstrate it. You can even set up analytics on these wireframes and get feedback that way.

It's not supposed to be easy

I'm a designer who codes, but if you're not, why not get friendly with someone who is. Sketch out your ideas, chat through them with a frontend developer, and have them produce responsive wireframes you can present and share with your client.

No one is saying this is simple. It's not. It takes a huge change from 'traditional' processes and to start with it will take some extra work. However, the benefits for you, your clients and the final work far outweigh the initial pain.

Always evolving

This is what works for us just now. We're always trying to look at better ways of doing things, for our clients and the agency. I'd love to hear what you think is the best way to work with responsive design throughout the process, and especially any good or bad experiences you've had.

2012-02-03

Responsive Design on Sharepoint 2010

This post originally appeared on the Storm ID blog.

When it came to rebuilding the [client] – that wonderful arts icon located in southside Glasgow - we felt that this type of content-rich site would benefit from a content first, responsive approach.

However, we weren't sure how responsive design would fly with SharePoint.

For legacy reasons, the rebuild had to be done on SharePoint 2010 ([client] being part of the [client] web family, all of which is built on SP), and we know that SharePoint can be notoriously hard to bend to your design will with so much extra code and use of <table>s.

Fortunately our SharePoint Team Leader, Tom Travers, is both a patient man and has spent years of his life rewriting SP controls to use markup that the Storm design team can actually work with. Because Storm are generally up for a challenge with SharePoint we were keen to see how a responsive design could work with that product.

First, the caveats…

First, we should say that we wouldn't recommend trying a responsive design approach with a standard out-of-the-box Sharepoint install.

Responsive design is not easy at the best of times:

  • First you have to break the design habits you have developed over the years.
  • Then you have to educate your client about what responsive design is and the benefits for the project.
  • Then you have to create a responsive design that flexes to any size of screen but is still compelling.
  • Last - and this is the really hard part when working with SharePoint - you have to integrate your designs with your chosen CMS.

An introduction to responsive design

Basically the web is going device independent.

We are currently experiencing a period in which there has been a dramatic increase in the number of devices that websites are viewed on. Smartphone penetration continues to increase with more people predicted to access the internet via this method than PCs by 2013. At the same time we’ve witnessed huge growth in tablets, like the iPad and Kindle, presenting yet another range of screen sizes and capabilities for websites to deal with.

The spectrum of screen sizes and resolutions is changing every day, so much so that creating a different version of a website is increasingly deemed to be impractical and unnecessary.

The emerging solution on the web is to adopt a responsive approach. The approach makes use of flexible grids, flexible media and media queries to serve the most appropriate experience possible to whatever device you view the site with.

Yes – it’s the right time for [client]…

We thought that a responsive design would help ensure that [client].org was accessible and well presented to the widest audience, regardless of where and on what device they were accessing it from. Moreover, as new and, as yet, unforeseen devices continue to enter the market, responsive design should help to ensure that [client] is future friendly.

Our approach to responsive design on Sharepoint

Our design approach for many projects in the past has been Research > Wireframes > Mockups > Output > Integration. However, this approach does not, in our experience, bring the best out of a responsive design:

  • Working with static mockups can never convey to the client how a design feels when it is interacted with, and it certainly can't show how the layout will work at a variety of sizes.
  • Likewise, static wireframes can show layouts and elements as viewed at a certain size and resolution, but we can't make endless wireframes of each view for different device sizes.

Also, if we mock up designs for some ‘standard' sizes, we will miss all the devices, niche or otherwise, that fall between these.

Responsive design is as much about those in between sizes as the 'standards' of today.

Wireframing

We now move on to quickly built HTML/CSS wireframes. (Actually, we do plenty of sketching first, but the client is seldom presented with these sketches.)

The wireframes are built using templates and snippets we have built up, including a wireframes.css file, which allows us to quickly add classes to elements to style them in the familiar grey, black and white boxy style for traditional wireframes.

The difference is that these wireframes can already convey to a client (and ourselves, this is as much exploratory as explanatory) how the layouts look at different sizes on different devices, and in different contexts.

They can view these wireframes in the office, on the train, in the street, and each template can be linked up to give a feel for the user journeys.

Yes, this can take a little longer than creating static wireframes.

But the more we use this process and the more snippets and templates we build up our library - yes, a “patterns library” for responsive design, nice - I hear you say - the quicker we are getting at this. Also, the extra time spent at this stage is compensated for in the next stage: visual design.

Visuals

Once the wireframes have been agreed, we move on to visual design, also in HTML/CSS.

We may work up some ideas in Photoshop (but again, the client won't generally see these). We work in HTML/CSS/JS, working with the existing layouts from the wireframes, building up the richness of the designs. This progressive enhancement approach allows us to give basic devices a basic experience without losing any functionality, and giving more advanced devices a richer experience as appropriate.

This also allows the client to see how the visual design will look in situ, in terms of layouts, contrast, typography, etc.

Having already worked out a lot of the problems with the responsive parts of the templates, this phase is much quicker than the traditional build phase from static mockups.

*!**!** SharePoint!

As mentioned above, normally our designers might spend time integrating templates into target CMS for the project. For Tramway, however, the static HTML/CSS/JS templates were handed over to Tom to integrate into SharePoint.

These templates were built initially without any allowances for SharePoint's usual eccentricities.
We wanted to create the best possible product first, and then see if we could integrate it and solve the problems needed to so. There's no point in starting from a position of weakness, as we knew we would have to make compromises later on.

How was it done?

First, we built a solid masterpage that works for anonymous, publishing web-site.

This goes some steps beyond the available minimal masterpage out the box. Not only did this mean ripping out anything that could come out, but quite a lot of ‘poking the angry animal’ to see if it would bite back. This means things like messing with the <html> element, the <DOCTYPE> declaration and the basic s4-* based structures.

Then it was just a case of pouring in the creative output…and a lot less debugging than anticipated. This was all combined with the site content, which has some rich content types, including calendar event links, video and audio, and other conditional display constructs. Oh, and a few calendar based searches.

The final challenge was to support the page authoring model, ribbon and all… Admittedly this does get a bit messy with conditional display controls being used for the page display to authenticated users and further conditionals when in page edit mode.

Methinks some further challenges lie in this area…

So here’s an open challenge for the Microsoft SharePoint 2013 team … how building in responsive support and a responsive SharePoint page editing environment?

A message in a bottle…

The bottom line, we’re pleased to say, is not only that a responsive design in SharePoint 2010 can be done, but that it can be done very successfully.

Go take a look at [client] and see for yourself…

2011-05-20

Coincidence?

Coincidence?

2009-03-14

SXSW 09 – Day 1 – Friday

Awake: 8.30am

Got to the convention centre just before 9am. Had my badge and 3 big bags and a ticket to the premier of Objectified by 10am.

Headed to the AT&T store and got myself a US pre-paid SIM card.

Hung around a bit and checked out some emails etc. Had my first tacos at the Taco Shack. It’s not Torchy’s but it’ll do.

Panels: 2 - ‘Getting the most out of SXSW FIlm’: Quite useful. ‘Oooh, That’s Clever! (Unnatural Experiments in Web Design)’: Very interesting. (We went to the Bogusky panel but it was too busy and hot, so we went for a beer.)

Parties Attended: 3 - Mix at Six: Quieter than expected, fun. Pastries and Pasties: Great cupcakes. AMODA showcase: too tired unfortunately.

Sleep: 11.30pm

Feeling much better for a decent night’s sleep.

2009-03-13

SXSW 09 – Prequel

So I’m going to try and blog every day from SXSW. I’m writing here instead of my Nonimage Blog because I want toblog about everythig that happened, not just the ‘businessy’ stuff.

So here’s the rundown of yesterday:

It was my birthday.

Awake: 3.30am UK time

Sleep: 11.30pm (4.30am UK time)

Flights: 3 - Edinburgh to Paris, Paris to Atlanta, Atlanta to Austin

In Atlanta I had 2 beers and a strong Jack and coke and because of the lack of sleep and travelling, felt rather tipsy. I was then told the flight was overbooked and I wouldn’t get to Austin to the next evening. Thanks Delta. Luckily a guy in first class left his ID across the airport, and had to go get it and wait for the next flight. So I got into first class. Awesome.

Times I was given food: 9 (Flights are like that. I didn’t actually try to eat 9 meals

Films watched: 3 - The Day The Earth Stood Still (terrible), the latest Bond (again), Flash of Genius (mediocre)

TV watched: 1 episode of The (US) Office

Books read: 1.2 - A book with excerpts from good blogs (freebie, some of it was excellent), then started ‘Bad Vibes’ by Luke Haines (excellent and very funny so far)

Music: 3 albums - ‘The Photo Album’ by Death Cab For Cutie, ‘Midnight Organ Fight’ by Frightened Rabbit, The Pains of Being Pure At Heart

That’s it for now. I’m back at the hotel having picked up my badge, big bags and a ticket for Objectified (film) tomorrrow. I’m going to get a US sim card now.

Andy Lobban

Edinburgh, Scotland