%20Logo%20On%20Transparent%20Backgr.png)
Design Management and the Creative Process
DSO201 - ASSESSMENT BRIEF 2
Oliver Lavender
"Organising A Diffusion Bee"
Personal Note:
This has been an interesting exploration of the prototyping process. Full disclosure, this assignment has mainly been written after the design process was completed as more of a recap of my method. After already doing two subjects this year that adhered fairly rigidly to the DDDD process and structure, it was important for me to trust my intuition and follow my gut in regards to the order of operations. Creating flexibility in the way I approached each task allowed me to determine a schedule that worked for this style of project. Another major point of difference from previous double diamond projects was the heavy reliance on others and their related systems.
"In this assessment task, diplomacy has been just as important as design"
In researching problems for other DDDD subjects this year, I started out with a rough target to focus on. What has been different about this specific DSO201 project is that the target was acquired midway through the process (to update and include new features in Diffusion Bee's GUI) but morphed into a "different beast" over time.
As I became more involved with collecting data, I realised the systems currently in place were inadequate for the growth of the app and the meaningful contributions of the small, but tight-knit community that has sprung up around it.
The more I consulted with users on their experience with Diffusion Bee so far, the more I realised the community needed a way to manage feature requests and further streamline the open source development process. It also became evident that better documentation needed to be created in order to support new users of the app.
These two discoveries changed the direction of the assessment from that of a UI upgrade, to prototyping how the community can better engage with the developer and share their feedback more easily. The GUI redesign has now become the second phase of this project as more scope is given to exploring community contributions.
The other defining characteristic of this subject (or problem) is the fact that this "design" already exists. I am not creating something new but rather trying to improve upon what is already there. This is markedly different from previous DDDD experiences and has changed the way I have approached this assessment from the outset.
Background
Over the last 2 years I have been researching and experimenting with text-to-image generation (TTIG). During trimester 3 (2022) a huge advancement in the sector was released to the public in the form of Stable Diffusion (SD), an open-source transformer model from StabilityAI.
This new technology has spawned a generation of apps and devs (in a very short period of time) that are all creating front-end graphical user interface (GUI) access to SD. These solutions are mostly open source apps that have extremely small development teams (sometimes literally consisting of one person - i.e. DeeBee) and loyal beta testers who are able to iron out the kinks AFTER release. This is quite different from more traditional software prototyping methods, where the end user only receives an update after it has gone through alpha, beta, and final release testing.
This process is aided by new-age tools such as Github and Discord, which allow communities to interact, share bug reports and keep up to date with the latest information on new features and implementations.
In the rush for early adoption, most developers have almost entirely ignored the normal UI/UX process, opting to incorporate as many features as possible with little regard to traditional design principles and the end user experience (versus a company like Adobe for comparison's sake). This approach may be crude, but it is essentially more about creating "proof of concept" than "polished product" and is the reason why R&D has exploded in the last few months. I believe most developers see this type of build as a challenge and in their eagerness to find solutions and release before their competition, refinement and usability are traded for early access.
This has led to a raft of powerful but poorly designed software, which is often inaccessible to the general "computer-using" public due to complicated installation procedures and many dependencies such as Python and other coding environments required to make SD work.
As technology has matured, compression has improved and GPU's have become more powerful, rendering SD images locally (on your own computer) is fast becoming the most popular method of generation. Other benefits include complete privacy (and no restriction from NSFW censorship), offline capability and of course its free.
Up until now, this has been the domain of PCs with heavy-duty gaming GPUs, but the new generation of Apple M1/M2 silicon chips have opened up a world of possibilities for rendering SD locally, with speeds now matching their PC counterparts. After the success (and lack of controversy) of Stable Diffusion's release, Apple has recently signalled further support for their hardware and software, along with the integration of new neural engines and Pytorch converters that will continue to offer significant speed increases for Mac users as time goes on.
(At the time of writing, Apple has just announced major support for Stable Diffusion on its various devices coming with the release of OS 13.1 (Orhon et al., 2022)
So it was with much delight when I stumbled across Diffusion Bee, a one-click installer and stable Diffusion wrapper that allows users to create text-to-image generation locally on their own machines, bypassing the need for APIs like Dall.E 2 and Midjourney. DeeBee is also capable of running faster than most local instances of SD due to its exploitation of Apple's native shader language, Metal.
Now, as good as Deebee is at creating amazing images quickly, it is clear that it was designed by an engineer. The bare-bones approach to layout is, for the most part, purely function over form, leaving much to be desired for power users. Certain basic functions such as text boxes accompanying sliders (allowing precise input) are noticeably absent, alongside superfluous features that remain under-utilised. More detail will be provided later on, but needless to say that DeeBee in its current state is a UIX designer's "wet dream", dripping with potential.
For me, this seemed like an ideal "problem" to look into for DSO201, but as the user base has grown over the last few months (3.5k as of writing), so have their wants and needs.
Before embarking on the design journey, an essential part of the double diamond process is consultation with key stakeholder groups. During this phase, I began to notice that the current way of recording the community's requests and feedback was inadequate. The problems here are varied and range from users' feedback becoming lost in a sea of information to duplicate requests and a general lack of structure in the way users respond.
It is also clear from detailed research that the average user level varies wildly across the community, with some being more proficient engineers and others (like myself) coming at SD from an artistic, design-oriented background. With this in mind, it is important to ensure DeeBee remains accessible to as many people as possible, regardless of their individual skill level.
Consultation
Early on I recognised that DeeBee's Discord community was an invaluable source of direct, honest user feedback and could provide the basis for most of my primary research. During the time I have been researching (or perhaps sleuthing?), the community has grown to over 3.5k members, a testament to the need for support and advice for new and power users alike.
As mentioned in the background information, these users vary from first time SD users to experienced, veteran programers and developers. Having such a wide cross section of community members at my disposal has been extremely helpful during the consultation process. I am able to to see previously posted questions (including their related answers) and contact users for clarification or to prompt them for further information.
This process is obviously quite different from others in the class and as a result, I have have had a mountain of information to sift through. In terms of gathering research, it wasn't so much the questions that I asked that were important (in the beginning at least) but more so the insights that have been presented from user questions and feedback. For instance I have noticed the same FAQ's on an almost daily basis. Many new users ask the same questions about how to find the seed number for images generated in a batch or if DeeBee supports custom checkpoint models. After spending time gathering these FAQ's I was able to start piecing together some important take aways, for example: more detail on seed numbers needs to be included in the user manual as well as the community wanting to be able to run their own custom models.
Primary interviews were also conducted with friends and colleagues currently working in the IT sector (I have omitted some for clarity and focus). Special mention goes to Alex Duncan who was extremely generous with his time and taught me the importance of UML diagrams and how to start the design process off on the right foot. We also looked at some cutting edge AI technology and had a chat about Alex's many interests, from becoming a Luther to entering the field of AI and developing an online artist management and booking service. The edited interview can be viewed here:
Parts 1 and 2
Part 3
Clustering and Patterns
During the research phase I was able to identify some common themes amongst users that would appear regularly. Aggregating these posts was no small task with tens of thousands of comments having been made since the server was created in September of this year.
My process involved reading each and every post and filtering them into lists. One of the most important indicators/metrics was the amount of times a particular request was made and how many likes it received. Posts with a healthy amount of discussion were also ranked more highly on the scale.
Within the DeeBee Discord community is a thread called #featurerequests, which was the repository for most users feedback and requests. As stated earlier, one major problem with this approach is feedback becoming lost in an ocean of content. There are also other discussion channels which contain feedback too, further adding to the chaos.
Initial findings (+ number of people with the same request):
Load Custom Models: 15
Choice of Upscaling: 4
Train Your Own Models: 6
Personalised Styles / Favourites: 4
Variations (remix option): 6
Save Destination: 3
Text based weighting: 3
Face Restoration: 4
Push ENTER to generate: 2
Load settings from History: 2
Prompt Cue: 4
Resize Canvas: 2
Custom Model Activation Token: 2
5 Whys Process
Problem: Feature requests are fractured between multiple threads, have little consistency in formatting or structure and are easily buried or lost amongst the noise.
WHY 1: The structure of Discord is chaotic/anarchic, expansive in detail and suffers from a lack of moderation.
WHY 2: The dev hasn’t yet assigned any moderators and fails to maintain the server (spam, requests duplicates etc) or respond to questions in a timely fashion. The server also needs to transition to a community server to take advantage of forum threads.
WHY 3: The dev is very busy developing and testing 2 different apps across multiple platforms and also is new to Discord - therefore does not understand the importance of hierarchy, responsibility and organisation in a public server.
WHY 4: The dev's main priority is in making sure that new releases run stably across multiple systems, not the administration of a Discord server. Most feature requests that have been implemented up till this point have come from the Github repository.
WHY 5: The community has experienced rapid growth, and as a result, there are no clear structures or rules for users to follow, nor are there moderators to enforce them. Moreover, there is no dedicated feature request forum that is easily accessible to all users and remains visible for a sufficient amount of time for the community to vote and discuss proposed changes and improvements.
Problem Statement
The problem is that feature requests posted in our Discord server are not being properly tracked and managed, resulting in many requests being lost or forgotten. This lack of organisation and oversight has led to frustration and disappointment among users who have made feature requests, as their suggestions and ideas are not being properly considered or implemented.
This problem is particularly significant because the discord server is an important platform for community engagement and feedback, and it is critical that users feel heard and valued. The current situation, in which feature requests are getting lost and ignored, undermines the community's trust and undermines the server's ability to gather valuable feedback and improve its services.
To address this problem, it is necessary to implement a system for tracking and managing feature requests, including a dedicated forum where users can post and discuss their ideas, and a mechanism for collecting and considering user feedback. This will ensure that feature requests are not lost or forgotten, and that the discord server is able to effectively engage with its users and respond to their needs and suggestions.
(Note: another benefit of posts being more organised is people are less likely to "double up" their requests which in turn means that a proper representation of the community’s desires is obtained. When requests are duplicated, that potential energy is fractured into lots of small conversations that don't accurately convey the needs and wants of the community).
Point of View Statement
As a user of a discord server, I am frustrated and disappointed by the lack of systems for tracking and managing feature requests. I have made several feature requests, but have not received feedback or updates on their status, and I have no way of knowing whether my (or others) suggestions are being considered or ignored. This lack of transparency and accountability can be frustrating for power users and could lead to a loss of trust and confidence in the developer, the server server and its administrators.
I strongly believe that it is essential for the discord server to implement a system for tracking and managing feature requests, in order to ensure that all user suggestions and ideas are properly considered and addressed (in one location). This will not only improve the server's services and features, but it will also foster a stronger and more engaged community, which will demonstrate the devs commitment to listening and responding to user feedback.
How Might We?
The original HMW question I posed in this process was something like:
How might we create a new GUI for Diffusion Bee that is more ergonomic and user friendly?
As the project has progressed, this has morphed into something more like:
How might we create a system that keeps track of community requests and keeps beta testers engaged?
Or perhaps..
How might we improve the tracking and management of feature requests posted in our discord server to prevent them from being lost or forgotten?
Ideation
The ideation process has been a shifting, dynamic force. I started the project thinking about how the user interface of Diffusion Bee could be improved upon and expanded to accommodate new features that have been included in subsequent SD releases, i.e., outpainting, custom models etc. With this in mind, I began thinking about not only what the community would want but what I desire as a user as well. By having a stake in the final use case, I felt I was able to make more informed decisions on the overall direction the design should take.
In class, I was lucky enough to do a "Worst Ideas / Best Ideas" exercise with a large group of people. Although I didn't end up using any of these ideas, this was helpful in getting me to think outside the box and consider unconventional or counterintuitive solutions to a problem. It also promotes collaboration and teamwork, as the participants have to work together to generate and evaluate ideas.
Bad Ideas
Good Ideas
The most successful ideation method for me personally was to speak to other users of DeeBee and find out how they are currently using the software. By discussing current limitations and areas of "pain" and "gain" for users, I was able to start imagining potential solutions. This is evidenced in the following sections, where I start to plot user feedback onto a grid. (n.b. this can also be seen in more detail in the video at the end and via the various Milanote boards I have linked to).
Prototypes
The first step (after speaking with Alex Duncan) was to generate a UML (Unified Modelling Language) diagram in Figjam. This ensured that all current features and their respective relationships were mapped out visually. This also allowed the introduction of new features that have not yet been implemented (yellow cards). Another bonus is the ability to share this board easily within the Discord server, seek feedback and have other members contribute to the design.
Figjam board:
After completing step one, my aim was to seek feedback on the feature requests I had gathered from users in the Discord server to further inform my design process. It was at this point that my problem statement really began to shift. During this process, I observed that there was no clear way to have users vote on the features that excited them most, so I put together a board in Milanote and shared this within the Discord server, asking a select group of fellow power users to provide feedback (before taking it to the wider community for a vote).
The following screenshots detail my process of prototyping the feedback board.
First I gathered all the feedback requests I could find including the original author and related links.
I then began to group the requests by colour and sorted them into families of UI and UX (ensuring I eliminated any duplicates).
Finally I filtered down the most important requests and "simplified" the language as the raw user requests are often convoluted and lengthy.
These simplified requests were then placed on a board for users to vote on. I tried to group them in a logical fashion that flowed from left to right, ensuring users would scan the entire page.
Full board link:
https://app.milanote.com/1OUWdQ1okUNFhC?p=NksqqIkhPzT
Immediately I was made aware of the fact that Milanote makes you create an account in order to comment on a board (sneaky!) which created a large barrier to entry for most users (as expressed in the feedback).
This was painful, as by the time folks were done whinging about it, they could have created an account and filled it out already. Still! This is why we prototype—to understand the users' needs more holistically.
To borrow a phrase, "you should never sell with your own wallet," which in this case means "just because that's how I feel doesn't mean others do too."
Feedback on first prototype
After making this discovery, I started investigating alternative solutions to this "mid-stage snag". During the exploration and layout of other whiteboard products such as Miro and Figma I came to the conclusion that none of them offered the features I needed (the ability to share publicly and vote anonymously). It took a while to come to this conclusion, which slowed down the prototyping process significantly. This finally led to me experimenting with the concept of a Google Form. From the start, I thought this was a poor substitute for a board, where all requests could be laid out in groups, making the decision-making process more straightforward for the user. Although this platform allows for anonymous submissions, the format and layout were inappropriate for the task at hand.
Abandoned Google Form
In an act of desperation, I started to look at ways I could use the discord to achieve my goals. It was at this point that I stumbled on a newly created feature for Discord servers: The Forum Channel! Oh hallelujah! Finally, I had found a way to keep all user feedback in one place that is easily accessible to the community and encourages long-form discussion.
The Catch
Because nothing is ever easy, there was of course, a few hurdles to jump over before I could even begin the process. First of all, for a Discord server to host a forum channel, it must be a "community" (with more than 200 members), which in turn changes the access from private to public. At this stage, I didn't possess any of the mod privileges that would have allowed me to make these changes personally, so I reached out to DeeBee's developer and server owner, Divam Gupta to ask if he would be onboard with implementing my ideas (with a view to being more organised in general).
During this conversation, we also explored the potential of my becoming a moderator (mod) to guarantee that the new process happened as smoothly as possible. Luckily, he agreed to the changes, and I was able to finally start inputting the data I had gathered long ago, into the Diffusion Bee server.
Testing
This is a difficult section to quantify (in my case), due in part to the nature of the final prototype. I haven't designed the system myself, but I have engineered a solution to the problem using the double diamond process. Most of the testing was undertaken during the prototyping phase by way of seeking direct feedback from the Diffusion Bee community.
The process I have described up to this point has led me to implementing the final design offering in the form of a Discord forum. After discussions with my lecturer, I realised that this process (for me personally) was more about the journey than the destination. I was made aware that design and prototyping is an ongoing process. The end goal has always been to develop a new UI for DeeBee, but the detours I needed to take along the way have been a necessity. Perhaps a good analogy is "Two steps forward, one step back".
At the time of writing, I have only just been granted moderator privileges, so there are ideas that are yet to be implemented, such as a mandatory welcome message for first-time forum users that explains how to structure a feature request correctly. This is in response to the inexperience of new users within the open source development process who create messy, garbled requests because - they don't know any better!
So far, the forum has been working well for the week it has been up. The community has taken to posting, liking and commenting on threads (like a duck to water). This has opened up discussions which were much harder to facilitate under the previous model.
The most positive change is possibly the simplest. Organisation. We are now easily able to find posts and better yet, direct users to the forum to add their own ideas. It has become a reference point for moderators to point new users in the right direction (easily reference information via links) and most importantly allows the dev to get a clear overview of what the community needs and wants, speeding up implementation of new features and enhancements.
Testing needs to continue, but slight tweaks can be implemented as we go, to respond to how the community is using the forum.
Evaluation
This is also hard to quantify due to the limited timeframe this project has been operational, but since the time of inception, I feel as though I have been able to create a positive work environment for users to operate within.
In terms of organisation, the impact the forum has made on the server is significant. Information is easily retrieved and disseminated amongst the community. Users ideas can be voted for and clear development roadmaps can be planned out.
I strongly believe that this system will be of great value to the development process moving forward and allows the community to contribute directly to the app. It has been amazing to be welcomed into the open source community with such open arms and I look forward to being able to continue to improve upon the work we have already done.
Design Offering
I felt the best way to present my final design offering was with video. There is far to much information to summarise in pictures alone. This video gives a guided tour of the new forum feature within Discord and demonstrates how users have begun to use this new component within the context of open source design. https://www.youtube.com/watch?v=ImscY_wC7-c
Value Proposition Statement
Diffusion Bee users can now meaningfully contribute to the development of their favourite app whilst simultaneously gaining feedback, support and advice from the community. This is the true power of the open source model.
Reflection
This has been an interesting process, involving quite a bit of liaison with 3rd parties. Many hands make light work, but there is something to be said for making something entirely under your own steam. Although the task may seem larger, your not having to wait on others for input or permissions for example.
My design offering is not what I set out to create. At first I was disappointed by this, but after speaking with my lecturer, I realised that this is what design is all about. As Andy famously says "If you already know what your documentary is about, you're doing it wrong". This holds just as true for designing in the double diamond structure. I guess it also comes down to managing expectations. I thought I could learn enough about UIX design in 8 weeks to finish with five designs for a new interface, where in reality it took just that amount of time to BEGIN the process!
Im looking forward to continuing this process and creating a GUI for DeeBee in the near future and this assessment has given me the confidence to start the next phase.
Research boards:
https://app.milanote.com/1OLy1c1fgRPzad?p=NksqqIkhPzT
References
Gupta, D. (2022, September). DiffusionBee - Stable Diffusion App for AI Art. [website]. https://diffusionbee.com/
Milanote,. (n.d.). Milanote - The tool for organizing creative projects. [website].
Discord. (2022, September 14). Join the DiffusionBee Discord Server!. [Server].
https://discord.com/invite/NbjRXDSZ Duncan, A. (2014, June 24). Uncle Dunc (@uncle.dunc) - Instagram photos and videos. [Instagram].
https://www.instagram.com/uncle.dunc/
Orhon, A., Siracusa, M. & Wadhwa, A. (2022, December). Stable Diffusion with Core ML on Apple Silicon. Apple Machine Learning Research. [paper]
https://machinelearning.apple.com/research/stable-diffusion-coreml-apple-silicon