UX Class & Case Study

I enrolled in the UI & UX for digital products course at Nashville Software School. It was a great experience for me. I got a taste of Agile, user interviews and digital design process.

I learned how to build a case study and how to frame a problem. I used interviews to see if what I thought was a problem really was something that needed to be fixed. Once I solidified my problem, I interviewed a few people and took that information to build my prototype and user persona.

This is a condensed version of my process. I have a full walkthrough of my UX Case Study on my portfolio.

My project

I proposed that people ran out of prescription pills and could use something to remind them to call the pharmacy before the bottle was empty. My resulting project was Medicine Minder an app that would send the user an alert to call the pharmacy when their prescription was low.

Wireframe

I sketched a basic paper prototype in a note book. It took several iterations to get everything I wanted on the design. Then I showed to some people got some feedback then I moved on to a wire frame.

Paper sketch to interactive prototype.

Prototype

I built a wire frame using the prototyping tool, UXpin. The interactive prototype allowed users to experience the proposed functions of the app. I was able to get feedback in person and online. The feedback helped to refine my concept.

OnBoarding screen

User receives an alert when the pill supply is calculated to be down to a few days supply.

Alert message to user.

Conclusion 

Studying UX has helped me focus my process. The idea that “You are Not the User” was repeated throughout the class. As a Designer I should focus on what the user’s needs are. They will be the one using a product daily, it’s their experience that matters.

Introduction To Open Source Event

Over the weekend I attended a introduction to Open Source class. The class was presented by Max Shenfield of Evenbrite and Nick Lorenson of Code for Nashville. Nick talked about what open source is and how best to contribute.

How to find, learn about, and meaningfully contribute to an open source project without being one of those people.

Hosted by Max Shenfield and Nick Lorenson.

No help is better than bad help

Nick opened the class by saying you need to build trust we a project’s maintainer before you just start pushing code.  Get to know the maintainers of the project, the project’s history and culture. Learn how the community likes stuff, why they do things the way they do. Use UX skills to determine what their standards are. Also get to know and be known in the project’s community by introducing yourself on their Slack or social media locations. 

By knowing the the community as people you can build trust. That way when you submit a pull request it is easier for them to know that you are reliable.

Nick’s example if you are going to rearrange a house get to know the person’s likes before you move stuff.  Don’t just jump in and totally rearrange everything or in his example set the house on fire.  You’ll get bad results. 

And now we Code,

Nick and Max had set up a faux Open Source project on GitHub. They assigned a few people to be project maintainers. The maintainers helped Max as the pull request started coming in. The rest of us split off into pairs. We forked the project and examined the code.

The project was a partially built Calculator with a list of know issues, or bugs, that need to be fixed. There were also unknown issues. My partner corrected a typo in the Readme file.

The teams claimed issues by commenting on the issues list. This prevented groups working on the same thing. We also used Slack for communication. My partner and I claimed an issue. We wanted to fix the subtraction function. We looked at the available code and figured out a solution. We built a test to confirm then submitted a pull request. Nick reminded the group to also add to the documentation. So we submitted an update to the readme file. Our pull requested was approved and our code added to the project.

We claimed another issue and went through similar steps to solve it. The issues were set up to be solvable in the allowed time. The idea of the project was to get introduced to Open source.  The issues were resolved and we got a taste of the Open source world.

It easier to contribute than you think.

“Even the smallest person can change the course of the future.”
– Galadriel

I learned I don’t have to reinvent the wheel to contribute to an OSS project. A project maintainer doesn’t necessarily want a massive change in code. They may just need some minor changes or documentation added. There may be some bug that they don’t have time to fix. You can help them by clearing some technical debt.

 

-$JarvisScript git push

/* Your Comments? */