Posts Tagged ‘ux’

17
Dec
2015

Attempting to reach actual reality

by Steve Cottle

really-header

 

Let’s do a usability test where we’ll take some participants and observe them with a product. We’ll take our findings and after a bit of analysis we’ll implement something. We’ll be able to base the development on solid research because we documented what the participants did and said. And that’s good.

Here are some things to bear in mind about usability tests:

 

Ironing out the creases
It’s good to practice. Practicing your test allows you to iron out any issues before they arise1. Imagine sitting down with your participant, you run through the first task annnd … they don’t understand what you’re asking! Oh no! All that time you spent crafting the perfect non-leading task and you have to rephrase what you’d like them to do. Will it be as effective as your original? Planning also means you’re not leaving everything to the last minute – printing stuff, getting equipment ready, sorting the room out and that.

 

Observation not conversation
As unnatural as it is, encouraging your participants to talk aloud2 about what they’re thinking gives great insight into why people find things easy or challenging. Also, try and avoid talking too much yourself. By the very nature of being a UXer, we want to help people achieve stuff so this is one that I personally really have to concentrate on. Avoid treating the session as a conversation and turn it into an observation3. Nielsen Norman Group has some good advice with their Talking With Participants article which covers three techniques (Echo, Boomerang and Columbo) that can be used in the test itself.

 

The whole truth?
So that’s all good. We’ve practiced and performed and now we can analyse our results.

Well hold on there Johnny-two-socks, the thing is sometimes participants might not be telling us the truth. Dun. Dun. Dunnn … There are several reasons why your results might be a little off the mark.

In UX Booth’s article Bridging the Gap Between Actual and Reported Behavior they have some insights into what could be going on in people’s heads.

 

1 – How would you like that answered?
Sometimes we answer questions in a way we believe the person who asked the questions would like them to be answered.  Similarly, we can answer questions how we believe to be socially acceptable … do we really exercise as often as we say we do?

 

2 – I’ll do what you do
There have been cases of participants straying completely away from what’s clearly a correct answer just to fit in with peers around them:

“[In the Asch conformity experiments] Research subjects were shown several lines of different length, and asked to select the two of equal length. The subject didn’t know that everyone else answering the question was a confederate of the researchers. The planted participants would sometimes unanimously give an incorrect answer and, 37% of the time, the real research subject agreed with them.”
Kat Matfield, Bridging the Gap Between Actual and Reported Behavior

 

3 – Self Image
People also say what they want to be true and perhaps not what is actually true, viewing their capabilities through rose tinted specs. Not so much delusions of grandeur, more wishful thinking:

“ … our self-image doesn’t match up to reality. But that self-image still influences how we respond to questions about our intentions, rationale, or preferences”
Kat Matfield, Bridging the Gap Between Actual and Reported Behavior

 

4 – Where and when
People respond differently in different contexts. For example there are more suitable environments than an office room to evaluate the usability of a sports app. The results from one environment would be quite different to the other4.

It’s not just about how people subconsciously answer questions. The very fact that people are being observed encourages changes in behaviour. The Hawethorne effect demonstrates that if a participant is set a task to complete while being watched by someone they might change their approach to completing that task. For example during an observation the participant may read through instructions leading to a more successful task completion, whereas if they were alone at home they may simply ignore them and fail the same task. There is also the notion that if a participant is asked to achieve a task then they presume that task can be completed. Whereas if they were using a new product outside of the test environment they wouldn’t know that what they wanted to achieve was possible and would enter a journey within the product to find out5.

 

5 - Ultracrepidarianism
People may also give you an answer to a question even if they they have limited knowledge of the subject just because the question was asked of them. And, if asked why they did something, sometimes participants simply may not know so they make up a reason, or offer their opinion anyway6. This is known as Ultracrepidarianism.

 

So …
Preparation will help things go smoothly and by applying some simple techniques during your test you can make the bits you have control over more successful. However the fact is, it’s inevitable that your participants will show some of the characteristics described above. The important thing is to be aware of them and to identify when they happen. You can’t control a participant’s subconscious or how much value they place on social acceptance and if you do become aware of anything which might skew things, note it down and advise how it may affect the results.

 

Usability testing tips
Here are some top tips for running a usability test courtesy of usability.gov:

1 – Be polite and make participants feel comfortable

2 – Help participants understand that you’re after feedback on the design. It’s not them that is being tested

3 – Remain neutral (refer to the Talking With Participants article)

4 – Avoid helping and leading the participant

[5 - Encourage participants to think aloud]

6 – Take good notes – there should be two of you, one to ask questions and the other to record

7 – Measure both performance (success, time, errors) and subjective (self reported satisfaction and comfort) metrics

 

Fancy joining the Red Badger team? We’re hiring UXers!

 

—————
References

1 www.nngroup.com/articles/pilot-testing/

2 www.nngroup.com/articles/thinking-aloud-the-1-usability-tool/

www.nngroup.com/articles/talking-to-users/

4 www.uxbooth.com/articles/design-research/bridging-the-gap-between-actual-and-reported-behavior/ 

5 www.measuringu.com/blog/ut-bias.php

6 www.measuringu.com/blog/ut-bias.php

 

5
Jun
2015

Smooth Sailing- Designing businesses to deliver value

by Sinem Erdemli

“Improving experience starts with every customer interaction. Your customers see you as a one entity.” -Jiri Brezovsky

This is a quote from his post Stop wasting money on a “beautiful” interface it’s about the importance of improving the overall experience, rather than creating beautiful UI. It’s a brilliant and valid point, one which we at Red Badger think about a lot.

Even though a beautiful design, a high quality piece of software or sky-high conversion rates may seem like the ultimate goal of running a business, especially on a day to day basis, there is one crucial bit that shouldn’t be overlooked. That is to deliver value. 

I just want you to get the job done

As a customer, I don’t care about how well your metrics are doing, whether or not you’ve met your sales goals or when the next software update is due. 

I only care if I can get what I want from you or not. How much do I need to give [time, money, effort] vs. how much I get out of it. 

In the end, if I want to get my hands on a new computer I want to decide which one is for me, where and how to buy it, and how to set it up and who to get in touch when something goes wrong. All of that should be easy peasy, but is rarely so. 

The times they are a-changin’

Businesses have complex structures, they exist on multiple channels, partner with numerous 3rd parties and carry ways of working from the day they were established. 

A business runs with the help of multiple ‘departments’ ranging from marketing, sales, merchandising, customer services, online, suppliers, logistics. There’s also a big board of stakeholders to please with the outcomes.

“The problem [with designing in silos] is that customers don’t just care about individual touchpoints. They experience services in totality and base their judgement on how well everything works together to provide them with value” -Andy Polaine et al.

Each and every department has different targets and end-goals. They are usually focused on just one channel or a single touchpoint of the customers overall experience of a customer. The problem arises when the links between these individual touchpoints are left unattended, when they don’t appear on the targets because they are not tangible enough to make it to the boardroom. As a consequence, your customer’s experience with your business ends up being nothing but a broken, inconsistent and painful journey. 

When you think about it there is only one simple relationship to focus on, whether you’re in the boardroom, at the shop floor or in the office developing the website; and that is the one between you and your customers. 

 Love thy customer

value transaction

When it comes to deciding whether or not to come back, or to ‘recommend the service to their friends’ customers will not think about one interaction in isolation. They will think about how easy it was to use the website, how the staff treated them on the shop floor, they will consider the call they received by customer service team when their package was late all together. Overall their decision will depend on how easy it was to reach their end goal, the whole reason why they chose to get in touch with your business in the first place. 

Keeping the bigger picture in mind at all times will allow you to have meaningful conversations when you’re collecting requirements. It also will give you a reason to talk to each other, regardless of your position in the business. 

Stop and ask why how who

Before you get in your productive autopilot mode, stop and have a think about what the greater goal is.
-Why
are you doing what you’re doing?
-How might you make it better for the person at the other end?
-Who else might have an effect of the delightful experience you’re trying to create? 

Go speak to your colleagues, your stakeholders, customers. Involve as many parties as you can. Make sure you, as a business, are giving the same message, have the same tone and same level of delightfulness for your customers throughout their journey with you. 

Then and only then will your efforts count for something. Don’t forget, your profit, sales, conversion rates can only improve if you love your customer, try to make their journey with you as happy and valuable as possible because your customer will love you back. (and will most likely recommend you to a friend, if that’s what you’re after)

further reading

servicedesigntools.org has plenty of methods you can use to think about your business offer as a whole. I would recommend checking them out. Or have a read through Andy Polaine’s book Service Design, it is delightful and one of the best you can find around. 

let’s spread the love together

If you crave consistency in experiences and want to help businesses create value with beautifully designed high quality software get in touch. It doesn’t matter where you’re coming from, as long as your intentions are well:) 

30
Apr
2015

I heart pens and paper

by Steve Cottle

Pile of paper with wireframe sketches

 

I love pens and paper and putting them together to make marks and lines and scribbles and that. Lots of people tend to avoid them nowadays, favouring the tippy-tap of a keyboard and the clicky-drag of a mouse. A few years ago I moved jobs and was surprised to see some of my new colleagues taking notes by typing stuff into Word. Maybe I’m showing my age but that really can’t be a good way of taking notes. The office had a healthy supply of pens and all manner of notebooks to choose from. Still she punched away at her laptop. She certainly wasn’t the quickest typist in the world, how did she get everything noted down? How would she go back and make new notes around her original notes? How would she doodle the cup of tea she was drinking, or the sandwich she was looking forward to at lunch? What was wrong with her?

 

It’s all about the pens and the paper, people. The pens and the paper…

 

Easy peasy

The vast majority of us can sketch a line, with little to no training. Those who can sketch a line, can join the lines together too. Once the lines have been joined together, loads of options then become available. We can now sketch anything in whole world, simply by joining lots of lines together in different ways. Woah there, anything? Sure, remember sketching isn’t drawing. The marks on the page don’t have to be a photographic representation of what’s in your head or what you see in front of you. The purpose is to get the ideas out of your head and to communicate your thoughts to other people. Sketches are ideas. The sketch needs to be legible but in no way does it super polished. And it just so happens that if like me, you’re responsible for communicating ideas for stuff like processes, websites, apps, flows and journeys, the basis of our sketches are boxes. We just need to sketch the boxes. Who can go wrong with a box? And if you’re feeling a little sketchy at first – don’t worry, the more you do, the more comfortable you’ll become.

 

Feel the draw sketch

Once you start putting pen to paper a wonderful thing happens. You start to show people, you pick the paper up and turn it over, slide it across a desk, touch it and pin it to a wall. Now your sketches are visible and out in the wild for all to see and get involved with. Now other people are interacting with it and collaboration begins, the idea isn’t hidden away behind a computer screen – it’s ownership has been removed and it belongs to the team. Even jargon becomes watered down and a common language develops. You’re now not trying to remember the names of modules or functionality, you’re pointing things out and bringing them into the group.

 

As easy as they are to create, sketches are also easy (and fun!) to get rid of. Screw them up and throw them (literally) away, make paper aeroplanes from them, or even an origami swan. The interaction continues even when they’re on their last legs.

 

Pros and pros

Sketching is quick. You really can make a fair few marks on some paper while your colleagues’ computer is firing up and their favourite software is loading. It requires minimal setup and very little investment in time, training and materials. Also, you don’t need to match software across teams or make sure you have the right amount of licenses. The tools are available from loads of easily accessible places and sometimes for free (shops, lying around, Argos*).

 

*I don’t advise you use Argos as a supplier of free sketching material.

 

Something old and something new

Wikipedia says paper was invented by our Chinese friends during the Han dynasty (206BC – 220AD). It was the equivalent of modern day wrapping paper and bubble wrap – used to protect anything from mirrors to medicine. More recently Architects and Design Engineers developed this ancient packaging material by making it more translucent so drawings could be precisely copied. This process of tracing is one of the fundamental processes in Product Design. Iteration is key to getting closer to solving a problem, refining and developing an idea. With sketching you can grab a new piece of paper, trace the old version, and iterate a new one, again and again and again.

 

Hmmm, but …

Hold on there smokey Joe, we don’t want any of that “well …”,  “erm …”, “I dunno …”. It’s quick, fun and produces lots and lots of ideas. And it all started thousands of years ago in ancient China.

 

Here at Red Badger we open sketching up to everybody from UXers, Designers, Engineers and Developers to the users of the products we’re producing. And from a tinchy 20 minute session we can get a whole heap of ideas and potential solutions to the problem we’re working on. All with no training and no budget. And we all get a break from our computer screens t’boot.

So, go on. Tool up, get your pens and paper out and pull up a pew with your team.

24
Dec
2014

UX Tip of the week: Making UX part of the Process

by Sinem Erdemli

Design has gone a long way. Roles have expanded from being a last minute add ons to product strategy influencers. 

Design is no longer seen as the last step of a process that makes a product look pretty to defining product scope. UX design as a profession has been creeping in businesses, as ‘user needs’ start being taken into consideration at board meetings. Now, managers are actually curious about their target users. They want to understand what makes them tick and what is a turnoff. This is all great, but too early to call it a day and go home…

Mom are we there yet?

No. We’re still not there yet. We seem unable to shake off the industrial mind set no matter how agile we are. Our industrialised minds are still programmed to deliver efficiently, we want fast returns to our investments and love performance charts that point upwards. We most certainly don’t like cards that go back, against the flow. 

The question is: How can UX and design be integrated in the development process?

At Red Badger, we work in agile. That means we talk to each other all the time (occasionally about work stuff), we change things, we question the decisions we made, check in with users and do it again until it is right. The designers, developers, testers they all sit together and work together. 

However, that process of close collaboration is difficult to capture on the Kanban board. The project board is there for a reason, it should be a mirror to team activities, it should communicate the process and the goal we work towards. But does it really?

Out of sight, out of mind? 

The issue with keeping UX as an isolated step in the process is that once the stories pass through and get closer to Done, the goals change. After a certain point, the goal becomes efficiency and you find yourself focusing on just delivering features, making sure they pass cross platform tests. 

We’ve talked about how crucial it is to keep your personas close and introduced Bob. If you haven’t seen that post do it-here and now.

We suggested sticking a picture of your version of Bob next to your computer, on the wall, by the project board. Somewhere you pass, and will see-daily. 

ALWAYS keep in mind that there will be people using your product (unless of course your target group is animals, insects, aliens..) It is important to have check-ins with users. Just like daily stand-ups you have with the team or weekly progress meetings with your client, make sure you check-in with the end users, and take a step back to make sure the greater goals and the purpose of your project are still there. 

kanban

  • Discovery: This is a good point to discover why you should get started in the first place. Find out about the strategic goals as well as the technical feasibility. Test the concept, go and get a feel for what the intrinsic needs and behaviours are. What people might like doing, what do they enjoy, who do they follow and most importantly why they do so. Use this space and time to go wild. Explore and question everything.
  • UX: You know the drill here. Use all the wisdom you have to do your magic. 
  • Design: Make sure the design reflects the brand direction, the look and feel is consistent with your intended messaging
  • Dev: Check that the high-tech features make sense to people who will be using the product
  • Test: Try to find out the different use scenarios, validate the assumptions you’ve made
  • Done: Watch usage, do some proper testing, measure and watch behaviour. Use all the data you’ve collected to write up new use cases, start thinking about improvements 

Disclaimer: We’re still testing this out. It’s already changed within a week. The user testing section doesn’t have to be a physical test with users, . 

It’s merely a suggestion rather than a solution- as always. Do try it at your own risk- we suggest collaboration over supervision. 

Until next time..

Ta!

17
Dec
2014

UX Tip of the Week: Meet Bob

by Maite Rodriguez

 

From the developers to creatives to business people, how to get everyone to finally understand the what UX is really about.

 

Let’s get started.

 

I would like to introduce you to Bob.

 

He will be our “user” for today.

 

 

Bob = User

 

For starters, you should always make it clear it is all about the “user” aka Bob.

 

Period.

 

If this is not absolutely clear from the beginning, then there is no point in reading the rest of this …..

 

Ta!

 

 

Stop using the term “user” to the team. These “users” are people with feelings like Bob. Try to use the persona’s name that the UX team meticulously researched and created for the brief.

 

Personas are there for a reason….

 

If you have to, frame a photo of your persona, let’s say Bob, and place it next to everyone’s computer as a daily reminder.

 

 

Let’s make this abundantly clear, people are not “stupid” or “slow” or “lazy”.

 

If your “users” do not understand the design, it is 99.999999999999%everyone’s fault involved in the project.

 

One team, One accountability.

 

 

If you are not there to defend the “user” … then who will? If there is no one representing Bob, then there is no UX.

 

 

Do not resort to the easiest tech solution. I know, it’s hard…

 

Mo’ work, mo’ problems.

 

But, if it’s for the “user” aka Bob’s best interest sometimes we all have to make sacrifices. As that great kung fu fighter once said in that kung fu movie:

 

“Take the hard righteous path than the easy wrong one to save the kingdom.”

 

 

UX is not like paint. We can’t just slab some paint on a chipped wall and call it a day. It is much more than that, so much more.

Here’s in on little insider secret…. UX doesn’t really exist.

 

UX is just a easy term that is used to group a whole lot of things that would take too much time to explain in one simple job title.

 

 

So, if you just take one thing from all of this, remember:

 

Every code written, every interaction made, every word read, every visual seen, the “user” should always be taken into consideration.

 

So, today I will rename the term “user” to “people” because it is all about the people’s experience…. Bob’s experience.

 

Until next week….

Ta!

 

10
Dec
2014

UX Tip of the Week: Post-its

by Maite Rodriguez

The Magic of Post-its

 

 

Post-its, Post-its, Post-its, Post-its, Post-its evuuuuurrryyyyy where..

 

All you need is a pen, wall space and post-its for your inner genius to come through.

 

When should you resort to post-its you ask?

 

  • Feeling overwhelmed with all the initial research and don’t know where to start….. post-it

  • Creating a christmas shopping list that you still haven’t started …. post-it

  • Need to do a feature analysis for a competitive website… post-it

  • Takings note at a meeting… post-it

  • Preparing a plan for action… post-it

  • Can’t decide where to eat for lunch…. post-it

  • Weighing the pros and cons of anything really… post-it

  • Need to prioritise and MOSCOW your project… post-it

  • Explaining to you co-worker how to get to Dirty Burger… post it

  • Trying to understanding foreign concepts (aka not related to UX) …..post it!

 

See! I challenge you to find a moment when the post-it can’t work its magic.

 

 

Until next week…..

 

 

 

4
Dec
2014

UX tip of the week: Competitive analysis for mobile navigation

by Sinem Erdemli

We started the week with user testing on an e-commerce site. It was all good until we asked people to find something, they had no idea how to work the side navigation.

And that was a surprise. 

tumblr_ltnymfq4NX1qen75u

It was obvious that users were struggling with it and it wasn’t a batch of those users who can’t work anything and have no idea what’s going on. There’s a limit to how much you can blame users.

The question in hand was obvious, one we had been pondering on for a while:

How might we get the benefits of a a mega nav on mobile?

So we went back to the office and got our post-its out. (Keep your eyes peeled for our next post on why post-its are king)

It was time to take a step back and clear our muddy heads. 

The game plan

1- List out relevant websites that have a similar issue (in our case it was squeezing mega nav content into mobile navigation)

2- Collect screenshots, the more you have the more ideas you can “steal” nope not that.. borrow

3- Break down the screens into it’s components. This is where the mighty post-it comes to play. 

4-List out Pros and Cons for each. Identify your favourites.

5- Sketch out the flow for each, find out how the users are lead to a particular Product Listing Page. How soon do they see the content? 

6- Compare flows. Visually comparing the flows let you highlight differences at a glance, it helps understanding (and communicating!) what works and what doesn’t. 

flow

6.a- If you can, go out and test the few examples with people, see if any alternative stands out, find out what people think. 

7-Show this to any stakeholder, it may be the client, it may be the designers, the dev team.. Talk about the issues users has, show the comparisons, think about what’s possible what needs more exploration..

8- Identify what you like, what can be done, with a little help from the favourite features list- and try it out. 

Taking a step back and looking around is useful. You clear your head, benchmark yourself among others and get to spend some play time.  Try it, you’ll feel better. 

Until next week, 

Ta. 

28
Nov
2014

UX Tip of the Week: Guerilla Testing

by Maite Rodriguez

What we learned this week:

Guerilla Testing

How to approach people and lower your chances of being rejected.

 

 

Do

  • Choose a location where people in your target audience are likely to convene. In our case it was a Co-op working space.
  • Go right at the end of lunch time when people have finished their food and are more likely to crave sweets.
  • Bring candy, brownies, cookies… get creative and place it next to your working space. Try to avoid being creepy. A fan to blow the smel may help catch their attention. Kidding!
  • Smile and ask if they have time to spare. (The amount of time you will be user testing)
  • If they say no let them walk away. No begging.
  • If they say yes, game on.
  • When you ask them the pre-screening questions and find out they are not your target user, its okay to cut the testing short.
  • Take notes. Voice recorder, video recorder or just a plain old note pad.
  • ASK PERMISSION before you do a voice or video recording!
  • During the testing. Watch, Listen, and ask follow up questions like:
    1. Why?
    2. What did you expect to see?
    3. How did that make you feel?
  • After 3 users it starts getting tiring.
  • Go home.
  • Next day, review notes and find the trends.

 

 

Don’t

  • Just show up with nothing prepared and wing it.
  • Lie and tell them it will take them 2 minutes when it will actually be 10.
  • User test anyone who is willing to talk to you.
  • Invade their personal space once they are close enough.
  • Creepily stare them down as they walk towards you.

 

http://giphy.com/gifs/black-and-white-smile-horror-XQLcriSh7za0w

 

The end

 

 

28
Oct
2014

Haller App Launch

by Joe Dollar-Smirnov

Red Badger in collaboration with Haller and Pearlfisher designed and built a web based app for the charity Haller. Our primary users for this app are Kenyan based, rural farmers who live a life far removed from the abundance of our comfortable western home comforts.

 

 

Haller bring life changing but basic civilised facilities to communities. The construction of reservoirs, wells, sanitisation, medical centres and learning facilities are all just a part of the work carried out by dedicated Haller recruits both on the ground in Kenya and in the UK. Led by renowned environmental expert Rene Haller, education and dissemination of agricultural knowledge is a big part of their work. Through education, Haller help local communities build sustainable futures.

The Haller app is a constant, on demand source of this information and an alternative way to reach further afield. Red Badger spent time in Africa working directly with the farmers to ensure the final product was focussed on their goals, accessible and understandable. Some of the users we were targeting had very little or no experience of using applications or websites so intuitive interactions were essential. We could not rely on any existing knowledge or experience of conventions.

The app has now launched and to mark the occasion Pearl Fisher have created this fantastic video that tells the story. To get the full background on Red Badgers involvement in the app, how we approached the research, workshops and testing there are a series of blog posts below.

Haller web appFarmer Training Research

Africa Road Trip: Day Zero

Africa Road Trip: Day one and two

Africa Road Trip: The workshops begin

Africa Road Trip: The challenges for app design and development

UX Testing in Africa – Summary

 

8
Aug
2014

The Design Sprint at Red Badger

by Sinem Erdemli

At Red Badger, we typically start projects by gathering insights and working out initial concepts. This allows us to understand the users, identify a scope for the project with clients and prepare design assets for development. Also known as ‘sprint zero’, it is an intensive week of absorbing as much as possible and coming up with a plan with the client working with us. 

 

Project Brief

We were approached to design and develop a multichannel touch screen that would go in a retail store. Unlike most e-commerce projects, this one didn’t want more sale conversion or higher profits. The goal was to improve in-store experience and increase customer engagement. Handed over a presentation as the project brief we could almost see the open-ended solution sea in front of us. Just as we were daydreaming about virtual shopping assistants, personalised product recommendations, we were hit by the expected launch date and resource plan allowing only 4 weeks of development and an expected launch in 6 weeks. This was going to be a very short pilot project with possibly many to come. We needed a tangible starting point to validate the concept and iterate as quickly as possible. 

 

Our Approach

We decided to run a design sprint to kickstart the project. We wanted to come up with a concept we could test and validate before our developer joined the team. 

The design sprint is an intensive week-long process of problem solving. Google Ventures runs Design Sprints for their portfolio companies to be able to make fast and predictable product design decisions. It doesn’t matter if the product/service is brand new, or is looking for a make-over; the whole point of a design sprint is to explore the problem in hand and come up with testable solutions quickly.  

The design sprint combines design thinking principles with the lean methodology. Based on iterations and fast paced decision making and prototyping, the outcomes try to find the sweet spot between the three forces desirability (user), availability (technology), and the viability (marketplace/project scope). 

The one hour planning meeting quickly turned into rapid sketching sessions and before we knew it we were already busy sketching out our ideas.

 

Day 1 

designsprint1

We started with the project brief and went through any material we had available. We looked into the best examples of multichannel implementations in-store, discussed the results from previous user research on customers and mapped out a high level user journey. By the end of the day we had defining keywords for the experience, dozens of bookmarked examples and the rough sketches of our Crazy Eights sketching session.

 

Day 2

designsprint3

We spent the morning working on the sketches and refining the user journey. The official kickoff with our clients was in the afternoon, which would let us get an initial feedback on everything we had and the direction we were taking.

 

Day 3

By Day 3, we had quite a few sketches so we started to put in a digital format. To get initial feedback on some of our assumptions we used the projector in the office to see how the other Badgers reacted. We grabbed a few developers by the kettle and asked if any of the elements might cause headaches when it came it implementation. UX and Design worked closely at this stage, the transition from sketch to wireframe and then to design was almost at lightning speed. 

 

Day 4

designsprint4

Day 4 was testing day. We had been itching for some feedback to see if our assumptions were somewhat valid. We went over the wireframes before it was ready for testing. We mocked up a prototype by sticking an iPad and the homepage design on a piece of cardboard and went out for some user testing. 

 

Day 5

designsprint5

By Day 5, the meeting room looked more like a ‘war room’ than anything. We iterated on the wireframes for the 4th time based on the user tests and flagged our technical requirements.

We had a clickable prototype that linked all screens for our first progress meeting. The meeting went well with positive feedback. Having a clickable prototype helped us discuss features that would have potential development risks. 

By the end of the week we had enough information from users, the client and developers to put together a backlog of epics and list our technical requirements. The overall impact of the design sprint is still to be seen but for now it’s fair to say that it will stick with the Badgers for a while.