Step by step process of building a personal website
By some stroke of luck, at the beginning of lockdown I found myself receiving incredible 1–1 content design classes from Amy Hupe. I wanted to try out some of the new things I was learning so decided to use some of the time freed up from commuting to create my own website where I could put the content learnings to practise. The idea was to use the things I’d learnt at work so far (predominantly user research skills), learn new skills (such as how to use sketch, write content, and buy a domain) and to do all the stages of building a website by myself (but with the help of many).
What were the challenges?
The main challenge was to get my head around how servers, domains, hosting services and things like bootstrap all connected together. In addition to this, I don’t have very much experience of writing HTML. I wanted to use this opportunity to understand a little bit more about how the internet works, practise HTML, whilst making something I can actually use to showcase my work.
Who were the users?
My users were myself and people who might want to work with me.
What I did
1. I started with some desk research
I looked at portfolio websites of various people, from facebook to design agencies, to government and NHSD. There’s so many ways of presenting oneself, and some were incredibly creative, some very aesthetic, some complex and others very simple. Once I had a wide look around, I started filtering the portfolios in the hope of zoning in a bit more.
I thought about what kind of work I liked > which companies and organisations did them > then looked for their employees’ portfolios.
This gave me a clearer understanding of where I wanted to head with my own.
2. I then identified my users and their needs
Whilst there are potentially many different types of users, I focused on the needs of myself as an user and the needs of someone who might be running a portfolio check on me during a job application. As I thought I knew what my needs were, I decided to concentrate on what the needs of someone who might be interested in working with me might be. So in true user centred design fashion, I conducted research to understand my users.
“Misaki” as the user:
- I want to exhibit the best of my ux and illustration skills
- I want to get hired for my work
- I want to express myself
“People who might want to work with me” as the user: Unknown
3. Writing a research plan and discussion guide
The focus of my research was to understand the process of someone looking to hire. I decided to take an informal approach to interviewing, so wrote 4 key questions I’d like to ask, and otherwise see where the conversation would go.
A very brief discussion guide
Q1. How would you first go about looking someone up? What would be your first steps- walk me through it please. Q2. What is the most important thing you’d like to find out about a person? Q3. What would you like to see first, followed by what, and then what? Q4.When seeing UX work, what do you want to see? And how?
4. Recruiting and Interviews
I recruited participants by contacting people I knew who were senior design professionals doing work that I really liked. I talked to Clara, a service designer from GDS who planned and facilitated amazing training sessions, and Caroline, a consultant who has worked on making many forms better all over the public sector. Both of them were very generous with their time and I interviewed them over Microsoft Teams, whilst taking handwritten notes.
5. Analysis
From my notes, I created bullet points of things Clara and Caroline said that related to content, and those that related to presentation. In the right column, you can see the top priority points, which were things both Clara and Caroline both mentioned. Followed by lower priority things that were still important. From this, I wrote up my user needs for someone who might want to hire me.
“People who might want to work with me” as the user:
- I need to be able to see the breadth of work misaki has done, but not everything.
- I need to know what, how and for who the work was done (and how- how much contribution there’s been)
- I need to see clear and concise messaging that misaki ticks off the criteria (key words)
- I need to see she can tell a story about the work she has done.
6. Based on the user needs I now had, I hand drew a wire frame.
7. From there, I recreated the prototype on sketch.
I had never used sketch before, but I found it very easy to use. It was like a kinder version of Adobe Illustrator. I posted it on twitter with variations of the home page to see what people liked the most. Based upon popular opinion, I went for option C (which was also my favourite).
I also asked my manager Eric Lamarca and my previous design manager David Hunter to critique the visual prototype. Based upon their feedback, I tweaked it.
8. At the same time I drafted up some words for my site.
The user needs helped me to make sure I used the right words and put them in the right places. I wrote the words on a separate google doc to the sketch prototype because at the time it allowed for easier editing, however in hindsight I wish I had written the content into the wire frame. The reason for this is because I found it difficult to find the right balance between the home page and the about me section. This mistake was pre-warned by Amy and yet I still had to make them to understand. I hope I won’t ever forget it!
9. Before building, I needed to understand (a little bit) how the internet works.
I talked to two friends, Adam Chrimes, a front-end developer from NHSD, and Cristobel from Hyperstudio to help me understand how the internet worked.
I cannot say I fully understand how domains, servers, and css frameworks relate to each other even after having built a website, however I found it helpful to think of a website as a house.
If the internet is the world, by buying a domain it’s like buying a patch of digital land. The server (is still a bit of a mystery to me) but i understand it as like a land registry. If I register my patch of digital land via a complicated looking online form, I can start building something in that patch of digital land.
In terms of the house itself, if I were a backend developer, I could decide myself how I would build the structure, pillars and shape of the house. If I could write javascript and the css myself then I’d be able to build a house on my patch of digital land that might look like this:
However, as I can only write HTML I need to use CSS frameworks like bootstrap which I understand to be like a pre-made houses. By writing HTML I can change the furnishings of the house, like where the windows go, what colour the door is etc. The repository hosting service is what puts my house (which I have made on my local mac) on the internet for anyone to see.
I used netlify for my server, purchased my domain from google domains and decided to use github as my repository hosting service. For my css framework I used bootstrap.
10. Building the website.
Once I was happy with the visual prototype, and had my domains and servers etc in place, I started building my website using bootstrap. It took a long time, and part way through I found I had made the website only compatible with desktop, so had to redo it all (I now understand why people say to use grids rather than tables). I’ve found that time literally melts away, and it was frustrating, but also very therapeutic!
11. Usability testing
When I was satisfied with my overall website I had built, I used twitter to ask whether anyone would be willing to spare 30 minutes of their time to usability test my website for me. Based on the research plan I had previously made I wrote up a rough discussion guide again for this round of testing.
Discussion guide
What do you know about me? How would you look up more information about me? [Ask participants to share screen and speak thoughts aloud] End: What is your impression of me after viewing my website? Was there anything missing that you would have expected?
I had 3 volunteers of which one was a content designer, one user researcher, and another who wasn’t an UCD practitioner but still with very relevant insights. As always with usability testing, there were so many things that I had missed. Here are a few of the things that came up, which I have divided into two lists. One is “quick fixes” versus the other I’ve named “Larger problems” which require more thinking on how to address them.
Quick fixes
- Typos
- Back button that goes to the wrong place
- Adding a sentence for “impact”
- Font changes in Edge browser
- More links
- Commission enquiry email
Larger problems
- Weighting of content in about me and homepage
- How to present this in hiring process
I was pleased to learn from my users that they felt the website was friendly, and easy to navigate. I also received a lot of positive feedback about sharing my processes (like this post).
I was challenged to think more about what context this website would be used within a hiring process. How much of this website caters to the needs of “misaki” as an user over the needs of other users.
12. Making changes based on the test results
Based upon the findings, I made changes to the website that were relatively easy fixes, and created a list of things I needed to address in the future.
Outcome: This website
Learning from this project
- I learnt the importance of integrating content design at the wireframe stage.
This might’ve helped me find the right balance between the pages much earlier. - I learnt that writing HTML was fun, and probably even more fun if I could learn the other coding languages.
- I think I would’ve benefitted if I spent more time at the start thinking about whether my need was for “misaki’s website” or “misaki’s online portfolio site”, as they feel like slightly different things. I assumed I knew what I wanted, so did not spend much time really investigating whether what I wanted was what I needed.
