Part 1. the UX process

Oneyoungman
MyTake
Published in
14 min readOct 24, 2019

--

intro

My fifth project at Ironhack’s UX/ UI Bootcamp in Berlin was trying, but this had more to do with team dynamics than anything else. I learned some lessons from the difficulties we experienced as a team, and in this article I‘ve tried my best to process what went wrong in an attempt to avoid the same mistakes the next time I encounter such a team dynamic, or work in a team of designers.

During the week, I furthered discovered my skills as a mediator and a leader. I notice more and more that sometimes, when stuck in discussion, all it takes to get things moving again is for someone to step up, choose a direction and lead.

So, let’s get on with it shall we…

the brief

For the fifth project in my Ironhack UX/UI Bootcamp experience, students were assigned groups and briefed to design an online editorial in newspaper or magazine format. We were asked to design for one user-persona from a provided set of 5 (see below).

This project took the form of a 5-day design sprint and was the first time any of our team had worked on designing an editorial.

5 User personas … or “Yuppies”; your new favourite sitcom

the team

I was randomly allocated two team-members; one with an academic background in research, and one with a background in industrial design. I had worked with both of them on separate projects at Ironhack and got on with both of them, but couldn’t predict how we’d compliment each other as a team. It turns out, not so well…

user 1.0

Who are we designing for?

Out of five given user-personas, we chose 33 year old James:

“The Ambitious Businessman”

Repeated grid of James’ stupid face
James the “Ambitious Businessman”

Each of the team felt some connection with James’ passions, and once it was learned that user research could still be carried out, we decided that it would be fairly easy to find relevant people to interview in-person in the huge, fancy-shmanzy co-working complex Ironhack was situated in. So far so good…

initial market research

Coming into this project, we needed to understand the market better. Firstly, each member of the team took around half an hour to assess the editorials they commonly used, especially those with content related (but not limited) to business and technology. We then came together to discuss anything we’d noticed, what we liked and didn’t like, and made some notes, bearing in mind that we wouldn’t be designing a product for ourselves.

user research — survey

Stat. takeaways from our user research survey. Yellow notes show quantitative data & blues show open-ended responses.

survey insights

We next conducted a survey in order to gather qualitative and quantitative data on people’s habits when consuming online editorial materials.

This is a reduced version; to read the extended-version please click here.

We started out by asking which online magazines, newspapers and blogs people tend to read, to inform us which online editorials to research and learn from.

91% of respondents like to read text

75% of respondents like to watch videos

50% listen to podcasts

In the next two questions, we considered the context of consumption…

70% read online throughout the day (e.g. in breaks at work)

66% read online on public transport

50% read on the toilet :)

50% of respondents read articles for 5–10 min (per session)

25% of respondents read articles for a few minutes (per session)

20% of respondents read articles for 10–30 minutes (per session)

notes

  • users should be provided articles of mixed length
  • How might we categorise and communicate article length?

83% of respondents read online to discover new things

75% of respondents read online to get more informed about a specific topic

54% of respondents read online to be caught up with the news

notes

  • users should be able to discover new stories + access specific topics

Next was considered how respondents landed on content…

70% of respondents navigate directly to editorial websites

54% of respondents land on editorial websites (e.g. link on social media)

33% of respondents use an app

notes

  • the primary user flow should start on homepage + secondary user flow should be developed from a landing page if time allows
  • app design can be ignored; focus on responsive web

Finally came one quantitative and one open-ended question regarding feature and content prioritisation.

79% of respondents valued well-written articles highly

45% of respondents valued beautiful design/ layout highly

45% of respondents valued specialised content highly

41% of respondents valued lots of varied content

37% of respondents valued well-produced videos

notes

  • users should be provided with proper journalism: well-written articles laid out beautifully, with clean UI.
  • Should the content be diverse or specialised?

“Minimal desgin good (sic) researched articles, diversity, interesting topics.”

“Like: Simple layout, very few widgets and integrations, researched articles Hate: paywalls, autoplay videos, advertorials”

“I hate pop-up ads.”

Thanks to question 10 being open-ended, it came out that the thing people were most frustrated about was disruptive advertising.

survey takeaways

In order to provide a product that matched the overall needs of this user-base, it was decided that this design sprint should focus on the following:

1 - avoid disruptive advertising

2 - produce a minimal design with clean UI and easy-flowing articles with little visual distraction e.g. avoid auto-play videos and ads that block text

3 - provide high-quality content from experts, properly credited and using trustworthy sources*

*As this was a five-day design sprint, it was decided that content and crediting design (see 3 above) would be sacrificed for this sprint in order to focus on other jobs to be done (JTBD).

user research — interview

Although a lot of actionable data had been gathered from the survey, it was mutually agreed that it would benefit the team to conduct an interview with an individual more closely matching our given user persona.

After a short hunt, we found a suitable candidate (F., a product manager in an innovative tech company with a passion for business, finance and tech.) without much trouble and conducted an interview with him.

interview insights

  • Checks stocks and reads articles every day on finance website Seeking Alpha, also regularly uses Bloomberg, Tech Crunch, Gruenderszene (de), Crunchbase and online newspapers such as Die Zeit (de).
  • Appreciates opinions of non-journalists on platforms such as Medium and Quora.
  • After initial interest piqued will then deep-dive topics on a variety of platforms (see first bullet point).
  • Doesn’t trust journalists and most Editorials to be unbiased; likes to get a balanced opinions from articles written by guest-writers/ non-journalists
  • Notes importance of well-written articles that are evidence-based and cite multiple reliable sources.
  • Notes preference for infographics and informative data in articles.

interview takeaways

Following the interview, the following ideas were brought into discussion:

  • Guest articles (written by users, not journalists)
  • Deep-dive articles (where subjects are thoroughly discussed at length)
  • Inclusion of finance tools to keep track of investments

data interpretation issues

The team now faced a problem. To what extent should we design for a mixed bag of survey respondents or for one relevant interviewee?

Our survey and interview data pointed in fairly different directions. The former pointed to a simple online magazine with a mix of contents and clean UI, and the latter (everything considered) to a more complex design with a more dense, traditional design and more focus on finance, investments and tools.

Decisions had to be made in terms of what data to include to inform the design. The issue detailed in more depth:

  • Our survey yielded 19–24 responses for each question, but from a mix of people, many of whom didn’t fit our user-persona, despite our attempts at targeting.
  • Our interviewee fit the profile of our user-persona well; this added weight to the importance of the data we collected in the interview.

But our interviewee was only one person. Basing a product on one interview- no matter how relevant- seems slightly insane. This was certainly considered at the time, but given the deeper insights and connection that the interview allowed, and considering relevance to end-users, this was a hard decision to make, made harder by differing team opinions on the matter.

next steps

Given more time in which to iterate, it will follow to:

  1. compose another more refined survey, this time targeted at our user-base
  2. carry out several more interviews

Already having spent more time than necessary on the research phase, we didn’t spend any more time at this point on user-research, as research could always be done later if time allowed.

Decisions:

  • What is the scope of the product’s content?
  • Should the product include finance content e.g. updates on dividends yield and investment tools?

fallout

On the second day of the project, one of my teammates shared that they wanted to split from the group and continue solo. The whole team was stressed, and this teammate didn’t wish to deal with conflict or to compromise as a team on the project’s direction. My other teammate and I took this as a challenge to work around, and urged him to keep working with us, fully aware that in professional working environments splitting a team up is often simply not an option.

I took this as a sign that I needed to step up as more of a mediator in order to raise team morale, but also found out soon enough that the team also needed more leadership: There was plenty of discussion but few decisions being made to time, so I tried to compromise and set the direction when the team became lost in discussion.

recovery

I pushed for us to divide up tasks between team-members; going off to work solo and then reuniting to meet, assess and combine our work. This had the advantage of reducing conflict, both inter-personal and work-related; thus speeding up progress.

defining the problem with “Jobs To Be Done “

Due to the team’s initial fumbling around with interpreting data from our research, I tried using the Jobs To Be Done framework to see if that would help bring our users’ key problems further into focus. Note that these are general statements not referring to James, James 2.0, or anyone specific.

When a user is reading an article, they would like to read without annoying ads, so that they won’t be distracted from articles/ videos.

When a user is anywhere on the site, they would like it to have a simple look and feel, so that they can navigate easily and not be overwhelmed.

When a user is on the go or has little time, they would like to access short articles so that they can finish reading the article.

When a user is at home or has more time, they would like to access long deep-dive articles so that they can explore a topic fully.

The project brief stated

“You have to choose one… primary persona and design for them. You can always conduct guerrilla research to refine the template or create a secondary persona out of your discovery.”

Now, after carrying out research, we had unpacked the data and were looking to piece it back together into an updated persona: James 2.0. This presented the challenges of deciding and mutually agreeing upon what to include in this new persona, and whether to utilise a secondary persona.

After far too much time spent in labour, James 2.0 was born…

user 2.0

James is a quiet Superman. You might not notice, but the world (relies) on people like James and like any other superhero James needs to know things about the world he is saving.

James needs that information in a short and clear way like snippets and about everything and should not take up much time.

So afterwards James can get back to doing the things he does during the day time that eventually will help to save the world.

user characteristics

Action-Oriented

Busy

Constantly in the middle/front of things

Decision-maker

Forward-looking

Leader

Never out of touch of things

Organised

Shapes world

Well connected

Due to the the team cooperating ineffectively on tasks, this task was carried out by our team’s researcher, and then reviewed as a team. Personally, I supported the splitting up of tasks at the time, to ease tensions in the group, reduce time wasted discussing arbitrary issues, and thus progress faster. However, the next time I find myself in a team situation such as this, I’ll push for more of a team-effort deciding our persona characteristics.

The team was making progress, and thus I let it slide that I wasn’t fully on the same page with the characteristics. I don’t think of them as inaccurate; they merely needed rephrasing and refining (see Part 2. Prototyping & UI) in order to be easier to work with and so that the team would be on the same page.

On reflection it seems that creating at least one other persona to cover more of the data gleaned from our research might have made decisions concerning direction easier and progress quicker. Another thing I would do differently next time would be to carry out one more (short) survey regarding content in order to better inform these other user personas.

competitive research and analysis

Our researcher went off to do further market research, coming back with a review of 12 editorials structured as seen below:

Everyone loves a good spreadsheet… right?

On the positive side, this review covered competitor analysis, some Information Architecture and content comparison.

On the negative side, most of the editorials reviewed did not come from user research, but rather from personal choices, thus failing to keep in mind…

we are not our user.

It should also be noted that using this sort of spreadsheet format with lots of text is not the easiest way for most people to absorb information, myself included.

On reflection it would have been better to discuss the presentation of such market research beforehand, but we were just happy for things to be moving along… next time round, I think producing separate documents comparing content, IA and Mobile vs Web screenshots will be much more digestible.

market positioning

“Goal” is the ideal market positioning for our editorial

Information Architecture

The next step was to figure out how to optimally structure the website’s information and navigation, known as Information Architecture, or IA.

Problems to solve:

What content should we deliver?

According to whose preferences?

How do we categorise this content?

content categories

What features should we focus on delivering? We set about feature prioritisation, looking at competitors for inspiration: how did existing editorial platforms (offered by our survey, interview and user-persona data) categorise and structure content?

Competitor IA research

There seemed to be no one school of thought on categorisation, and considering the varying specialisation of editorials why would it be otherwise?

card sorting

After looking at competitors, we employed the technique of open card-sorting in order to get some input into how to structure the site optimally for users, considering feature prioritisation and structure allowing editorial content to be easily added in the future.

One useful result from the card sorting process

This helped the team to get an idea how people unfamiliar (and emotionally unattached) to the project would structure the pages that would eventually make up a responsive web-platform (after many many iterations).

site map

The next step was to sort out the organisational structure, or “sitemap.” This maps out the relationship between pages on the site.

Mixing our initial user-persona’s content preferences with some of our survey respondents general content preferences and desire to keep the design minimal, along with our interviewee’s less finance-oriented content preferences, the compromise reached was to use three article categories:

Technology — — — Business — — — World News

? here represents an unknown sub-category

We decided to keep things simple, reduce the cognitive load on the user and refrain from using sub-categories (see image above), relying on user-testing for feedback on this approach. As there was no client to provide content specifications, there was no content to group and label, although changes to the sitemap and the future growth of the site needed to be considered.

user stories & flows

User stories help us to empathise with our users and prioritise user issues to (hopefully) solve with our designs. They also come in handy for figuring out which flows the user takes through a webpage or application.

Story 1. User lands directly on HP and reads one article.

Before work, James is at home and feels like reading up on his favourite topics, Business and Tech. He’s browsing and not looking for anything specific. He already has an account and is logged in to the website.

User flow 1.

James…

lands on the homepage directly from a url search,

browses through the quick news section of the homepage,

scrolls vertically until he finds an article he likes the look of,

clicks on the article,

reads the article,

exits.

Story 2. User lands on article from search engine, later shares content.

Previous to him becoming a regular user and getting an account, James was made aware of the site while going through a period of being obsessed by current affairs in North Korea and landed on an article on the site from a search on Google. He found it so informative, well-written and well-sourced that he wanted to share the link on Facebook.

User flow 2.

After James lands on the article page after a Google search, he

reads the article,

clicks the Facebook icon on the sharing tool,

uses Facebook sharing pop-up,

exits.

These scenarios are very basic, for example containing no error states (like “error 666: article not found 😮) and involving no menu navigation to other pages e.g. to the Business category using the primary navigation. This will certainly be a next step to follow up on.

brand attributes

Green notates “should be”; red “should never be.” “Yellow” is on a wrongly coloured note.

Our editorial should always be…

Fresh. Trustworthy. Clean. Modern.

But never…

Fancy. Over the top.

On reflection some of these stickies are in fact based on function, rather than characteristics that can be given to people like “daring” or “dull”. This task was therefore poorly carried out, but still gave a good sense of brand values.

brand name

With our brand attributes guiding us, we each separately played with the names for our editorial.

I tried to come up with something that would feel clean and contemporary but fresh and not overtly serious.

Brandname brainstorm

I picked a few of my favourites and brought them to the team, and, not wanting to delay the process with too much discussion, we quickly made the decision to go ahead with “Avarice.

According to Cambridge Dictionary (online):

Avarice - “an extremely strong desire to obtain or keep wealth.”

I felt like this title fit the profile; being clean and professional while simultaneously having this tongue-in-cheek, self-aware meaning that hopefully would feel fresh and make users feel more trustful of an editorial not taking itself too seriously.

Going through this process of working in a team in disarray made me appreciate the importance of good management, the huge benefits of a balanced team working fluidly, and how much ego, passion and miscommunication can get in the way of effective teamwork.

Here is the next part in this mini-series: Part 2. Prototyping & UI.

--

--