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.
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
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.
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
These looked comprehensive on paper but we needed to test these as wireframes to get the best feel for how these would work. Given the detail required to demonstrate the flows, it made sense to invest most of the project time in this phase by developing the design system as wireframe components first. This would allow us to revise functionality quickly, and experiment with layout and the elements of the design system in increasing fidelity. And if done correctly I would only need to apply high-level design to a handful of screens to communicate the application of the design system.
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.
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.
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.
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
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?
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?
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.
We tested these at sites around the city, and hosted our first in-house workshops for Residents and Businesses. The group setting helped create a natural discussion about disruption experiences and allowed us to get deeper into research activities. We used questionnaires and card-sorting activities to map expectations and prioritise the needs and desirability of information that would help minimise disruption impacts. Some key takeaways were:
Disruption is first experienced in-place
Disruption is typically experienced in-place and without prior knowledge. Sometimes users receive prior warning by mail, public signage, social and traditional media.
Serving disruption information on-site, and in public spaces was a key opportunity for users to understand impacts in the moment and plan accordingly.
Impacts matter most, but they are hard to gauge
Users care most about how a disruption will impact them. But it is difficult to gauge impact level up front and time consuming to seek relevant and trustworthy information.
When communicating disruption information, it needs to be easily translatable to the impacts an individual or business could expect.
Impacts can change from day to day
Over time the impacts of a disruption will change, even if the disruption itself remains consistent. For most users this was impossible to predict and track.
Presenting a timeline of expected disruption impacts would help users understand the potential impacts of a disruption now and in the future, and allow them to plan accordingly.
& reporting go hand
Users typically report disruptions regardless of impact level directly to them. But if there is no follow up, or issues persist beyond expectations, they are unlikely to report in the future.
Users see disruption as a shared experience, and a shared responsibility. They want the tools to help and reassurance that any information provided won’t just disappear into a black-hole.
With these insights in mind, we had a clearer picture of how disruption is experienced and how changeable it can be. From this feedback, we generated quantitive insights to specify what information was helpful, and how it should be delivered. The graph below illustrates the relationship between disruption characteristics and the level of detail Businesses and Residents required to understand them in a relative context. We split these into groups based on importance and assigned their position across the x-axis to represent the level of detail needed.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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:
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.
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
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.
The survey had 23 respondents over 3 days. The results echoed recent discussions about the platform and provided some ideas to amend the issues. It also uncovered new information about usage habits and some early indicators as to why mobile engagement was low. I compared findings where possible with site analytics provided from Semrush looking at trends in the same time period. Using a free account I was able to compare traffic share between desktop and mobile, and average time on site and in both cases the results and analytics aligned. From the survey the key takeaways were:
Low quality content & manipulation were the top blockers
The most frequently identified problems were those relating to low quality posts - this usually meant spam, but also covered overly self-promotional or content-marketing style stories that had markers of voting manipulation
Respondents wanted action from DN owners to fight this behaviour, and for DN to return to creating unique content to differentiate itself. Until then user engagement in contributing high quality posts, discussions and comments would remain low
Users were still visiting the site but weren't contributing
80% of respondents visited DN once a day, with 40% multiple times per day. 40% visited for ≤ 15 mins, another 40% between 30 mins to 1 hour with the remaining 20% 1 hour or above. 6% would occasionally post a new story, and 27% were likely to comment on a story
Respondents were visiting the site frequently but only to see what was newly available. There was some interest in contributing content but in-survey comments suggested it was not worth the effort given the influx of spam, manipulation and low-quality content
There was interest in a mobile app but it was conditional
85% of respondents rarely or never visited DN on mobile and there was roughly an even split on the need for a mobile app. Of those interested, the most popular feature requests were for native integrations and making it easier to find information
There was appetite for an app but it was unlikely to have much impact unless the larger platform issues were resolved. Respondents indicated in a best case scenario an app would split time with the website, but increase visits to DN, and usage of DN on mobile
In summary it was obvious there was a need for additional processes to reduce spam and manipulation to increase quality of content and trust in the platform. Until this problem was solved user engagement would remain shallow even though it was frequent. Naturally this problem extended to the expected engagement of a mobile app but I felt it was worth experimenting with one if the improvements could be translated easily to the desktop website.
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.
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.
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.
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.
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.
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.
A key goal of the app was to make contributing stories and comments easy, and provide consistent pathways to report stories, users and comments.
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 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.
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.
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:
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:
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.