UX case study
Ink Bloom
Overview
Ink Bloom is a start-up in the early stages of creating an MVP, founded by Dr. Ray Hsu. Ink Bloom’s mission is to “help writers hone their craft, share their work, and connect with a vibrant community of peers and professionals”.
TEAM & ROLE
-
Yun L. - UX/UI designer
-
Emily L. - UX/UI designer
-
Jason X. - UX/UI designer
-
Laura Trouiller - Mentor
​
Previous design teams contributed to the foundation of this project and are cited throughout
TIMELINE
Four weeks
​May 31st, 2024 - June 28th, 2024
THE PROBLEM
Writers are often doing their work alone, leading to loneliness and a lack of opportunities for growth.
This isolation also keeps writers in an echo chamber of feedback from their own social circle. As a team, we aimed to reduce isolation that writers experience by connecting them with a larger network of writers and professionals. As a result, writers get feedback from a more diverse group of peers to help them grow their skills.
​​
The client had a few user flows created by the previous design team and wanted us to bring him closer to an MVP. One major constraint of this MVP is that the client needed the platform to be partially monetized. He also encouraged us to test the assumptions of previous design teams as we are building off of their design.
THE SOLUTION
A website to help writers build community and get feedback
My team and I expanded on the ideas of the previous team through additional research, analysis, user testing, and multiple iterations. We designed a desktop-based website that helps writers network, build community with other writers. A key feature of the site is that writers can give and receive in-depth feedback through "Critiques".
UX process
The team used the double-diamond model to re-work this design. Although we were handed a partially completed project by the previous design team, I believe design is an iterative process. We used the foundational knowledge and design of previous teams to continue progressing toward an MVP.
Note. Adapted from the Double Diamond model, by Design Council, 2005
I. Discovery
GETTING STARTED
Catching up on past research
As a new team, we spent the first few days reading any past research and documentation from previous teams. This helped us understand how the last team arrived at their design decisions and informed our decisions moving forward.​​​
Key takeaways
01.
Users were more interested in using this as a desktop platform for core flows
02.
Writers are looking to grow their network and get feedback on their work to eventually get published
03.
Users desire a supportive community of writers to engage with.
DESIGN AUDIT
Accessibility & heuristic analysis
I collaborated with the team to identify any concerns they had about the previous design. I used these concerns as a jumping-off point to create a heuristic analysis and accessibility audit. This helped me analyze what changes needed to be made and documented for collaboration. This audit acted as a guide throughout the span of the project for the team to improve the design.
Below are visuals of key findings. To see this audit in more detail and my thought process, you can read the whole audit here
Accessibility
NNG's usability heuristics
USER INTERVIEWS
Researching a path for monetization & testing previous assumptions
While past research helped give design direction for the pain points of writers, we didn’t have much information regarding writer’s attitudes of monetization. We wanted to ensure that monetization didn’t negatively impact usability and would add value for users.
​
We also wanted to challenge the assumptions of the previous groups, as we had been asked to do by the founder. One of the previous teams did user interviews early on, recruiting members of a writing lab. As a result, the type of writer interviewed was skewed to the program the writers were sampled from. We made an effort to cast a wider net for a more diverse sample of users. We recruited writers from various areas, social circles, writing niches, and skill levels.
​
My team and I interviewed five writers via Zoom using a pre-determined script. I was tasked with synthesizing information from these interviews. Some interviewees did not feel comfortable being recorded, so my teammates did their best to take detailed notes. In a perfect world, I would have re-watched the interview to bring new perspective, but I digress. ​​
Working with the team's notes and insights, I created a thematic analysis to look for patterns between interviewees. While this can be somewhat time-consuming I find that it helps me to remove bias and see findings in new ways.
​
​Now that I had a big mess on my wall, I took the most apparent patterns in this and created a grid of notes. I started by highlighting key learnings, then used another column to write recommendations based on these learnings. You can see a cleaned up version here
RESEARCH REPORT
The user interviews allowed us to expand upon previous knowledge & understand writer's views around monetization
I organized all my findings into a more digestible report to share with the client and design team.
Key Learnings
Community
-
Highly valued as a source of inspiration, motivation, knowledge, and feedback
-
They did not feel this was worth paying for
-
-
Were excited by the possibility of getting feedback outside of their real-life social circles
-
Want to see content and meet other writers within their interests and writing niche
-
Taste in books
-
Personal writing
-
Genres they align themselves with
-
-
Reported issues with other community based platforms
-
Lack of engagement
-
Exclusivity
-
Poor usability
-
Disorganized UI
-
Mentorship
-
Was something all users were willing to pay for
-
Motivations
-
Career advancement
-
Meeting a goal
-
Getting published
-
Monetizing their writing
-
-
There was some variation in what writers look for in a mentor, some commonalities were:
-
Shared niche
-
Taste in literature
-
Quality of previous work and critiques
-
Availability
-
Knowledgeable in their niche
-
II. Ideation
HOW MIGHT WE'S
Updated based on our research
Using the information gathered in the discovery stage, my team and I began brainstorming ways we could better meet user’s needs in the next iteration. First, we brainstormed several new “how might we” questions that better fit the new research. I narrowed them down to a few that encouraged creative solutions.
Engage
Create an engaging community for writers to grow their skills?
Monetize
Create an unobtrusive path to premium for interested users?
Mentor
Help users connect with a mentor that fits their needs?
How might we . . .
USER STORIES
Updated & prioritized to focus on the MVP
Next, I updated the past group’s user stories to reflect the project goals and research. I prioritized user stories focused on community and getting feedback, while also adding a few new ones. I lowered the priority of all non-essential features such as resources, dark mode, and geolocation. While these would be nice to have, the MVP can address our “how might we’s” without them.
I did want to note that some high-priority user stories were not designed during this project. This was a decision made early on by the team based on our time constraints and what we felt would be best left for later in the process.​
SITEMAPS
The site’s organization needed to be updated to follow design heuristics and feel more intuitive to users
My team and I held a meeting to discuss our ideas around an updated sitemap. Based on the audit, we knew that the site’s organization needed to be updated to follow design heuristics and feel more intuitive to users. From our interviews, we also knew that usability and organization on a site are highly important to the writers.
​
​
Many versions of the sitemap were created by different team members before prioritizing what was most valuable and efficient for users. Sharing different sitemap concepts helped us to
-
Quickly generate ideas
-
Agree on the scope of the project
-
Align on a vision for the platform
My original sitemap
Included from my version
-
Removal of the hamburger menu and intuitive redistribution of its contents to reduce cognitive load
-
Social media-like organization to give users a sense of familiarity
-
Prioritizes engagement with other writers
-
Writing is moved into the profile to give more context as to where it is being saved and shared
-
Inclusion of following/followers so users can determine privacy settings
-
Main feed and notifications were added during wireframing
Additions from my team
-
Search is visible across the site and allows users to search the entire site
-
Addition of filter to search
-
The feedback/critique section was simplified by adding a status page
Finalized team sitemap
USER FLOWS
Revising the flow for user-generated feedback
Once I felt good about the sitemap, my team and I divided up key user flows. I decided to design the process users would take to give a critique to another writer. To stay within the timeline, I created my flow from the perspective of a regular user. This would allow the next design team to iterate a monetized flow.
​
The last team had designed a critiques feature that was within the writer's posts. In this version, any user could critique any writing, but users could also request critiques from a specific individual. Below is a version of the original critique flow designed by the previous team for reference:
Previous team's critique flow
This flow works well for short-form writing where only small changes are needed, but the writers we interviewed were more interested in an in-depth critique from a trusted source. I made this the focus in the next iteration. I also wanted to help the critic and writer set clear expectations for the critique and timeline from the beginning in hopes that this would improve user satisfaction for both parties.
User interviews
-
Writers valued feedback from others in their niche that fit their specific criteria for quality
-
Writers wanted clear, written feedback provided within a pre-determined timeline
-
Based on the way writers talked about feedback, there was an expectation that it would be more in-depth
-
Writers were more interested in using a desktop platform for this type of process
Audit
-
New users may not recognize they can highlight more than once in a critique and are required to go back after submitting to do so, causing additional slowness. (Flexibility & Efficiency of use)
I created a quick rough draft before meeting with my team so I could share my ideas and make sure my flow aligned with others.
After meeting with my team I decided to add a critique status page to simplify the process of checking critiques at each stage. With this change in mind, I revised my user flow to integrate this.
After user testing my wireframes, I adjusted this flow again to reduce decision-making on the user’s part. The “Give a critique” page was combined with the "Critique status" page. This increased findability and reduced the number of clicks.
Small changes were also made to improve user satisifaction throughout the next rounds of testing. Based on user feedback, we added a strikethrough feature and gave users the option to send a message when declining a request. Visually, you can see how I simplified the flow through each iteration, even with adding these enhancements.
III. Design & validate
EARLY STAGES
Collaborative sketches of key screens
My team and I agreed to kick off sketching by each creating proposed versions of key screens. This helped us brainstorm ideas as a group and come up with many possible solutions. Below are my sketches for the community page and profile. The hi-fi screens were the final result, designed by other members of my team.
​
Prior to sketching, my team had discussed that they would like to avoid having a main feed. While I felt that this may be confusing to users, I tried to sketch it this way to see if I could make it work. I wasn't happy with the result since it doesn't allow users to have a high-level overview of the content. I brought this concern to my team and they agreed to add a main feed.
We decided to design a profile to give users a place to share their writing portfolio and align themselves with specific niches. Profiles also provide relevant information in the decision-making process of choosing a critic. In my sketch, I focused on aligning the writer with a niche and displaying their interactions on the site. I probably under-prioritized their writing in placing so much emphasis on their activity. I feel that my team's final design of this utilizes and expands upon my sketch to give writers valuable and engaging information about one another. ​​
SKETCHES OF MY FLOWS
My messy (but effective) brainstorming process
Once we had shared our ideas about one another’s screens, I made several sketches of my flows. As shown above, when I am sharing work with others my sketches are legible.
“I like to call the sketches I create for myself ‘chaotic stream-of-consciousness’ sketches."
This messy process helps me get out as many ideas as I can super quickly and I generate better ideas as a result.
​
I had many ideas for the critique status page. I started out with ideas for different card layouts to display each critique. I quickly realized this was going to be overwhelming to any user with more than a few critiques and shifted gears to a sketching a grid layout for better scannability. Why am I sketching from bottom-to-top? Because they are my chaotic stream-of-consciousness sketches.
Next, I used this process to work on the flow for users giving critiques. Below is a wire flow (using the term loosely) that I sketched to look at possible steps a user might take to leave a critique. In this flow, users use a floating toolbar to highlight, comment, or suggest a change. I later determined suggesting a change was not needed for an MVP since the comments section can complete the same task. I added a strike-though instead for areas where commenting would be less useful.
After user testing wireframes based on the previous sketches, I found usability issues with the design. I will go into this in more detail when discussing wireframes but wanted to share my second sketch when I was brainstorming ways to fix the usability issues we encountered. You may also notice other features on this sketch that didn’t make the final cut, like “notes for writer” or a pageless format. In the end, I decided that having additional notes outside of comments wasn't needed for an MVP and having a pageless format may be less useful for writers who intend to publish offline.
COLOR PALETTE
Designing for accessibility & flexibility
The last design team created a great UI that fit the needs of their design. Since my job was to scale this design, I was looking at it through different eyes. I used the audit I created to dictate many of these design decisions.
​
I started by looking at the color palette with a focus on accessibility and design flexibility. In the audit, I found many colors were not compliant with WCAG contrast standards. I created an updated color palette that would meet WCAG standards and also allow for more flexibility across the design. For reference, the color palette created by the last design team is included.
Original by previous team
My revised palette
I kept the same primary color, as there were no accessibility issues with it. I wanted to keep the previous secondary color and work in a monochromatic color scheme, but as I tried this out, it didn’t match the upbeat vibe the previous team had established. Instead, I added a monochromatic purple secondary and tertiary color scheme based on previous accent colors. This allowed us to have more values to intuitively communicate through color while maintaining a harmonious, upbeat, color scheme.
​
I also added a larger grayscale to allow for more flexibility of use in this area. This really came in handy for some of my pages where I needed a darker background against a white page for displaying writing. It was also helpful for creating a hierarchy in text and components through value.
​
I changed the naming conventions to be more practical for a collaborative setting. Many grays are named after what they can be used for based on compliance standards. I also added labels defining the color compliance. This helped my whole team follow these standards.
​
The last team created a lot of fun, vibrant illustrations using many of the accent colors. I wanted to keep these for marketing purposes while simplifying the main colors used. You will see these colors under “Accent colors for marketing”
TYPOGRAPHY
Improving readability
I made a few small changes to the typography. By increasing the spacing on header fonts and the text height on body text to improve readability. I also added an italicized version of the body text to be used for instructions on text inputs across the site. This helped better indicate instructions vs. text without relying solely on grayscale value. Lastly, I changed the way text styles were displayed in the style guide to have all the information about the text styles accessible at a glance.
Original by previous team
My revised version
COMPONENT LIBRARY
Defining the building blocks of a clean & scalable design
The previous team had started a component library, but it was missing a lot of key components needed for the full site. We started by defining clear rules around buttons, dropdowns, inputs, and other foundational components that would be used across the site. Then, we created components more specific to certain pages. We used “Wireframing starter kit 2.0” designed by Tiago Gonçalves as a starting point for creating stylized components.
​
Below are a few of the main components I was primarily involved with designing. My main focus in designing these was to create a clear visual language for users to help them interact with the site. I wanted to keep everything very clean and simple to help users focus on their writing and the content. During user testing, many people appreciated the simplicity of the site, showing that we were successful.
THE SCREEN DESIGN PROCESS
Why wireframes?
Next, my team and I started wireframing to define our proposed changes to the design. In our initial project plan, we were going to create the updates using hi-fi screens since the previous team had already designed a few hi-fi screens. After creating the audit, looking at the limitations of our current component library, and planning new flows, I was able to persuade the team to start with wireframes to suss out usability issues early on. This saved us a ton of time that we used to update the component library.​​
CRITIQUE STATUS PAGE
Helping users track the critiques they are getting & giving in real-time
During user interviews, many users expressed the desire to have a clear timeline around the feedback they are giving and receiving. The status page helps users to access critiques they are giving and getting, view their status, and see new requests all at a glance.
Getting critiques
In my wireframe of the design, writers are able to look at the progress of their critiques, the requested date, and the due date. This meets the need writers had to have a clear timeline around their critiques, while also acting as a place users can access all their completed feedback.
My team and I recruited five writers of different experience levels to conduct moderated usability testing. This helped us find usability issues and test that our solutions solved writer’s pain points before investing time into hi-fi screens. I completed one usability test with a writer who blogs about mental health. I provided my recording and detailed notes to another team member to synthesize the data. My changes are based on the team’s findings and my ideas for improvement.
Changes
Why?
“Critiques I’m receiving” renamed “Critiques I’m getting”
Increased clarity and naming consistency across the site
“Critiques I’m getting” swapped places with “Critiques I’m giving”
​Not all users wanted to give feedback, but all wanted to get feedback. This swap prioritizes the screen all users are most interested in.
Notification dot in the tab title
​​Added to prevent users from missing new requests
Increased padding, added icons & color-coded system to status tags, added profile picture & usernames, removed underline
​I made these changes to improve scannability for users through visual indicators while removing distractions. I also followed users' asks for color coding.
My team and I recruited another five writers based on the same criteria and conducted moderated usability testing. My usability test was with a fiction ghost-writer. She declined to be recorded, but I provided my detailed notes to another team member to synthesize the data. Below are my changes to this iteration.
Changes
Why?
Removed the “requested” date column
To reduce cognitive overload viewing the status page and allow more room for the request title and for users with long names.
Pending status changed from orange to blue
Some users felt it looked similar to the overdue status, which has a more negative connotation.
Moved the location and padding of the “Critique status” title
Standardized with changes other team members had made to their screens
Giving critiques
The wireframe for giving critiques is quite similar to that of getting critiques. The purpose of this page is to help writers giving critiques meet their deadlines and easily access all critiques they are giving.
While there weren’t any issues with this section during user testing, we reorganized the flow of giving critiques to make this page more valuable to users
Simplifying the process to accept & decline critiques
Early in the design process, the flow for accepting critiques was a bit different. Users would access a “give a critique” page to accept and decline requests.
View details
Accept
Critique now
Start your critique
While no one had any issues with this flow during user testing, my team, my mentor, and I all agreed that this could be simplified by removing this page and reorganizing the flow. In the next iteration, I removed the “Give a critique” page and integrated the accept/decline feature with the critique status page. In order to accept or decline, they must first view the details of the request, to encourage clear expectations between the writer and critic before the request is accepted. I user tested this flow again on the hi-fi screens to see if there were any usability issues with the simplified flow.
View details
Accept
Changes
Why?
Optional choice to send a message when declining a critique
Users said they would want to explain why they were declining a request
Changed request dividers size, color, and added side stroke.
Light purple was being used in other areas of the site to indicate an active state and competing for attention with purple text. Width was changed for a cleaner UI. A side stroke was added to visually differentiate from other rows.
GIVING A CRITIQUE
A space for writers to effectively critique a work
With little time to do research, I created the critiquing flow after looking at the feedback features on Google Docs, Notion, and Quip. I looked at what they did well and also picked up some of their shortcomings to avoid. One issue users reported having on other writing platforms was having to “learn” how to use it through extensive tutorials. I knew I needed to create a simple, but impactful tool that anyone could quickly understand.
​
During user interviews, one user pointed out that they may leave a site once they find “their people”. If a critic is unhappy with this process, they could leave the site with the writers they have established a working relationship with. With this in mind, I knew this feature would need to perform at a level that exceeds the expectations of users.
Note. Adapted from the Double Diamond model, by Design Council, 2005
The first version of this screen includes a highlight button. Users must follow the flow below to highlight or comment.
Highlight
Color picker
Comment
During user testing, many users had issues completing this flow. Below are all the changes I made based on my findings.
Changes
Why?
Redesigned flow so that users didn’t need to click a button to begin highlighting
Users were naturally following this pattern and failing to complete the task. Removing the button removed the obstacle keeping users from successfully using this feature.
Adding option to strikethrough
Gives users an additional way to provide feedback that is crucial to the editing process
Implementing more hierarchy between buttons, tags, and titles
Users were clicking “mark as complete” instead of going back when they weren’t done.
Animation and brief blurb of instructions
Some users asked for clearer instructions on how to use this page. I kept is extremely brief to avoid feeling like a tutorial.
Adding a header and footer menu and implementing a clearer hierarchy
Users were clicking “mark as complete” after making a single change. Moving it away from the “back” button and changing the hierarchy helps differentiate the two. Creating a clearer hierarchy also helps organize the page and reduce distractions.
Request details accessible from this page
Since I changed the flow to no longer show request details prior to accessing this page, I added it within the header.
Direct messaging button within the page
During user testing, many users indicated they would like to be able to message the person they are giving feedback to. While they can do this from DM’s, that would take them out of this flow and create additional distractions.
In the first round of testing, this flow had the most issues. By this last round all issues had been resolved and no new ones were identified in testing. That being said, I still wanted to make a few small changes based on my reflections, feedback from my mentor, and suggestions from my team to improve the design.
Changes
Why?
Changed direct message button to light gray
Differentiates the DM button from the writer’s name.
Animation and instructions placed inside a card
Better groups the information to communicate that clicking “hide” hides the animation and text. This feature reduces distraction.
THE NAVIGATION BAR
Reorganizing navigation to reduce the need for recall
The original navigation bar for Ink Bloom was created by the previous team and was designed to organize most pages in a hamburger menu. Since I had eliminated the need for the hamburger menu when my team and I updated the sitemap, I needed to design a navigation that fit the new IA. Below is the original navigation bar designed by the last team for reference.
Previous team's navigation bar design
The navigation bar began as a team effort to ensure that was in alignment with the functionality of each page. We created a rough navigation bar before anyone started sketching to accomplish this. In this version, we reduced the thirteen items in the hamburger menu and navigation to five visible options
Changes
Why?
“Groups” in the navigation to replace “Community” in the hamburger menu
This communicated the core function of joining different groups and needed to be a main option because interacting with people in groups is a core interaction on the site.
“Critiques” was added to the navigation
This communicates that users could find all feedback-related features in that area. This was prioritized highly because giving/getting feedback is another core interaction of the site.
Other menu items that were lower priority were moved to corresponding areas on the site.
This de-clutters the navigation bar and puts these features in intuitive areas where users would expect to find them.
Removed “topics you follow” section
This wasn’t relevant on every page. We added a similar sidebar menu under “Groups” that performs this function in a relevant space.
During the wireframing process, another team member cleaned up the design into a component. She also created a version with page titles as this worked well within the design of the “Groups” part of the site.
After user testing our wireframes, another teammate and I took on the re-design of the navigation bar. I shared a few design options with my team and landed on the one below.
Changes
Why?
Reduced text size of “Groups” and “Critiques”
During user testing, several users would confuse the “Groups” button on the navigation bar with the “Groups” button in a subnavigation on the search page. I reduced the size of this button to make it less distracting from other features.
Added a dropdown to “Critiques”
This reduced the need for a sub-navigation bar that took up screen real estate on the critiques pages.
Removed the title bar
This wasn’t useful in most cases and was more of a distraction. Designers working on relevant pages were able to design new solutions.
After user testing our wireframes, another teammate and I took on the re-design of the navigation bar. I shared a few design options with my team and landed on the one below.
Changes
Why?
Clicking the logo in the navigation leads to the main feed as well.​
Many users would click the logo to get back to the main feed and found it wasn’t clickable.
Renamed “Groups” to “Community”
After coming full circle, we felt that “Community” better described this area of the site with the addition of direct messaging and a main feed.
Added dropdown to “Community”
Some users weren’t noticing the different options in the sidebar navigation. This was suggested by a group member in charge of the “Community” design as a solution.
PROTOTYPE
Check out the prototypes we used throughout the project
We created a prototype of the wireframes in Figma to complete moderated usability tests. After iterating on our design, we prototyped the first draft of hi-fi screens in Figma to do a second round of usability testing. While we did not do a third round, I felt it was necessary to create an updated hi-fi prototype based on the user testing findings to improve the current design. This prototype is intended to be used for demos the client will present to investors and as a starting point for the next design team.
IV. Reflection
COMPLETING THE PROJECT
Reflections as team lead
We successfully handed off all deliverables to the Ink Bloom founder by the deadline. When we met for the last time, there was a buzz of excitement around the positive user feedback and for what Ink Bloom holds in store. As the team lead, most communication between the client and team was my responsibility, including responding to messages, leading presentations, and sending all deliverables. I was aware that how I handled this role could make or break this project and I was very intentional about clearly communicating all important information to the founder. In messages and meetings, I always kept an open dialogue for questions and discussion so that the client could give input and to ensure we were all on the same page. By the end of our time together, the founder was happy with the outcome and excited to present it to investors.
FUTURE RECOMMENDATIONS
Documented steps to get to an MVP
Another piece that I feel helped our team’s communication was clearly documenting what would be left by the end of our time to get to an MVP. This was discussed both early on in the project and again at the end to communicate expectations and help the founder know what was still left to do.
-
Design the POV for a professional user
-
I would recommend researching professional user’s needs and build a persona
-
This will allow professionals to see payment information
-
-
Giving a critique
-
Many users may have several comments/highlights that overlap and will need to be in a card that expands to show all
-
User POV once they have been given a critique
-
-
Design any relevant parts of checkout and payment process.
-
Checkout will be integrated with a payment platform, so this may just include designs related to this
-
This will allow the site to bring in money
-
-
Filters
-
Filters were referenced, but we did not design what users can filter by
-
I think there is already a lot of information in past research about what users would like to be able to filter search results by
-
This will help users have an efficient search process
-
-
Notifications
-
Users will need to be notified when they get new critique requests, follows, comments, directed messages, etc.
-
This will help remind users of important updates and improve engagement
-
-
Onboarding process
-
This will help users create a secure account
-
Users could have the option to fill out profile information or save it for later
-
Flow to edit profile if user chooses to save adding info for later or wants to make changes
-
-
Pagination
-
This was something we realized late into designing could be needed in cases where users have a lot of status requests
-
-
Settings
-
Account settings related to
-
Privacy of account
-
Openness to giving critiques
-
-
-
Design screens for reading another user’s shared work
-
Design screens for leaving a review
-
Improve the responsiveness of the design for larger and smaller screens
-
-
Blank states
-
Error states
-
Extreme users
-
LEARNINGS
Areas I want to improve
One area that I learned a lot from my teammates was creating research questions focused on user impressions. Since I began learning about research as a psychology undergraduate, I have taken a more observational approach, still asking questions, but heavily focusing on actions and subtle queues. My teammates had a more direct approach, that when balanced with mine provided us with some great insights. This came in handy when we were talking with the client at the end because we had quotes to show him the excitement users had shown us. In the future, I want to hone in on how I write my interview questions to try new methods.
​
Another area I would like to improve in the future is planning out the most used components in more detail. In some cases, we could have simplified the library by finding more ways to reuse components and by creating more foundational components before moving on to larger pieces. In the future, I would set up some time to spell out what we want to build, rather than solely relying on the wireframes and communication throughout the process.
CONCLUSION
Final reflections
Overall, this project was one of my favorites to work on. It was really exciting to see user’s reactions when we solved one of their pain points. I also learned a lot about my leadership style and communication as team lead. I valued getting so much direct communication with the client and being able to build a positive working relationship. At the end, one of my teammates sent me a thank you message that said
“I really admire your skillset in terms of leadership, communication, & design”
This comment made me feel that I had a positive impact on the team, as well as the client and future users. I’m excited to see what Ink Bloom has in store. I hope my contributions will help writers to meet their aspirations within an engaging and supportive community.
WANT TO SEE MORE?
Subscriptly is an iOS mobile application that helps users manage their subscriptions through efficiently finding subscriptions, customizable dashboard displays, and suggestions based on the user's current subscriptions.
