I’m all about
designing things
that put people

Hi, I’m Noah and I’m a product designer with 7 years in the fields of UI/UX, print and brand design. I’m a devout user-centrist and believe in building cohesive and intuitive experiences that put people first, and simply get jobs done. See my case studies below to get an idea of how I do this. I’m based in 🇭🇰 and looking for fulltime work, if you think we’d be a match please get in touch.

1 3 Longform case study

Updating the
beauty industry
in Hong Kong

BloomMe is a startup founded in Hong Kong that provides business management tools for beauty service vendors, and a companion mobile app which customers use to discover and book on-demand discounted services from vendors on the BloomMe platform. This creates a seamless experience for the business, and the customer, and it’s transforming a pen and paper industry.


BloomMe (4 weeks)


Wireframes, branding & design system

The BloomMe Products

BloomMe is available to consumers via native apps on iOS and Android, and the business management product is delivered in-browser as a web app.

I was contracted to help BloomMe implement new features for the business management product, and create a branded design system to roll out across the new features and the rest of the existing platform. The work was conducted over a four week period, working with the BloomMe management team in Hong Kong and their engineering team in Israel.

At the time the business product was capable of managing bookings, bookable services, staff and payments. This mirrored the functionality of the consumer-facing mobile app which listed a businesses services', pricing and booking availability. But after a year and half on the market businesses wanted more. The most frequent request was for inventory and supplier management tools. It was a key piece of the equation as each service required different consumables, and every business managed its own stock. Not knowing or being able to track what is on hand and what is being used could lead to unfulfilled bookings, reflecting poorly on the business and BloomMe. Building out these features would be a step closer to BloomMe being an all-in-one management solution.

Before adding new functionality the design of the business platform needed to be addressed. It had worked so far but it was messy and not something BloomMe wanted to scale with. Feedback from users echoed this need with some abandoning the business management tools even though they continued to pay for them. With the right design system and a clearly communicated set of guidelines, BloomMe could continue to build out new features, maintain consistency, and incentivise its users to engage with the all the tools on offer.

Flow mapping

To begin I mapped out the new inventory and supplier management features starting with flow maps and wireframes. We wanted to create these in their most ideal forms first, to challenge the existing systems limitations and evaluate opportunity costs where things could change. I relied on BloomMes knowledge of the platform to do this effectively, given the short timeframe. Together we created a set of principles to guide the work:

(1)   Any solution had to be simple, easily understood and deliver multiple times the value of a pen and paper system

(2)   Designs had to accomodate multi-language implementation in the future - specifically English and Chinese

(3)   The design system would need to be easily adapted to use-cases outside of the new feature set for it to be applied by the dev team to the existing platform


I started the wireframes by thinking of products, orders and suppliers all as simple data entries. For the most part you could import, view, search, filter, create, edit and remove them. This aligned with the existing system in how it treated bookings, services and staff, and like the rest of the system, these entries would primarily live in tables. This helped us compare our ideas for the new sections and how they would be adopted by the existing sections.

Our early ideas for improving the platform focused on making text legible in size and contrast, adding assistive search, introducing pathways to help and live filtering options. We used English as the placeholder language to test spacing as it almost always runs much longer than written Chinese.

Over a week I delivered the complete package of wireframes. This was the first time that there was significant change to the platform since it had been built and it was important to communicate clearly the functionality and intention behind the new features. We setup tour points and notes for each page in Invision to help onboard everyone and detail the minutiae.

Wireframe templating

The first package of wireframes covered just over 70 screens across the new features and some examples of how existing sections could adapt based on the proposed updates.

Design systems

The existing branding system was lightweight and up until this point had not been utilised on the business product outside of a logo and some colour. This was a huge opportunity area as the final design system would align the B2B platform and could potentially be adapted in other touch-points of the brand.

The main objective of the branding was to ensure that the density of information on a screen was not overwhelming and that navigation and action items were clearly identifiable. Supporting this would be simple helper language to prompt and direct users along the way. Visually we wanted something approachable and legible but not overly plain or typically SaaS-y. I was given creative freedom to translate these goals into a new brand system covering colours, typography, and on page elements.

To accompany the designs I built a styleguide which detailed colours, typography and UI elements. This was would supplement the rest of the flows that were in the wireframes, and for rollout across the existing business platform. At the time BloomMe had no in-house designers to adopt and translate this for the rest of the business so we made sure each section had accompanying instructions and explanation, along with explicit rules and guidelines.

The styleguide was delivered as a PDF and a Sketch file using a component and state system with layered smart objects. Creating the Sketch file took up more time than what we had budgeted but it was a powerful tool and would save BloomMe a lot of time maintaining and rolling out the new design system.

Outcomes & reflections

Working with BloomMe I was able to get up-close with how a startup manages both a B2B and B2C product stream. The bottom line seems to be; one can't flourish if the other is floundering. In this case, businesses were putting money down but only half were using the full suite of tools built for them. Exposure to a new customer base and receiving bookings were worth the price of admission but not engaging with the business product makes the booking system unreliable and undermines BloomMe's service value for all parties.

We were able to make a great start on incentivising businesses to use the platform on its own merits, by unifying the way in which the product is presented and functions, and introducing features businesses needed to more effectively manage operations online. At the conclusion of the project I was proud that BloomMe had full confidence in implementing the design system given there were no in-house designers at the time. I credit that to regular communication with client parties in Hong Kong and Israel, and building detailed documentation with all involved from day one.

If we'd had a larger scope I would have liked to investigate further why some businesses were not using the platform fully. Was it just a by-product of bridging the gap from pen and paper to a completely online format? Or something else? Also due to time constraints our designs entered implementation untested, but given the nature of startups, existing customer feedback, and business direction from BloomMe I felt confident at the time that our work would be effective. And I was right! Since we wrapped BloomMe has implemented these features to great response, expanded to Taiwan and have reached 1800+ Businesses using the platform.

2 3 Longform case study

for disruption
in the City of Melbourne

The City of Melbourne is the fastest growing city in Australia and the fourth fastest
growing developed city in the world.  It’s home to 170,000 residents, 32,000 small businesses and has an average weekday population close to a million people.
As infrastructure and development projects increase to support growth so too
does disruption for the cities population. It’s a fine balancing act and the City of
Melbourne are committed to getting it right.


City of Melbourne (12 weeks)


User insights, hi-fi prototypes, data strategy

Day to day disruption in the city

Disruption is typically caused by construction, repairs, maintenance, events and emergencies. The impacts of a disruption are relative to the individual but in varying degrees, they can be felt by everyone in the city.

I worked with CoMs human-centred design team Citylab over 12 weeks, across two design sprints on researching and testing digital solutions to disruption within the city. My job was to help form and implement research strategy, facilitate workshops, generate insights, map data processes and opportunities, and lead the building of prototypes with city users and partners. Our project was designed to focus on:

(1)   In-depth research and testing of prototypes with; city users, internal CoM teams, and third-party disruption partners such as utility companies and major infrastructure project owners and,

(2)   Reviewing CoMs data collection processes and exploring ways of improving and sharing internal data, and opportunities to ingest external data-sets through partnerships with third parties.

The core project team was made up of three full-timers with additional part-time support from internal CoM branches. A typical week for us would include testing and research on Monday and Tuesday, synthing and refinement of research and prototypes across Wednesday and Thursday, and Friday to share-back and plan for the following week. In practice, everyday was different but daily stand-ups and checkouts kept us moving together.

Our learnings from first sprint identified two groups who were most impacted by disruption: Residents and small to medium size Businesses within the city. Disruptions were varied, frequent and the impacts could be felt for months or sometimes years as works progresses. Finding relevant information to understand and mitigate impacts was time-consuming and sometimes impossible because of regulation requirements. Designing for these groups was the clear priority for the next sprint. To frame this, we created a how might we statement:

How might we

Connect people to works so that they can shape their experience of their place now and in the future?

Deeper research

Over the first few weeks, we went out to community centres, businesses, and on the street to hear about our audiences experiences with disruption. We gathered feedback and ideas around the current state of disruption, recounting experiences when they had been affected and if any, what actions were taken to mitigate impacts.

Disruptions could range from small maintenance and cleanliness issues such as an overturned bin or an overflowing drain, to finding building access suddenly blocked because of construction or a whole laneway of public carparks reserved without notice. Lack of information was a persistent issue, and it meant starting the investigation process repeatedly. On the whole Residents and Businesses knew there was no getting rid of disruption entirely but if CoM knew about a disruption ahead of time, why couldn’t they?

Inside CoM we began to understand the ways in which disruption is managed between teams, outwardly with Residents and Businesses, and with “disruption partners” like construction companies and transport networks. Disruption queries and reports from the public were typically filtered through the Customer Relations team by phone calls and emails. The investigation process was largely dependent on what the disruption was, and in most cases, it required follow up with other internal departments, and sometimes with disruption partners. But in every case the question of “who was responsible?” would come up. 

For CoM there is a clear separation between private and public works but for Residents and Businesses, there was little to no differentiation. For them, if disruption was in the city, then CoM would be the first point of contact to find out more or report a problem. This got us thinking about ownership - what parts of disruption should or would CoM want to own? What is realistic and sustainable? How could we share the responsibility with disruption partners?

Early ideas

The first prototypes were designed to test specific actions a user might take to mitigate disruption impacts including, browsing disruptions, creating notifications for disruptions and, reporting a disruption. These actions were split into separate flows so we could test an idea in isolation and prompt users to tell us what was missing.

City of Melbourne: Disruption characteristics vs. level of detail

We then gauged which platforms and services users would prefer to find and receive information from and measured how frequently users would want or expect to engage with them. Comparing these factors would give an indication of feasibility over time for a delivery method. For example, all users indicated that in-place signage would be the most useful in the first instance of disruption. But for more information or to stay up to date with developments, they would have to move to other platforms such as an app or website.

City of Melbourne: Delivery methods vs. desirability

Finding the data

Next we looked at CoM’s internal datasets to see what data was available and what level of detail it was in. Collating this information and mapping internal data flow was an extensive exercise as no-one had documented exactly how disruption data was recorded between teams and interpreted across the business. To do this, we sat down with individual teams and got into the details with each to understand the information they collected, how they collected it, where was it entered and what happened to it next.

In documenting these processes we uncovered overlap between departments. This presented immediate opportunities to optimise collection and in one case it sparked a new initiative that would better enforce construction regulations by adding more on ground site inspectors. This would yield more detailed disruption data, increase frequency of monitoring and issuing of fines where needed and discourage practices that contributed to disruption in the city.

CoM Data flow map

Some of the early data flow map an

The full version of this is huge, and as it was being built, we questioned if it was worth the effort as it needed input from many teams and many more revisions to finalise. But it became one of the most powerful tools to communicate the project internally and show how crucial each arm of CoM was in organisational data.

The completed data map confirmed CoM was in a good place to deliver some pieces of the puzzle but engaging with externals was essential to create a holistic view of disruption in the city. We reached out to utility providers, transit authorities, startups in the civic services and accessibility space, universities, and cross-government. Aside from understanding what external data could be pulled in, we also wanted to gauge interest levels for pushing out CoM’s data via their OpenData platform.

A key motivator for data-sharing across all of our disruption partners was in the coordination of capital works. A common disruption story from our users was seeing the same footpath or road being ripped up and repaired frequently in a short time. Obviously, this creates a lot of disruption - noise, dust, lack of access, potential interruption to utility services etc. but it also reflects negatively on CoM as it is seen as inefficient and wasteful. Between CoM and our disruption partners, they could save a lot of time and money if there was a way to coordinate these activities.

To test this CoM was running a pilot program of a planning collaboration platform called SmarterWx and with the OpenData team, we used this an opportunity to test an alpha version of data standards with our partners. Feedback on the pilot helped us understand what data partners were interested in and which datasets to prioritise if they weren’t already published as part of the OpenData platform.

To illustrate how all of this data would help Businesses and Residents we created a service flow map (below) connecting the needs and sentiments of the user represented as specific input/output data points, and the relevant data sources that could push and pull the information.

CoM Service flow map

Some of the early service flow map

This helped us map the lived experience of disruption in relation to the actions and information users desired, and the data sets that could support them. We used this in tandem with the final prototypes to solidify how good data underpinned all of the proposed solutions.

Our research and testing guided us in creating four distinct prototypes. They are designed as companion products and services. Users may interact with one or all of them at different times depending on how they are impacted by disruption. Each leverages a different platform for delivery but all rely on having a cohesive disruption database to push to and pull information from. We presented these along with our learnings over the sprint in a final showcase for internal and external partners, and as part of a formalised report.

Directory web app

Explore a holistic, map-based directory of disruption and future developments in the city. The Directory presents information from an impacts and benefits first perspective enabling users to self-serve and understand disruption in their own context. It provides avenues for reporting and giving feedback and allows users to subscribe to areas and activities for future updates.

Directory Prototype demo

The final versions of the prototype were styled using CoM's brand guidelines - all the way down to the map styles which our cartographer shared from Mapbox. The screens were assembled in Sketch and Invision to test the interactions.

The Directory is the focal point among the prototypes and is positioned to receive the bulk of referrals from the other products and services. It's functionally robust but ideally users wouldn’t need to repeat searching for and discovering new information more than a few times. It’s designed so the user can find relevant disruptions and areas to subscribe to, and from that point on the Directory serves primarily to deliver information in notifications. This provides a more convenient experience and makes it much faster to digest relevant information.

Next to discovery, reporting is the other core area of the app. Like the earlier prototypes, it asks users to profile a disruption by describing where it is, what it is, the impacts, and to include a photo or video of the disruption. We added an area which checks for known disruptions in the area to reduce duplicate reports and provide relevant information in the moment.

The Directory was pitched as a responsive web app to support the need for information across devices. This felt appropriate as an MVP as it would have the widest reach. Moving forward a native app for mobile platforms would afford greater convenience and integration potential.

Integrated Services (API)

Sharing CoM disruption data with partners and distributing data to apps and tools that users already engage with. The Integrated Services prototype shows the power of aggregated data between CoM and disruption partners, and the benefit of sharing this with third-party services. This allows disruption information to be surfaced via the products and services people already use and opens up opportunities for new innovations to be created by making this data available.

CoM data on third party services

Talking to the potential of data in words and large flow maps becomes dry, fast. Especially for something as intangible as an API. The solution? Mockups.

Testing this prototype was largely an effort in understanding CoM’s data capabilities, those of our disruption partners and ways of collating and distributing data to third-party services. The data section above this goes deeper into how we did this and what it achieved. Besides the aforementioned outcomes, some highlights include: Formalising a data sharing agreement with Waze, talks with CityMapper, Emergency Services VIC and VicRoads to begin sharing, and meeting with universities and startups to understand what CoM data would help enable current and future projects in the accessibility and civic service spaces.


Ask, report and subscribe to disruption and future developments in the city. The Chatbot is targeted to people experiencing disruption in the moment, when they are out and about, by surfacing a condensed version of disruption and future developments information. Users can report disruption within chat and subscribe to areas and activities for future updates. This service leverages the Directory and external partner sites to refer users for more information.

Chatbot Prototype demo

The final iterations of the chatbot were created in Chatfuel which delivers chat prototypes using the Facebook Messenger platform. We were able to plugin a mix of real data from disruption partners as well as mock information to represent an ideal view.

We tested versions with more personality but found that users favoured brevity and speed in the form of pithy and factual language. This made better use of the limited screen space and reduced the time and effort needed to get a job done.

Current chatbot technology provides a great deal of flexibility in the deployment and integration of chat services across social channels, SMS, web and mobile. In addition, most platforms include multilingual support. These conveniences mean that a single instance of a chatbot can operate natively across most touch points of a business. One of the applications we investigated was using the chatbot as a referral service directing users to the Customer Representative team and integrating with their existing case management tools. This would streamline customer engagement and reduce unnecessary queries if the chatbot could provide the right information.

In-Place Signage

Communicating impacts and benefits on the ground at sites of disruption and across the city. In-place signage provides information for works that would otherwise have little to no communication of disruption impacts. This helps to create a ground level holistic view of disruption for users and serves as a call to action for CoM’s digital tools for future use.

Signage prototypes & scenarios

It wasn’t necessary to take these into hi-fi iterations as the concept of signage is understood. Instead, we illustrated the scenarios in which signage would be best applied and some ways it could refer to companion products and services.

In-place signage is one of the most immediate and effective solutions for disruption communication. It displays information in snapshot format which can be tailored to a single disruption or a collection of works. The idea is that signage templates would be used by CoM and disruption partners, and generated dynamically through data-sharing programs. But regardless of its supporting tech, signage is a cheap and easily scalable method of delivering timely and relevant disruption information to people in the moment.

Outcomes & reflections

Kudos for making it this far! My goal for this case study was to convey the detail and length to which we investigated our solutions from the standpoint of the user, CoM, our disruption partners, and third-party services. Due to scope of this audience we mainly focused on research and developing programs to evaluate and share disruption data. It was a lot to get across but giving everyone a seat at the table took us beyond the brief and into actual cross-organisation implementation before we even finished the project. This was a big achievement considering our timeframe and I credit it to this to three things:

  • ✅  Constant, planned engagement
    Altogether we spent about 40% of total project time with city users, disruption partners and service providers.
  • ✅  Refining our understanding of the problem
    This included our internal stakeholders but mainly focused on people and organisations outside of CoM. Speaking their language allowed us to contextualise their role within the project and disruption in general. It built trust, collaboration and extended our support systems.
  • ✅  Operating in a large non-siloed organisation
    All credit to Citylab and CoM for cultivating an environment that encourages and actively creates cross-team initiatives.

In hindsight, it's easy to recognise these as strengths but sometimes I wasn’t sure where we would end up given how many stakeholders there were. There is a real risk for initiatives like these ending up as “talk-fests” ham-strung by overwhelming amounts of consultation and slow decision-making due to the sheer amount of choice. I bounced between excitement and anxiety at the possibilities of and commitment to this kind of collaboration. But this lead to everyone seeing themselves in the problem and its solution. So when we were answering the key question of disruption ownership in the city, we arrived at solutions which shared responsibility and benefitted contributing parties many times over.

Due to this approach CoM data is now available via third party services like Waze, and third party data is being integrated in the planning of private and capital works as part of the SmarterWX program. The learnings from our investigation into CoM’s data are also forming the basis for larger initiatives between CoM and state government to educate people about organisational data.

I learned a lot from my time with Citylab but the key takeaway for me is to create more opportunities for participation when designing, as prioritising these efforts leads to a shared vision that people believe in and can own a part of. It was also my first time up-close and personal with legit service designers and I never want to work without them again.

3 3 Longform case study

Improving the Designer News experience

Designer News is a large, online community of people working in the fields of design and technology. It serves as a place for people to share and discuss ideas, news, events and developments in the industry. The community was launched in 2013 and now boasts 110,000 users visiting from all over the world.


Self-initiated (1 week)


User insights, hi-fi designs

Designer News on desktop

This is the homepage of Designer News. The website is served as a simple message board similar to Hacker News or a subreddit.

I've been a member of Designer News (DN) for close to 5 years and use it regularly to catch up on happenings in the design community. Over time I have shifted more to Twitter and Medium but I kept coming back to DN for its community discussions and the curation of stories, AMA's and other original content. This year I found myself visiting less and less as the platform was increasingly infiltrated by spam, vote manipulation and low quality, self-promotional content. This put the community at odds and became the primary talking point in most posts and discussions.

To help the resolve these issues I reached out to become a volunteer moderator. I was able to remove spam posts and ban users but there was still obvious manipulation of the platform occurring which moderators had no control over. I wanted to challenge myself to come up with some ideas to put Designer News back on the right track so I put aside 7 days and created a HMW statement to guide the exploration:

How might we

Reduce the influence of bad actors & improve the Designer News experience in general?

By the end of the sprint I wanted to:

(1)   Gauge general user behaviour, sentiments and ideas for improvements to the platform, desirability for a mobile specific solution, and if warranted experiment with ideas for one

(2)   Provide recommendations and actions to the owners of Designer News to reduce potential for abuse

(3)   Create a list of amendments to the DN community guidelines to set a baseline quality for content and further limit opportunities for manipulation and spam

To kick off the exploration I created a survey using Google Forms, to understand the DN audience position on all of the above. At the same time I planned an audit of the newest accounts created on DN to see if I could gauge if spam-like accounts were being created, and whether I could identify any acts of platform manipulation.



Next I manually audited some of the newest accounts created on DN to see if it was possible to identify bad actors from account information and behaviour. If it was effective it could a long way to reducing the current issues with spam and manipulation. I went through 220 of the newest accounts as this number represented about 7 days worth of sign ups. Accounts flagged as "suspicious" had to match one or more of the following criteria:

(1)   Displayed overtly spam-like / unrelated handles, names or job titles eg. "Driving West Motor School"

(2)   Shared a common sign-up IP address with one or more new accounts created in the same period

(3)   Had no other account activity except voting on the same stories as other new accounts, regardless of their IP address, within the same period

While these weren't absolute definitions of a bad actor, the criteria flagged 66 accounts and one likely case of manipulation within the 7 day period. Of the 66 accounts, 45 of those had spam-like names, business or website handles associated with them such as escorts, waste removal services or just gibberish.

Account Auditing

I used Google Sheets to manually record the basic account information of the users I audited. Note: to protect users privacy I’ve blurred account information.

33 of the flagged accounts came from just 5 IP addresses. Within each IP address group, each account was created at the same time, usually one after the other as indicated by their user number. 16 of those 33 came from one IP address, with accounts created on the same day, one after the other, all voting for a story published on the same day as the accounts were created. This story became the number one post and stayed there for about 48 hours. Another possible case was identical in execution with 5 accounts created on the same day as the upvoted post, this time sharing the same IP as the user who posted the story.

I was surprised at the ratio of flagged accounts as my criteria felt reasonable but given the timeframe of my experiment and the miniscule sample size, these numbers would need to be taken with a hefty grain of salt and could not be representative of the community as a whole. However my method seemed effective in id'ing accounts for further investigation, and in one case highlighted what was likely voting manipulation.


Before entering the design phase I referred back to the survey to understand what parts of the DN website users most frequented, areas that were unused, where problems existed, and opportunities and ideas to innovate.

Areas of activity

This is the Stories page which is the "homepage" of DN. Highlighted are areas of frequent use in green, occasional use in yellow, and rare to never used in pink.

Primarily users visited DN to browse stories. The "Jobs" section was occasionally visited. "Podcast" and everything hidden within the tertiary menu was almost never used. Sections like "Terms / Privacy" and "Guidelines" are always low in engagement but are required, and areas like "Advertise" and "Post a Job" are not relevant to the sign up audience. But most other areas targeted to everyday users like "Podcast", "Things" and "Gallery" had not been maintained and were never used. Search was also almost never used - I suspect because it favours much older posts and the results list is limited to 10-20 items per search.

Within stories users would mostly look for news, events, discussion topics, and folio showcases. The most preferred method of sorting stories was by recent, followed closely by top of the day, and occasionally by top of the week. Sorting by badge type eg. story, podcast etc. was rarely used, and sorting by top of month or top of year was mostly rarely or never used.


Next I created a list of basic requirements for the mobile app. Reading stories would be the core focus, and making it easy for the user to discover, share and report. I also wanted to explore how a comprehensive search function could make the mobile platform suitable for deep engagement. I started sketching out ideas for flows and how users could move between different tasks. I used iOS as the base platform as 75% of respondents reported this to be their day-to-day platform.

CoM Data flow map

Some of the wireframe exploration

When exploring ideas I typically start with pen and paper and go wide, then into Procreate to refine the better options, and then Sketch to deep-dive into the best options. Given the timeframe I only moved through this cycle once but usually I bounce through this process many times as new insights and feedback are generated.

I was satisfied with resolving some ideas in rough wireframes but I moved into hifi design to see how things could work together. The major areas I was able to experiment with were stories, search, and share + report.

The visual design of the app inherited DN's primary typeface Whitney, and brand blue colour. I introduced secondary typefaces and colours where necessary along with a mix of custom icons. A key consideration was balancing legibility and screen space. I erred on the side of legibility trying to keep text large enough with decent contrast ratios across the flows. In the same vein I wanted functionality to be largely obvious while relying on expected interactions present in iOS and popular apps to direct users eg. swipe left to go back, pull down to refresh etc.

Stories flow

The app opens into a list of stories as the stories section had the highest engagement on the website. Stories are presented in a vertical list which can be sorted by new, or top of day, week, month, and year. To sort stories the user can tap and hold on the stories icon in the bottom action menu to bring up an interstitial sorting menu.

Stories flow

The action bar at the base of the screen provides quick access to saved items, submit a story, the stories feed, search, and activity notifications such as replies. Account settings are available in the top left of the stories feed, which displays the users DN avatar as a shortcut.

Each story is presented with a title, upvote and comment count, and author name. If a story has a link, it is included as a small box containing the logo or favicon of the referring site as an image, and its URL, so users have an idea of where they will be taken before engaging. By tapping on the link the site is served within an in-app browser.

The content of a story can be accessed by tapping on its title, taking the user to the discussion area. Users can upvote, save and share the story and, can report it if it is suspicious. By commenting users can can respond to the original poster or to posters within the discussion. Comments can be also be upvoted, collapsed, copied or reported for spam and users can view profiles of other members by tapping on their handle.

Share & report flow

A key goal of the app was to make contributing stories and comments easy, and provide consistent pathways to report stories, users and comments.

Share & report flow

In addition to reporting, moderators would have options to delete posts, and ban users, allowing them to moderate the community within the app. This could extend to receiving notifications of user generated reports to assist the DN admin teams moderation efforts.

Users are able to post DN via their browser from the iOS sharing menu. A preview of the story is displayed with the title of the post pre-filled. Back in the app, a button is displayed to notify users of any new stories that are available.

Reporting can be initiated from the stories feed, within a story or on a users profile. When a report is created the user selects the most appropriate reason for a report before sending it to the DN team. Reported stories, comments, and users are then marked for the user moving forward.

Search flow

Search was an area which presented a lot of opportunity for optimisation. The value of communities like DN to its user-base is in the curation of content and discussion of niche topics. But the problems of the current search meant anything older than a week or two was largely inaccessible.

Search flow

Originally I designed search to be a tertiary function of the stories feed but resolving story sorting methods and search results filtering simultaneously, presented too many clashes.

Within search a user can re-use their most recent search queries or start a new search. Search results are displayed in a tabbed format so the user can isolate matches between stories, users, and comments. Within these groups, results can be sorted between relevancy, newest, number of upvotes, and time, ranging from "all time" to "today". In the example flow the user is able to find the latest stories relating to folios from the past month in just a few steps.

Outcomes & reflections

The work covered in this case study was largely catalysed from the problems I could see emerging within DN and my opinions of how they could be fixed. But from time spent as a user and moderator, and the sentiments and concerns voiced by the community in separate posts and comments, I believe my work was representative of more than just my own feelings and assumptions. With that said there were many restrictions and oversights given the one week time-frame I committed to:

  • ❗Limited survey audience
    With additional time I would perform more in depth, repeated surveying with a wider audience to garner more meaningful results
  • ❗No access to analytics
    The Semrush analytics corroborated the limited crossover data with the survey, but stats like what users search for, how long they spend on site and new vs returning users would point future efforts in a better direction
  • ❗No testing of the designs
    For these to have any legs they would need testing with users to understand viability and desirability. As it stands these are purely experimental but at the very least demonstrate some optimisations which could be fed into the website

Despite the shortcomings of the experiment, I was able to provide recommendations to the DN owners in reducing spam and abuse to the platform, and amendments to the guidelines to help steer content and behaviour. Looking at the new user sample there were some obvious behaviours linked to spam and manipulation which could be reduced in the future by:

  • ✅  Pre sign up measures
    Including monitoring IP addresses for multiple sign ups,introducing a honeypot field within the sign up form in case bots are creating accounts and considering switching to SSO account creation for better authentication
  • ✅  Post sign up measures
    Including shadow-banning users to discourage undesirable behaviour once inside DN and creating a list of keywords that could be detected in forms and posts to id spam

This experience has given me a real appreciation for the amount of effort and work required to build and maintain a community. I am confident that the proposed changes would make a positive impact on DN but they would require a lot of work both from the owners and the users. In the short term I see benefits in creating dialogue and transparency around the future of DN from the owners as well as vocalising any commitments in reducing spam and manipulation. Only then would users be likely to start contributing more content and creating discussion inline with what DN aims to be.

Build notes

This is V1.1 of my folio. It is held together by CSS Grid, Flexbox, and Plumber. Navigation uses the Intersection Observer API. Galleries are from Flickity. Typefaces are; Aspic for headings, Tisa for body copy, Improv New Wide Nine for feature copy, Inter for supporting copy and, Woodford Bourne for small caps. Site and media hosted on Netlify. Any work presented here is for folio purposes only, all clients retain copyright of their respective materials.

© Noah Scott 2020