Logan Rasmussen

Title

Goal: Goal here.

Paragraph.

Paragraph.

Research & empathise

Goal: Understand the requirements of the system.

It's important to understand existing user roles, key objectives and constraints before trying to design anything.

This application has a lot of procedures and terminology currently used by the forestry industry. I first had to understand the process, what players are involved and what the key objectives are. Luckily a comprehensive brief had been written because the clients were the subject matter experts and there’s no way to find this information anywhere else. I discovered that some of the functionality and user flows must follow existing government regulations. For example there's an existing forestry compliance grading system and colours that is used universally.

Analyse existing product

Goal: Understand the existing system and identify potential improvements.

The MVP has already been built, however the user interface was stock and had to be re-designed to allow users to easily navigate complex information in an intuitive and simple way. I started forming a hierarchy by breaking up tasks into steps, and considering each user's role.

Key Problems

• No navigation hierarchy.
• Lack of semiotics, icons etc
• No clear flow for activities e.g generate a report
• Analytics could be visually improved
• Home screen had a heavy load time
• Difficult to compare forest blocks
• Information overload - experience not broken up enough
• Big learning curve
• Some features requested didn’t necessarily reflect user stories

Key Solutions

• Designed Navigation hierarchy
• Designed svg based national view for lighter load time
• Designed concise analytics screen
• Looked into analytics based on user needs
• Made it easier to compare blocks
• Made clear flow forwards and added a way to go back
• Focused on making tasks more simple and use less real estate

Screen-shots of existing web app

Create UI foundations

Goal: Introduce visual hierarchy and structure to make the application easy to navigate.

In the older design users had difficulty navigating the app and there was no way to go back once a screen was entered. I redesigned the main navigation using standardised UI elements and built a quick low fidelity prototype to test it. At this stage everything was about functionality. Even colours were chosen to help communicate information faster.

I also considered they key user roles and which flows are more important for them. Some of the elements that were originally on the starting screen were moved to deeper levels in the navigation because they were not required at that stage in the user journey.

Refine style and functionality

Goal: Push the visual style further and make functional elements more concise.

The first iteration of the navigation worked okay, the clients were happy but I wasn’t completely satisfied that it was as good as it can get. Even though the task was accepted as complete I pushed it further. This really paid off.

Introduce new components

Goal: Design a final future state of the application based on remaining user flows.

There were only a few components built in MPV1. There were still many components that needed to be included. I started by designing universal elements such as form fields that would be required. Next I included the remaining components in the prototype based on the user flows. For example a form for submitting new forestry activity notifications.

Map the user journey

Our first key objective was to map the journey of one service as an example. We were designing a process for the service improvement team to follow long term. I soon discovered some possible improvements in our approach:

Goal: Build a tool that enables the service improvement team to easily map out all services and subjects within two years.

Key Problems

• It’s taking over 9 weeks to map one user journey.
• Making visual blueprints requires design skills that the Service Improvement Team doesn't have.
• Each workshop is followed by a significant amount of manual data entry.

Solutions

• Created a tool that automatically generates visual blueprints of the user journey.

Outcome

The tool was built using spreadsheets and formulas to pull data through and generate the final user journey map with conditional formatting. This made it easier to compare services and track the overall progress. The tool helped eliminate data entry and other time consuming tasks. The service improvement team was happy with the outcome. They could now focus more on improving services and spend less time processing everything.

The tool would also cut the estimated time it takes to map all 700 services down from 96 years to two years.

Understand the existing product

Once we understood the user roles we needed to research the job dispatch system. Our objective was to replace the software, many of the pain points we collected from users were seemingly caused by the software.

However when you look closer you can see that many issues were actually caused by how the information is structured within the system, rather than how it was built. We couldn’t simply solve the problem by replacing the software.

I looked at the data for the most used services in the organisation and found even more issues. 30% of service names in the system were not used for years and there were many duplicates. The Contact Center had to search through 700 services and subjects to file each job because there was no information hierarchy. Terminology wasn’t consistent across departments, everyone had different words for each stage of a jobs completion.

I believed that designing a universal system and categorising information could solve many of the problems and make migration to a new software product less messy. These problems that would appear to be solvable with software development could be solved with service design better.

Goal: Design a universal future state diagram for the job tracking system.

Key Problems

• Logging a job required users to select from a list of over 700 services.
• Service names were messy and there were many duplicates
• There were 50 different statuses to communicate the progress of jobs.
• Jobs often got sent to the wrong department.
• Tracking jobs was difficult.
• Our UX research found hundreds of pain points that were caused by the system.

Solutions

• Designed a hierarchy that splits jobs into states, statuses and steps instead of just status.
• Created a visual language for jobs to make it much easier and faster to use.
• Designed a future state blueprint that shows how any job can progress from start to finish and easily be tracked.
• Introduced some very simple automation work-flows to make the system more efficient.
• Created a ‘job card’ paper prototype so we could role-play the system.
• Used the paper prototype to validate the future state, job statuses and terminology worked better.

Outcome

The future state blueprint was a great document for communicating how the new system could work. It would also prove useful for migration as it simplified a complex system in a visual way that could be easily engineered. It also helped influence the new job statuses which made communicating and tracking jobs easier.

This triggered my project manager to actively solve problems in the system by creating a panel that would:
- Introduce new procedures for adding new services
- Simplify job status terminology
- Remove unused services form the system

We then worked together to validate and test changes to the system with the paper prototypes I created later on.

Compare existing products in the market

We started engaging other local governments to see what they were doing for job dispatch. None of them seemed to have a good solution in place and some had been developing tools for years with massive project budgets. We didn't have that much time. Our service architects gave us a list of viable software out on the market. I had a quick look at them all and felt as though none were a great fit for our user requirements. It took awhile for me to convince my team that doing a more in depth analysis of the solutions would benefit our project.

Goal: Make a visual comparison chart so that our organisation can approach the open procurement process well informed.

Key Problems

• None of the products were solving all of our user requirements.
• We had 17,000 users and per user licenses for some solutions were too high.
• Some products only covered one component of the software we were replacing.
• None of the products were designed specifically for local government services.
• Many products on the list were designed for sales.
• No other councils had good solutions in place either.
• We couldn’t possibly develop our own solution in house within the project time frame.
• We couldn’t engage development companies because of open procurement procedures.

Solutions

• Created a visual comparison chart to show everyone the differences.
• Compared product pricing for 17,000 users.
• Found that some solutions can cover one component well.
• Found that some solutions could work together as they have rest API.
• Researched how rest API and cloud services work.
• Looked where custom development such as customer facing forms could be easily and quickly built and integrated with solutions to be even more efficient.
• Found that using solutions together can significantly reduce license costs too.

I was given the go ahead to complete my research and finished the product comparison. Since I’m experienced in working for solution providers I understood our project in depth. I raised the problems with my team and explained how the solutions work in a simple way.

Outcome

Doing the product comparison paid off greatly. I helped my team solve problems that would occur later in the project cycle. I also knew enough about how rest API and cloud data services could help us solve the problems. At this stage my team almost had everything they needed to go into the procurement with confidence, with a much higher understanding of solutions. I felt proud that a lot of the work I pitched was eventually approved and became valuable assets to the project.

Prototype, test and validate the system

A low fidelity prototype would help test changes to the system, and develop a visual language to make it more effective. I was tasked to mock up what job cards could look like, a dashboard and eventually designed a concept for how input forms can work faster than selecting services from a list.

Goal: Create an early visual concept of a ‘future state’ system.

Key Problems

• Changes were being pitched for the system without a way to test and validate them.
• There was no visual language being used in the existing product.
• Many of the solutions we saw that were custom developed had a very clunky UI.

Solutions

• Designed mock ups of job cards.
• Created a visual system for job statuses.
• Categorised services and subjects into an easy to understand system.
• Used temporary icons to explore how visual communication can be more efficient when sorting processing a lot of information.
• Designed a user interface that was structured based on what users wanted to do intuitively.
• Designed a prototype that makes logging jobs more efficient for both public and contact center.

Outcome

The job cards and dashboard helped people understand the system more in depth, and ended up being useful assets. This gave our team and users a way to interact with the system before changes are rolled out.

Research

Goal: Understand the building consent process and online application form system

I brought myself up to scratch with the project so far, learned about how building consents work and started assessing the application form in question.

We were using an online application form that was being built and maintained by a third party. It didn’t quite integrate well with council services because they had their own help and support team, who would refer customers to our contact center. It was using pretty clunky development methods like bootstrap and jQuery. It had several security warnings when I inspected the form page. It wasn’t accessibility friendly, and I was surprised to find that local governments didn’t have to comply with government accessibility and security standards, that it was a guideline...

Despite all the issues I could see straight off the bat I put my UX hat on to let user testing data do the talking.

Map User Journey

Goal: Research the users experience with online application forms.

I adjusted my UX user journey mapping tool specifically for the building consent process. I went through the process myself and mapped out 72 steps from start to finish. This gave me a great structure for interviewing our different user roles. There were seven different user roles for the process.

Next, with help from the web team to find actual users to interview, I started collecting feedback. I added a layer of quantitative data to comments by splitting them into positive and negative, sometimes asking for a rating, or judging by the response. Sometimes people don’t need to be asked how painful a step in the process is because you can see it in their face, and there’s no need to disrupt the immersiveness of the interview.

I also conducted a few user testing sessions to see where people got stuck in the forms.

I compiled and assessed the UX research data, generating a visual map of the process from start to finish, so you can see where problems are occurring, and why.

List issues to fix

Goal: Compile a list of fixes for the web team.

I split the issues into types, some were content related and could be changed by the web team, others could be fixed by the form system, some were underlying issues in the process of communication channels. The UX mapping tool I made also handled this too, the lists were simply split into different sheets and sent along with the visual map so that everyone can understand the context.

Present to leadership team

Goal: Provide sufficient information for the leadership team to make a decision about resource consents

I presented the case study at the monthly leadership team meeting and a few guests from the building consent team.

Once I explained the process I went into a few other things to consider going forward and suggested a few paths.

Key Findings:

Limited Functionality: The current online system was designed specifically for building consents and lacked the necessary flexibility to accommodate the broader scope of resource consents.
Usability Issues: The user interface was found to be outdated and not user-friendly, leading to confusion and frustration for applicants.

Form web app structure

Goal: Create the foundations of the web app and design a navigation hierarchy.

I separated user stories into categories then designed a navigation that suits the core functionality. I started by designing on paper then created a final low-fi wireframe on screen for approval. I had to think about how things would be scalable and meet accessibility requirements.

Design aesthetic style

Goal: Develop a visual style and create a styleguide.

Clients were eager to get the visual style nailed early. Initially I took a functionality first approach but my first designs were considered too corporate looking. A more bright colourful UI was requested, I tried to use colours that would likely not be used for functional elements later.

Design functional elements

Goal: Design components that meet user needs.

We had a lot of creative freedom to design functional elements. Fascinatingly enough, my experience working in a basic hospitality job 10 years ago helped me design a better user experience. The product owners were the subject matter experts in management, but overlooked many other roles in hospitality. I helped design tools for managing stock levels in storage for example, a feature that third party clients eventually asked for. Some of the ideas I pitched were initially declined but later asked for by users and included.

Improve components

Goal: Finalise functional components.

Once components were approved we tested and iterated each design. The statistic dashboard was a good example of a section with many functional components.

Create wireframes

Goal: Create basic wireframes of the user interface.

I did research into UX layout and developed the main navigation. Mobile devices were particularly important because the website would be used during the event too.

Design website pages

Goal: Design the website based on existing print visual designs.

I designed the website’s visual components based on the style guide. There were many components that I had to design from scratch and make consistent with the style guide. I also had to make a few adjustments to meet the government's accessibility requirements.

Build Low fidelity prototype

Goal: Create a prototype so that clients can interact with pages and request changes before the website is built.

I designed and prototyped the functional elements so clients could see exactly what would be built. I did client demos every week to explain the interactions and get feedback on new features. We also had a constant flow of comments coming in from the clients if changes had to be made later.

Handover to developers

Goal: Enable developers to build the website quickly without confusion.

Since we were short on time and human resources, it was important to speed things up for the developers and assume whatever role was required. I wrote some CSS, sent emails, and ran social marketing. I had previously acquired these skills from using Mailchimp and running social marketing advertising campaigns for my small business clients.

Business planning

Goal: Create the foundations of how the business will operate

My first main focus was web design. In my business training class, several students were starting a business and needed a website. I was lucky to hit the ground running with several clients taking me on shortly after I started.

Design the business

Goal: Create a cohesive design business with a consistent brand.

Most of the work went into testing the market than the visual design.

I named the business Launch Design, I gave the business a space theme to help people understand and remember the business.

I came up with a name for the business based on what names were free. I used some online tools to research domain names, business names, and social accounts. The aim was to choose words that are not saturated in search and social media.

I didn’t want to spend too much time making the logo since I was more interested in the visual style and illustrations. I felt that a name and theme would carry more weight than a logo.

Outcome

The theme worked out well, it was easy to find the business by searching. Many of my clients came through my network anyway and just called me with unique problems to solve.

Complete design projects

Goal: Operate an effective design business and constantly improve over time.

As a business, I designed, built, and maintained search engine friendly websites for various clients. I often had to venture into marketing and search engine optimisation too. I branded several small businesses; this wasn’t my passion but good work often led to web-related projects.

On larger projects, I sometimes collaborated with friends working in my field or contracted junior designers. This enabled me to scale up any kind of project and speed things up for clients.

Outcome

Building up a network was the most powerful thing for business services in Wellington City. Each project I completed led to new opportunities. I also learned many new technical skills and became more efficient as a designer. I became known for solving problems and helping business owners avoid building unnecessary products.

Research

Goal: Understand Apollo 13 narrative and systems.

I didn’t expect my first design job out of university to involve rocket science. However, I was suddenly learning how the Saturn V rocket used cryogenic propellants to adjust course. I had to “design a screen for team BOOSTER to monitor fuel consumption so team FIDO could simulate the possible adjustment to trajectory using only the Lunar module”... exactly as they did in Apollo 13. This was to be interacted with using a replica 1970s control panel (which was before mouses, keyboards, or touch screens were a thing).

Project planning

Goal: Create a road-map for the project.

We designed one prototype interactive application and created time-line estimates based on it. We then designed how they fit into the Apollo 13 narrative. We wanted to emulate the original experience as much as possible, including making the audience use telephones to communicate important information.

Designing apps for the consoles

Goal: Design and test interactive apps for the replica 1970's console monitors.

Each designer would come up with an experience, pitch it to the team and then design it. I had additional roles: game designer and user experience tester. I formed a user testing group and ran weekly testing sessions.

Documenting & handover

Goal: Create a consistent project document for engineers to build apps.

We used online collaborative docs to document everything for engineers to build and Github to manage the project.

Handover between roles was generally smooth as the team worked well together. As a game designer, I helped create a hierarchy of complexity so that users would learn what to do without getting lost. One of the visual designers helped me improve my layouts. The engineers helped us bring realism into our designs. For example, instead of using arrow controls to simulate how the landing module approaches Earth, users had to enter an equation. It was great seeing our designs working; we didn’t have many prototyping tools, but our engineers coded our designs using Javascript, which was used directly for the consoles in the show.

Show trailer video

MDA Framework

Games are designed by creating rules that combine to create the experience, which influences the players' feelings. It’s a way of designing experiences with a functionality-first approach. A functionality-first approach is also the most powerful way to design products like websites and apps.

Mechanics are the rules, components and limitations that form to create the experience, like chess pieces and how they can move.

Dynamics are the experiential play that mechanics combine to create and that we engage with in real time. Kind of like strategies in chess to get a checkmate.

Aesthetics of play are the emotional responses players get while interacting with a game. Every game has a core aesthetic which is often the reason we play it. Almost any game can fit into the 8 categories listed below:

Sensation: Game as sense-pleasure
Fantasy: Game as make-believe
Narrative: Game as drama
Challenge: Game as obstacle course
Fellowship: Game as social framework
Discovery: Game as uncharted territory
Expression: Game as self-discovery
Submission: Game as pastime

Mechanics, Dynamics and Aesthetics (MDA), is a framework developed by Mark Deblank.

Flow Theory

Designing flow is about balancing user experiences so that users are not overwhelmed by too much information, or have too little and get bored. Flow theory is important in game design because it provides an optimum goal for balancing difficulty and controlling engagement. As the player’s skill increases, the difficulty needs to increase to keep the player engaged so that they don’t get bored. Likewise, if the difficulty spikes too high, the player may get stuck.

User flow is very important in UX design. If a user is given too much information at once or too many options, they can get lost and confused. However, if you break up the information too much, it could become tedious for long-time users to get things done. It’s crucial to find a good balance between on-boarding new users and making a system efficient for power users.

Visual Hierarchy

In games, visual language and hierarchy is used to guide players while still keeping them immersed. Rather than having an arrow flash up on screen, a door might be well-lit and of a certain colour, naturally drawing the player's attention.

You can use visuals to communicate information to users more efficiently because:

It’s faster to communicate than words
Complex systems can become simpler
Intuitively easier to remember
You can guide users with visual hierarchy
The experience can be more consistent

In web design, you can use visual hierarchy to make more important things stand out and keep the user engaged in the task they are trying to complete.

A good service design example of visual hierarchy is way-finding. One of the most impressive visual systems I’ve seen is the Shanghai metro system. I could find my way around without knowing a word of the local language.

Research

Goal: Explore the problem that the application is attempting to solve.

Research & design content

I researched the most important things that contribute to personal wellbeing and landed on 3 categories, each with 7 subjects.

Test content

You can validate if an application would add value to your target audience long before you design anything. To do this I ran people through the questions that the app would be asking. I recorded responses and notes in a spreadsheet. There was enough interest to run with this idea, and a few problems to solve too. I believe that some of these problems can be solved with design.

Design App

Make paper concepts

Designing everything on paper is faster than going straight to a screen.

Design visual style

Before getting into the apps structure I worked on the basic visual style. This will still be polished later but it gives me a good set of colours and visual elements to work with. I quickly blocked out icons and chose workable fonts.

Make grid & structure

I started fitting content into a grid and working on the visual hierarchy. I made everything into components in Figma so I can easily change things later. Now if I need to change an icon it will change all of the design screens at once.

Visualise data

One of my objectives was to explore how I can visualise data in creative ways. The planets are a way of illustrating this. Each planet represents a year of data, reflecting how well users looked after themselves. The goal is for users to be able to glance at the planet and understand this instantly.

I also explored using layers of visual information to communicate more to people that look closer. For example a new resident will be added to the planet for each entry. After the 52 weeks a planet will have 52 residents, each with unique character traits that reflect that week.

Many of these ideas would need to be tested and validated. I'm curious as to whether it would encourage people to have more athletic residents than passed out drunks on their planet.

I explored many ways of how the same data could be displayed and communicate different information. I'll need to test users on which information they find more important to design the best experience.

Create visual prototype

This is project was not taken further than the low fidelity prototyping stage.