# Portfolio https://viktorem.work - **Contact:** viktoremn1@gmail.com --- # Greater Scene (Full product) - **Project page:** https://viktorem.work/projects/greater-scene - **Current status:** Planning beta testing - **URL:** https://greaterscene.com - **Password:** gXedVkp9vDKk - **Project type:** Solo project - **Timeline:** July to present (in active development) - **Role:** Founder, product designer & AI-native builder ## TLDR Image generation models can already edit property photos of course, but flexibility alone does not create a practical workflow for the user. Can someone upload an image and explain what they want changed? Indeed they can, but this requires them to know what they want and how to properly prompt it. Greater Scene keeps source images, effects and generated results together in one workspace. The user can work with several images, generate more than one result at a time and continue iterating whilst other generations are running. Guided effects also replace much of the repeated prompting with a few relevant choices. The product has been tested technically through automated tests, different browsers, persona based flows and edge cases. But it has not been fully validated by actual users. The next step is to test whether property professionals understand the flow, trust the results and find enough value in the product to pay for it. ## Product roadmap * Implement technical SEO. * Build internal tools that automate parts of the marketing workflow. * Test the product with actual users before expanding the feature set. ## Role I have led Greater Scene from the initial idea through product strategy, research, UX, UI, the design system, technical direction, testing and launch preparation. I use AI coding agents to turn detailed requirements into production code. Does this mean every generated implementation is automatically good? Of course not. Something can technically work whilst still being inconsistent, poorly designed or completely different from what I intended. A large part of my role is testing the result, spotting where it has drifted, rejecting weak solutions and turning accepted decisions into rules that can be reused. My strength is not pretending to be traditionally specialised in every technology behind the product. It is being able to direct AI assisted product development whilst keeping the experience, visual system and technical implementation connected. ## The opportunity I have used AI image generation since the earlier models became available, so I already knew the experience from the user side. When I use a product, I tend to notice where the flow asks more from the user than it should. An empty prompt offers a lot of creative freedom, but it also expects the user to know exactly what they want and how to explain it to the model. What happens if they know something looks wrong but cannot describe the change? They can continue prompting, use something such as Magic Prompt or start again, but the work is still left to them. Handling several images can make this even messier. The user may have to describe them as the first image, second image and so on, or process them individually. If they notice something wrong with the second result whilst already working on the sixth, they have to bring the earlier image back into context and explain the change again. They could keep several chats open at the same time, but now they are managing more than they are supposed to. I reviewed AI staging products, general image editors and human property imaging services during the early research. This was directional desk research, not proof of the entire market. The products I reviewed often relied on the same prompt flow, handled property images as isolated jobs or charged prices that felt difficult to justify based on the state of the experience. So there appeared to be a gap worth exploring. ## How the product works Greater Scene uses external image generation providers. The product is built around what happens before, during and after the generation: > Property, images, guided effects, output choices and independent generated versions. The user should not need to understand which provider is being used or how to phrase every instruction for it. They should understand what they want to do to the property image, what it will cost and where the result will appear. ### 1. Design around the property #### The problem A property rarely contains one image. There may be several rooms, exterior photos and results that need further changes. Uploading several images is not a problem by itself because many services already allow it. The problem begins when the user has to repeatedly explain which image they mean, wait for each one or bring an earlier result back into context to make another change. #### The decision I made an infinite canvas the main workspace. One file can contain several source images and independent generated results. The user can select more than one image, resize them without changing their proportions, compare the source with the result and use a generated image as the starting point for another supported effect. The wider structure follows the same thinking. All files is the default overview, whilst projects are optional. A new user can create their first file without deciding how everything should be organised. Someone with more work can introduce projects later. Favorites make important files easier to find, and Trash separates recoverable files from active work. #### The tradeoff The canvas is more complicated to build and explain than a single upload screen. It introduces questions around performance, responsive behavior, selecting images and onboarding. Is it still worth it? I believe so, because it allows the user to keep the property and its results together instead of moving between separate jobs. But this is still an assumption. Actual users need to show whether the canvas helps them or simply gives them more interface to understand. ### 2. Replace the chatbot with guided effects #### The problem I initially explored using a chatbot because people already understand how prompting works. But a chatbot also allows the user to ask for almost anything, including something that conflicts with the effect or produces a result different from what the interface appeared to promise. Creative freedom is a nice feature. However, it also means that the user has to make more decisions and understand how to communicate with the model. #### The decision I removed the chatbot and replaced it with guided effects such as virtual staging, renovation, decluttering, day to dusk changes, lawn enhancement and pool enhancement. The user chooses what they want to accomplish and only sees the options related to that effect. Completed choices remain visible and can still be changed. Instead of writing a lot, they click a few times. #### The tradeoff The tradeoff is of course that guided effects remove some creative freedom. Each new effect also needs to be deliberately designed, tested and maintained. But if someone is already using Greater Scene, another empty prompt may not be what they want anyways. The product is for someone who wants to reach a supported result without having to understand everything the model expects from them. ### 3. Make spending credits clear #### The problem Applying an effect and generating an image are two different actions. Generation spends credits and sends work to an external provider, so the user should understand when they are still preparing the image and when they are actually committing to the result. The provider also does not expose progress information that would support a truthful percentage or estimated completion time. Showing 72 percent may look helpful until it stays there for three minutes. Then the user may think something is wrong or that the product is simply slow, even though the percentage was never connected to real progress. #### The decision Having an Apply step introduces another action before the user can generate. Is it necessary? I believe so, because it allows them to review the effect, output settings and credit cost before anything is spent. Source images and earlier results are never silently replaced. During generation, the product uses an indeterminate shimmer and messages related to the work without pretending to know the exact progress. Errors also explain whether the issue comes from missing choices, insufficient credits, a rate limit, the provider or reporting the result. #### The tradeoff The extra Apply step adds another click. An honest loading state may also feel slower than a percentage moving across the screen. But both decisions make the state of the product clearer, and I believe that matters more when the user has already spent their credits. ## Supporting the main flow ### Onboarding The onboarding uses the actual interface rather than showing a separate presentation. It introduces files, creating a file, importing images, applying effects and choosing the output. The user can move backwards or skip it. ### Support and feedback Documentation is used for self service help. Contact support creates a case that can be followed, whilst Send feedback is kept separate for suggestions during the beta. A product issue and a feature idea are not the same thing, so they should not enter the product through the same flow. Generated images also have copyable job identifiers. If something fails, the user can include the identifier when contacting support instead of trying to explain which generation they mean. ### Destructive actions Deleted files move to Trash before they are removed permanently. The retention period is explained and permanent deletion remains an explicit action. Deleting something should feel different from closing a menu, especially when the file may contain source images and generated work. ### Marketing and product The marketing site can be more expressive and image focused because its job is to show what the product can create. The application itself is more restrained so the property images remain the focus. Using the same visual intensity in both places would make the workspace compete with the work inside it. ## Building a system that can change Rapid implementation repeatedly exposed the same issue. An interface could work whilst the spacing, type, icons, borders, colors and motion slowly became inconsistent. So I created an implementation contract for the authenticated product. It documents tokens, components, interaction states, responsive behavior, motion, accessibility expectations and which part of the system is responsible for each style. AI assisted with code inspection, prototyping, implementation, testing and documentation. My role was to define what the product should do, test what was built, reject what did not work and turn the accepted decisions into reusable components and rules. ## What has been validated Greater Scene has been tested technically through automated application tests, database access checks, two session isolation testing, Chromium, Firefox and WebKit coverage, production builds and checks for dependencies, secrets, containers, the software bill of materials and CodeQL. This shows that the tested version behaves as intended under the tested conditions. But does it prove that people want the product? No. The work has not yet proven: * That the product fits the market. * That generation quality remains consistent across complete properties. * That production reliability and costs make commercial sense. * That customers are satisfied or willing to pay. * That the final legal, tax, privacy, billing and accessibility requirements are complete. The controlled beta needs to measure whether people finish onboarding, reach their first successful generation, work with several images, retry failed results, contact support, understand the credit model, return to the product and eventually pay for it. ## Reflection The most important change was realising that Greater Scene should not compete by allowing the user to ask the model for absolutely anything. General image models already offer that freedom. The opportunity is to decide which parts the user should not have to manage. This is why the product uses a canvas, guided effects, visible credit costs, independent results and clearer generation states. But structure only helps if it matches how people actually work. Otherwise it is simply another system they have to learn. So the next step is not adding more effects because the list looks impressive. It is putting the current product in front of property professionals and seeing whether the choices make their work easier. Research and technical tests can suggest one thing, but you never know for certain until the product meets reality. --- # Modern Poverty (Landing + App) - **Project page:** https://viktorem.work/projects/modern-poverty - **Current status:** Figma app MVP preparing for user testing - **URL:** https://modernpoverty.com/ - **Project type:** Solo - **Timeline:** 1 day for the landing page; app MVP built in Figma and preparing for user testing ## TLDR Modern Poverty started with a domain I found at an auction for $2. The name itself was interesting, so of course I bought it since I already envisioned what the site could become. The first idea was an interactive view of poverty, which I developed and deployed. I later changed direction after remembering a subscription tracker I had designed a few months earlier that, in a strange way, also fit the name. A subscription tracker is obviously not a new idea, and the area is extremely saturated. This was also why I left the design alone for a couple of months. But subscriptions are becoming a part of almost everything, and I have indeed forgotten about one until the renewal appeared. So I returned to the project, created a new landing page in one day and continued working on the app MVP in Figma. The prototype is now being finished before I test it with users. A saturated idea can still solve a real problem, but you never actually know until people use it. ## Where it started The domain was originally meant for an interactive experience where people could learn about poverty through a three dimensional map. I developed and deployed that idea, but the project eventually stopped moving forward. Could the name only be used for poverty in the traditional sense? Of course not. Modern poverty can also describe the smaller systems that slowly take money from people without feeling significant on their own. A streaming service here, a software subscription there and perhaps something you signed up for once and completely forgot about. The subscription tracker I had already designed began to make sense under the same name, so the project changed direction. ## Why subscriptions Everything is slowly becoming a subscription because it is a profitable model. People tend to set and forget, which works well for a company collecting recurring payments. Then one day another renewal appears. You can clearly see the amount and the company on the transaction, so identifying who charged you is not really the issue. The issue is forgetting that the subscription was still active in the first place. Classic. Banks already have access to the transaction data required to identify recurring payments, but my bank still does not turn this into a useful subscription overview. Perhaps there is simply not enough value in building one for them, or helping customers find and cancel recurring payments could work against their own interests. This is an assumption, of course, and not something the project has proven. ## Returning to the idea I built the first app MVP before the current wave of AI assisted development. The subscription market was already saturated, so leaving it as a design was an easy decision at the time. Why build another tracker when so many already exist? AI has now made finishing and testing the product more practical and feasible for a solo person. Research can say one thing, but you never actually know for certain whether an idea works for people. Being able to reach a testable prototype without spending as much time changes that calculation. It does not make the idea less saturated, but it makes exploring it less costly. ## Current state I created the new landing page in one day and built the app MVP in Figma. I am currently finishing the prototype before putting it in front of users. The first tests need to answer fairly simple questions: * Do people understand the purpose of the product? * Can they add and review their subscriptions without the flow becoming another task to manage? * Does the overview reveal anything their banking app does not already make clear? * Is the product useful enough to return to after the first setup? ## Reflection Modern Poverty has already been two different products under the same name. The first was developed and deployed, whilst the second began as an app design that sat untouched for months. Perhaps the project will change again after testing. That is fine. The point of returning to it is not to prove that a subscription tracker is an original idea. It clearly is not. The point is to see whether this version gives people a more useful view of something that is already happening around them. If it does, I can continue. If it does not, then at least the answer came from reality rather than another assumption. --- # Portrait (Early stage) - **Project page:** https://viktorem.work/projects/portrait - **Current status:** In active development - **URL:** [looking at available domains] - **Project type:** Solo project - **Timeline:** 2 days to present (in active development) - **Role:** Founder, product designer & AI-native builder ## TLDR Portrait is a working case study rather than a polished launch story since I am still working on it. It records how the product changed whilst I designed and built it, including the ideas I reversed, the features I removed and the questions that still do not have a final answer. The flow itself is kept simple, because why complicate it more than necessary? Upload photos, choose clothing and backgrounds, review the setup and then generate the portraits. The user can also apply company templates to skip parts of the setup and generate more quickly. The complexity appears when an account owner needs to create portraits for an entire team. Now there are several people, shared company choices, individual exceptions, credits and sensitive reference photos that may belong to the employees rather than the person controlling the account. The current product is my attempt to make those parts understandable before it is tested with customers, engineering constraints, image output, legal review and production security requirements. ## Role I am leading Portrait across product strategy, UX, interaction design, the design system, prototyping, technical direction, testing and frontend implementation. The product is still in early development, so my current focus is not presenting it as a finished launch. I am defining how it should work, implementing the ideas and then challenging them when the result reveals another problem. Sometimes this means improving a flow. Other times it means removing it completely. ## Where the product is now Portrait allows an account owner to create consistent AI portraits for one person or an entire team. The flow has five connected steps: 1. References 2. Outfits 3. Backgrounds 4. Review 5. Results The account owner controls the shoot and pays for the generation. Participants provide their own reference photos, but they do not choose the final settings or spend credits. The same structure appears throughout the product. People are shown in rows, their current state remains visible and group choices can still be changed for an individual. Before any credits are spent, the account owner sees what will be generated and how much it will cost. This is the current idea. It is not an answer that can never change. ## Where I started Most AI portrait products are designed for one person uploading photos of themselves. This works until a company wants portraits for ten people. Now someone needs to add the participants, collect their photos, apply a company style, make exceptions and understand who is ready. The employees may want to provide their own reference photos, whilst the account owner still needs to control the credits and final output. The earlier versions showed too much at once. Explanatory text, controls, thumbnails, states and actions were all competing for attention. Could a user still complete the flow? Indeed, but it felt more like moving through a collection of forms than using one product. So I began removing the parts that did not need to be there. Longer status descriptions became thumbnails, badges and a completion indicator. Repeated actions were brought together, and the review became closer to a receipt where the account owner could understand what they were about to buy. ## Current product idea The account owner adds people, applies templates, chooses outfits and backgrounds, spends credits, generates the results and downloads them. Participants only provide the reference photos required for their portrait. They do not enter the configuration or generation flow. The main object in the product is a person. Their references, outfit choices, backgrounds, review information and results remain connected to them. Group controls provide a default, whilst individual controls allow exceptions. ## How the design changed The product changed several times as the flow became clearer: * Participant generation was removed when it became unclear who should control the account owner's credits. * The default person became a real empty state so removing everyone behaved honestly. * Separate upload actions became one stable Photos menu. * Longer status descriptions became thumbnails, compact badges and a completion indicator. * A separate Apply to everyone toggle was removed because the Everyone card already communicated the same action. * Exact garments and gender categories became broader outfit directions. * Backgrounds were allowed across categories when each choice became another generation setup. * Configurable quantities became one result for each outfit and background pairing so the cost remained understandable. * Results returned to the five step flow instead of becoming a second dashboard. * Fragile shared styles became dedicated composition classes with a clear purpose. The recurring pattern was not removing things simply to make the interface look clean. It was removing them when the extra control created more questions than value for the main flow. ## Product decisions ### 1. The account owner controls generation I initially designed a way for participants to generate the images themselves. This could create a smoother experience because they would choose exactly what they wanted and the admin would not need to generate for everyone. But the issue is that they would be using the admin's credits. What happens if someone generates twenty portraits without understanding who is paying? Limits, permissions and approval states could solve parts of it, but now the product needs more settings to support something that is not necessary for the main flow. So I removed it. Participants provide their photos, whilst the account owner controls the settings and decides when credits are spent. The tradeoff is that participants have less control over the final image, but the responsibility is at least clear. ### 2. References is organised around people References uses one row for each person. The row combines their identity, photo state, optional company template, upload action and removal action. The workspace can contain zero people. This sounds obvious, but the earlier version always kept a default person in the interface. Removing that person did not truly remove them, which made the state dishonest. Now the account owner can remove everyone and cannot continue until a person has actually been added. ### 3. Show progress instead of explaining it repeatedly Long status sentences made each person row heavier than necessary. So states such as Awaiting upload and In progress are supported by image previews, compact badges and a completion indicator. Color is not the only signal. A user should not need to interpret green or orange correctly in order to understand whether someone is ready. ### 4. Keep photo actions in one place The available photo actions change depending on whether images already exist, but the location of those actions should not move around. One Photos menu contains importing images, taking photos with a phone, managing photos and hiding them when those actions are relevant. The menu keeps a reserved place in the row and closes when the final image is removed. The state changes, but the user does not have to search for a new control every time. ### 5. Participant upload is still unresolved The participant upload needs to be practical. Sending a link is useful, and a QR code could make it quicker to open the same flow on a phone. But the simple part ends once identity, consent and deletion are considered. I initially planned to require the employee's email when the admin added them. This could be used for verification and might give the employee a way to contact the service later if they wanted their photos deleted. For example, if they left the company or simply became concerned about their privacy. However, this would also require the admin to enter someone else's email into a third party service, which could create another privacy problem. So I have removed the earlier flow from the current case study as a decided solution. I am still researching how verification, consent and deletion requests could work without making the upload unnecessarily long or disruptive. The production flow will need proper security, but listing possible controls is not the same as having a validated solution. This part requires technical and legal review before it can be presented as complete. ### 6. Mobile and desktop share the same flow The upload experience uses the same states and information on mobile and desktop, but that does not mean every element needs to appear in exactly the same place. The hierarchy and behavior remain consistent whilst the layout changes to fit the screen. Forcing desktop geometry onto a phone would make the experience less consistent in practice, even if the screenshots looked more similar. ### 7. Company templates remain optional Company templates are meant to make setup quicker, not silently decide the final portrait. They remain visible, optional, attributed to the company, editable and reversible. Completed shoots keep a snapshot of the template that was used. Otherwise changing the company template later could also appear to change the history of a portrait that had already been generated. ### 8. Use broad outfit directions Portrait does not promise exact garments. The choices are broader directions such as Executive and formal, Business casual, Creative and modern, and Casual and approachable. Exact clothing would suggest a level of control that the generation may not consistently provide. Gender categories could also introduce assumptions that are unnecessary for the flow. A broad direction gives the model guidance without pretending that the user is selecting a specific item from a shop. ### 9. Group choices still allow exceptions An account owner might be creating portraits for ten people who all need to follow the same company style. Should they have to choose the same outfits and backgrounds ten times? Of course not. The Everyone option applies a selection to the group. However, this does not mean every person must remain identical. Individual choices can still be changed, whilst new people inherit the choices that are already applied to everyone. Flexibility is a nice feature. ### 10. Backgrounds can cross categories Backgrounds are separated into Solid colors, Real backgrounds and Uploaded. The user can move between the categories without losing choices that are currently hidden. Selections can also cross categories because each selected background becomes another generation setup. The Review step then shows what those choices mean for the final number of portraits and credits. ### 11. Keep summaries visible and reversible Outfits and backgrounds use the same summary pattern. Up to three previews are shown, whilst the rest are represented by a remaining count. A detailed view shows every selection and removal stays an explicit action. The user should be able to understand that several choices exist without the row growing every time another one is added. ### 12. Review works like a receipt Review shows one collapsed card for each person with their references, outfits, backgrounds and portrait total. One portrait is generated for every unique pairing of an outfit and background. This makes the cost deterministic. If someone has two outfits and three backgrounds, the account owner can see that the result is six portraits before any credits are spent. Two pieces of information creating an answer that is easy to understand. ### 13. Results remains part of the flow Results is the fifth step rather than a separate management dashboard. Moving it elsewhere would make the user leave the process at the exact point where the process is completed. Skeleton states keep the future image space visible whilst generations are running. Download actions remain in the same place and change according to the result, so partially completed generations do not move the controls around. ### 14. Build the visual rules into the product Repeated implementation can make a working interface slowly drift. Spacing changes, icons become inconsistent and one screen solves the same state differently from another. So the product uses semantic tokens and dedicated composition classes for the parts where the geometry is easy to break. The interface remains flat, using borders and changes in surface rather than shadows. Motion is short and functional, with reduced motion considered from the beginning. ## Supporting decisions * Content uses sentence case and consistent product terms. * Black represents active neutral actions. * Orange represents waiting and something the user can act on. * Green represents completion. * Red is kept for destructive actions and actual errors. * Color never communicates a state by itself. * Controls need visible focus, accessible names, keyboard support, nearby errors and usable touch targets. * Destructive actions explain the consequence before they happen. These rules may sound small individually, but repeated inconsistency is how a simple flow slowly becomes harder to understand. ## Privacy, retention and responsibility Reference photos are sensitive. Using an external image model does not remove the product's responsibility for what is collected, why it is collected, how long it is kept and how someone can ask for it to be deleted. The current direction is to keep raw references for as little time as the service genuinely needs, delete abandoned uploads sooner, retain only necessary audit information and define when results and backups expire. Deletion would also need to reach the external processors involved. But the identity problem is not solved simply by showing someone an upload reference. A deletion request still needs defensible verification, and the participant email idea introduces its own privacy question before it solves another one. So this section describes the concerns and current direction, not a finished legal answer. Consent, lawful basis, processor agreements, retention, regional requirements and the final upload flow need specialist review before launch. ## What I deliberately did not build * Participant controlled generation or credit spending * Gender based outfit filtering * Exact garment selection * Industry uniform presets * A random mode that generates thirty looks * Mandatory choices beyond what generation requires * Hidden application of company templates * A second dashboard only for Results * A production verification flow that exists only in the browser * Permanent storage of raw references by default Some of these features could be built. The question is whether they should be. Every additional option introduces another state, another explanation or another way for responsibility to become unclear. ## Detailed decision register The published case study will contain the complete decision register for the workflow, references, identity, participant uploads, templates, group choices, backgrounds, review, results, styling and motion. The register is useful because the current interface will continue to change. Screenshots show what the product looked like at one point. The decisions explain why it looked that way and which assumptions still need to be tested. ## Reflection Portrait began as a fairly simple generation flow and became a question about responsibility. Who provides the photos? Who chooses the final style? Who spends the credits? Who can ask for the source images to be deleted later? The interface can make these questions look clean, but that does not mean the answers are complete. The participant verification flow is a good example. I had a solution, followed the logic further and realised that it could introduce another privacy problem. So I removed it for now. This is why the case study remains a working record. A functioning interface is not the same as a validated product, and a detailed flow is not automatically a good one. The next step is to keep testing the parts that work and remain honest about the parts that do not. Indeed, that is the actual work. --- # Jobbkompassen platform optimization - **Project page:** https://viktorem.work/projects/platform-optimization - **Current status:** Completed university project - **Project type:** Group project (3) - **Timeline:** 1 month - **Outcome:** Analytics dashboard and prioritized recommendations based on mock platform data. ## TLDR We evaluated Jobbkompassen to understand how jobseekers and employers moved through its search and contact flows. The project used mock platform data together with user feedback, so the goal was not to pretend that we had discovered proven behavior from the live service. Instead, we translated the platform's goals into questions that could be measured and created a dashboard where the answers could be compared. The analysis focused on search keywords, failed sessions, visit duration and the points where people continued or left. This gave us a shared view of the service and a direction for improvements such as better filters, more relevant job matches, CV tools and a redesigned search experience. Because the data was simulated, these are directions to explore rather than proven solutions. The next step would be to compare them with real behavior and see whether the same problems actually appear. ## What we wanted to understand A conversion rate can tell you that something is happening, but it does not explain why. If few jobseekers move from a search to an application, the issue could be the search results, the words people use, an error in the flow or something else entirely. So we began with questions: * Where do people leave the search flow? * Which search terms result in applications? * Where do errors interrupt the experience? * How long do people spend on the platform before applying or leaving? * Are employers reaching the point where they contact a jobseeker? These are simple questions, but answering them requires events, pages, inputs, sessions, timestamps and error codes to be connected. Looking at each number separately would not explain much. ## Measurement We defined two primary measurements. The conversion from job search to application was 0.7 percent, whilst the employer contact rate was 2.5 percent. We then used three areas of analysis to add context: * **Search keywords:** We compared the words people searched for with application and conversion behavior. * **Errors:** We isolated failed search sessions to see where the flow stopped working as intended. * **Visit duration:** We examined how long people spent moving through the service before continuing or leaving. Does a longer visit mean that someone is more engaged? Perhaps, but it could also mean that they are struggling to find what they need. The number only becomes useful when it is compared with the actions that happened during the same session. ## Dashboard We built a dashboard with separate views for Overview, Jobseekers, Employers, Keyword Analysis, Visit Duration and Error Analysis. Funnels showed where sessions ended, whilst the charts made search behavior, visit duration and errors easier to compare. The separation also made it possible to look at the service from the perspective of a jobseeker or employer without losing the shared overview. The purpose of the dashboard was not to fill a screen with numbers. It was to create one place where a discussion could begin with the same information. Which searches work? Where does the service fail? Which problem should be looked at first? ## Recommendations The analysis created several directions for improving the service: * Introduce more advanced filters for skills, industries and other search criteria. * Add CV building tools and templates so profiles become more useful to employers. * Prioritise specialised job titles more intelligently instead of relying too heavily on generic matches. * Explore AI assisted matching between jobseekers and employers. * Redesign the search interface and resolve language inconsistencies. These recommendations follow from the questions explored in the dashboard, but they still need to be tested. A filter may make searching easier, for example, but adding more controls can also make the interface harder to understand. The direction makes sense. The final solution still depends on what happens with actual users. ## Outcome and limitation The outcome was a shared analytical view that showed where users left the search flow, which keywords resulted in applications and where errors interrupted the experience. This gave us a clearer direction for improving the service. However, the project used mock data. I cannot claim that the findings represent how people actually use Jobbkompassen, and the recommendations should not be presented as proven solutions. The next step would be to use live behavior, compare devices and speak with users experiencing the same parts of the flow. Research can suggest one thing, but you never know for certain until it meets reality. --- # Archive (6 projects) - **Current status:** Archive - **Description:** Collection of finished smaller projects I stopped working on. ## Archive Collection of finished smaller projects I stopped working on. ### Helios Engine - Built a persona-based survey system using predefined demographics, personalities, and backgrounds. - Added switchable local gguf and GPU-accelerated PyTorch inference backends. - Processed responses into aggregated HTML reports with charts, tables, and individual persona results. - Configured personas, questions, models, and output through JSON and YAML, but paused development as early models lacked reliability. ### Music video editor based on stems - A web app that syncs audio with 2D/3D video elements, real-time shader effects, and beat-triggered sequence switching. - Features an integrated Python backend using Spleeter to split tracks into 4 independent stems (vocals, drums, bass, other) for isolation and signal-based triggers. - Includes audio waveform analysis, threshold detection, and video frame scanning tools for previewing, tweaking, and exporting. ### TypeGen - Built as an experiment to see how generated images transform frame by frame as textual context evolves in real time. - Local SDXL-Turbo to Flask so images render live as you type. - Added live prompt inputs, style presets, seed locking, and a video recorder to capture the visual transformations. ### HalalHostel - Bought halalhostel.com cheaply at auction and built a functional landing page in under an hour. - Created a credible home for the idea, linked the supporting Google document, and collected waitlist interest. - Contacted halal-friendly hostels around the world to validate supply and traveler interest. - Planned a searchable hub organized by hostels and destinations if demand proved strong; otherwise, the domain could be sold. ### Water plant app (Uni project) - I gathered quantitative user data through surveys to identify hydration habits among university students, defining target personas and prioritizing core features for a gamified water-tracking mobile app. - I designed an intuitive, minimalist UI in Figma that transforms daily water tracking into a rewarding habit by integrating virtual plant growth mechanics, streak rewards, and unlockable custom pots and seeds. - I structured the app layout according to established UX laws, using Miller's Law for low cognitive load in the shop, Hick's Law for a streamlined two-step planting flow, Fitts's Law for accessible bottom navigation, and Nielsen's 10 usability heuristics. - I developed the functional app prototype using React in short Agile cycles, iteratively refining the gamification system and user experience while balancing scope and technical requirements. ### ComfyUI workflows (local image generation) - A set of local image-generation workflows built around ComfyUI. - Focused on repeatable node graphs and controlled visual experiments. - Archived as a technical exploration.