-J.

tl;dr: learnt from my mistakes from DC3, better prototype (more screens), but not satisfied with how I displayed my design thinking.

I jumped onto Designercize again a couple days ago to try my hand at another brief. Since I’m working from home the next couple of weeks, I’ve brought my work computer home. It’s a fancy pants Toshiba that converts into a tablet and comes with a pen. I thought I’d try to use it to see if I could improve my rapid prototyping. After reading this post from Elaine Tran, I knew that I had to keep trying not matter how much I sucked.

I didn’t get a screenshot from Designercize this time, but as you can see I scrawled the brief onto the tablet. In case no one can read my terrible handwriting, here’s the brief:

DESIGN CHALLENGE

Design a Single Detail View for a Ticket Purchasing Site for Dog Walkers.

What follows are subsequent notes I took as worked through the design problem:

The Process

I start by defining the key question at hand: what use would dog walkers have for a ticket purchasing site?

Having learnt my lesson from DC3, I didn’t get stuck fleshing out a whole back story. I did however establish a narrative in my mind to frame the problem in such a way that I could design a solution for it. You can read that in the “User Research” screenshot above. Again, just in case my writing is too atrocious…

• dog walkers need to get “accredited” to walk dogs professionally.
• they need to access a website to book a course to become accredited.
• accreditation is for a particular area of town.

I wasn’t sure what a single detail view in the brief meant, so I Googled it. I came up with the following screenshot:

That cleared things up for me. I added the last dot point to tie the research back to the brief: the accreditation site has multiple locations in which you can get your licence. They didn’t have a clear design to help new dog walkers find the area in which they wanted to target. My job is to design that view.

Just like the last few times, I froze when it came to actually drawing screens. Determined, I pushed through and created the following screens:

Having the tablet helped with the rapid prototyping and overall, I’m happier with this than I was with my earlier screens. I get so hung up on this, but I need to keep reminding myself that it’s not necessarily about the screens but more so about the design thinking that led to the screens.

Musings

This is as far as I got before time ran out, but here are some subsequent thoughts I could have fleshed out:

• I specifically chose “check availability” instead of “purchase tickets”. The latter implies someone who’s further along the decision process and might deter potential dog walkers from actually signing up later. This microcopy can be tested.
• …On further thought, it could be better to scrap “check availability” altogether and list out dates and times for future accreditation. That way they can get more information from fewer clicks. Only problem here is that it might clutter the screen too much.
• I assumed that dog walkers would focus on areas near where they live. I designed the second screen with this in mind, building in GPS capabilities that would bring up a list of locations closest to you.
• Dog walkers can choose to get accredited for multiple areas if they so chose.

Closing Thoughts

• I’m glad I did this design challenge. I feel like I am getting better, but there’s room to improve. It’s still not structured as well as it could be.
• Despite me writing about it in earlier posts, I’m still not utilising the framework. I need to signpost and explicitly state the User Needs, User Goals, Assumptions and Constraints. It will force me to elucidate my thoughts, which in turn will produce a more thought out design.
• I need to try an actual person to work through an example with me on a whiteboard. That’s better than doing 10 of these by myself with only my brain as company. Getting that live feedback is priceless.
• If I don’t want to do that, I need to at least record myself talking through the solution as I build it in real time. While I won’t have the feedback, I have to get used to doing this when it’s crunch time.

tl;dr: weird design brief had me spending more time creating a fictional philosophy cafe than actually designing. Thus, I ran out of time.

When I fired up Designercize again, this was the first option that came up. I dragged my mouse over to the pink “RELOAD CHALLENGE” button on the left… but didn’t click. I thought to myself: I mean, that’s why they call it a design challenge, right? I’ve never done an actual design challenge, but who’s to say that there’s a “normal” style of design challenge? I bit the bullet and forged ahead.

In case the image is too small, this is the brief…

DESIGN CHALLENGE

Design an edit settings form for a book discovery app to help baristas.

I gave myself 45 minutes this time and started the clock.

Going from Design Challenge #2, I started with the question “what use would baristas have for a book discovery app?” Right off the top of my head, the answer was “none.” Note that this is barista, a person who makes and serves coffee at a cafe, not a barrister, which is a legal eagle. I dare say it would make more sense to design a book discovery app for barristers but anyway…

After racking my mind for five minutes, I found myself going down the route of turning this challenge into a chat with potential client. I was a UX consultant who had been called in by the founder of Beans & Books (BnB), a cafe that nourishes the mind with thought-provoking ideas from their favourite books. Below is the “interview”:

The Interview

Founder: Baristas play an integral part to the positive experience of the patrons. They don’t only take orders, make coffee and serve it all up with a smile. They are people too who come from all walks of life. We here at BnB (Beans & Books) not only look for people who have the ability to make great coffee but for those who are passionate about thinking.

Every day, we challenge our baristas to come up with a point of discussion from a book that they have read. Across a morning and afternoon session, they hold open-ended discussions that enrich the mind and promote deep thought. We’ve found that our concept has taken off over the past year and a half. Our sessions were consistently standing room only and people spread the word. Now, we’re at 10 stores and have plans to build our own app to share the thoughts of our Baristas anywhere, anytime.

(I realised that I started playing the role of the founder too long, so I hurried things along. Would definitely have helped having an actual person to speak to!)

Designer: So you asked me to help you design the first concept of an app. What big problem is it going to help your baristas solve?

Founder: We have 80 baristas all trying to come up with interesting topics to talk about. I thought having a book discovery app to help them share their ideas amongst them would help them stay on top of it instead of trying to do it themselves every week.

Designer: OK. What solutions have you tried to do this?

Founder: Not many. We tried Google Docs for a while, but it doesn’t work so well on smartphones.

Designer: Why is using smart phones important?

Founder: Because it allows them to take their ideas with them wherever they are. Whether they’re commuting on the way to BnB or at home.

Designer: OK. What do you think would happen if you didn’t have a solution to manage this?

Founder: We wouldn’t be able to consistently produce high quality talks for our patrons. Also, it’s important to me that they have their own network where they can lean on each other for ideas and inspiration.

Designer: So would they just find out about the books from each other or is there a feed from patrons or somewhere else online or…?

Founder: There have been already quite a few instances where our customers have provided the spark that has helped our baristas for a future talk.

Designer: Great. So the book discovery app would be used by your network of baristas at BnB to get inspired so they can give great talks based on the books that they have read. Patrons will be able to suggest books directly through the app to the baristas.

Founder: That’s right.

Designer: OK. So now I want to design a possible interaction. Through this, I’ll be able to understand the particular screens involved. *looks at different interviewer* can you be one of the baristas?

Barista: Sure can.

Designer: Thank you. OK, so can you walk me through how you plan for one of your talks?

Barista: Well, I usually start four or five days out. I look back at the books I’ve read and think about…

(Me: so I’m down to 8 minutes left. I’m going to skip forward and start looking at the Edit Settings screen itself, just so I have an actual design to show).

In the last 10 or so minutes, I hack out the below design:

Some notes:

• I put in the patron suggestions tick box to give the baristas an option to receive updates from book recommendations from customers. In hindsight, this makes more sense as a sliding switch, since a switch communicates turning something on or off. In this scenario, BnB would be getting a lot of user feedback and it would be like turning a tap on or off.
• I put tick boxes for genres, but the link to the core design isn’t strong. The way that I had envisioned the app was that baristas in the BnB network would share books with one another and get updates on those. Genres suggests that each book is categorised, but I didn’t touch on that in my interview because I ran out of time (more on that later).
• The “Sync with Amazon.com” is an afterthought that I added because it made sense at the time. Now, it doesn’t make so much sense. I just thought, when you think of “books”, what else do you think of? The big ‘Zon.

What Went Wrong

I got caught up creating the fictional BnB rather than actually designing. You’ll see in the above interview the notes in brackets where I realised I was going overtime. I ended up going over time and not spending nearly enough time looking at the important stuff, i.e. creating a design, asking more questions, outlining assumptions and calling out constraints. As a result, it ended up sucking again.

For what it’s worth, I think it’s slightly better than Design Challenge #2, but not by much. Admittedly, it’s not my fault. I went with a brief that was more difficult and spent too much time on the wrong thing. If I had someone who could act as the interviewer and create the scenario, I could actually focus on the design stuff.

What Next?

Doing these last couple of Design Challenges have been helpful. They’ve helped me identify my shortcomings, but have also pointed out constraints of my own as I’m trying to do these challenges. Namely…

• If I have someone to act as the interviewer, I can focus on doing the design stuff. Time to rope the missus in.
• In a timed situation, I’m slowed down by writing. I need to get my thoughts out on a whiteboard, so I might be doing this from home where I actually have a whiteboard.
• I learn best when I watch someone doing it first. I need to go to YouTube and see if there are videos of people doing real-time design challenges and how they approach it.
• I also need to see if there are any resources where I can look at best practice UX screens to help me decrease the time it takes to create a rough design. I don’t have that experience so it’s something I need to study up on.
• I might take out the initial part of of the Designercize brief so I can focus on the application at greater length. That, or find a different site to get my briefs from.

I mentioned in my last post that I wanted to sink my teeth into a real design challenge. So in my one hour dedicated to UX design on Wednesday, I went to Designercize.com. It’s a random design challenge generator, where it lets you reload random prompts, choose your level of difficulty and select the amount of time you want to give yourself to complete the challenge.

In reality I only had about 20 minutes spare, so that was the time limit I gave myself. I had a couple of goals:

• Practice going through a challenge under pressure and,
• Establish a framework for myself so when the shit hits the fan, I don’t freak out.

I’m going to outline the thoughts that went through my head in the order they bubbled up.

DESIGN CHALLENGE

Design a search results view for a scheduler app to help chefs.

Questions

As I felt my brain juices churning, questions began bubbling to the surface:

• What do chefs do? They cook!
• What’s hard about cooking? Managing cooking several meals at the same time during rush hour.
• What’s the worst case scenario? Messing up orders, putting an allergen into someone’s food and they die, meal is under-cooked anda they die.

That’s all I had written down on paper. I suppose they’re sensible questions to ask. One of the key goals of design is the make a user’s life easier. Asking what it is they do, what they struggle and what would be an absolute nightmare/worst case scenario makes sense. In hindsight and out of the pressure situation of the design challenge, there is a big question I missed: What use would a chef have for a scheduler app?

What I realised later was that my design lacked aim because I didn’t tie the user’s role back to the actual thing I was meant to be designing. The beauty of this question is that it encompasses nearly all of the above questions into it, forcing you to articulate an answer that addresses the role, their needs and their challenges that ties back to the solution itself.

With this realisation in hand, a possible answer to that question could be:

A chef needs to cook many dishes at the same time, especially in a big restaurant. When it’s the meal rush, it’s easy to make mistakes. The sort of mistakes he could make are: leaving food to cook for too long/not long enough, forgetting to take an allergen out or forgetting to make the dish altogether.

On top of this, chefs don’t necessarily cook dishes in chronological order. They would cook things based on what’s already on the stove and would be easier to increase the portion of. But this means that they have to make judgement calls about the priority of meals. Thus, it is easy to see that a scheduler app for chefs could be very helpful.

By simply rephrasing the question, I was forced to dissect the brief in a logical manner. What I liked about this is that it led to the validation of the app as a natural conclusion. While I did this all in my own head, doing this in front of a panel of interviewers gets them engaged on your thought process and scores you bonus points early on.

DO: phrase the question such that it ties back to the solution in the prompt and forces you to look at the situation logically, leading to a natural conclusion validating the app.

It becomes really easy to follow on from this initial question with another one that ties in the other part of the prompt: why would a search results view in the scheduler be useful? Admittedly, I didn’t think about this at all in my solution, which is why it bombed.

Problem Statement/User Goals

Help me ensure that meats are cooked to perfection in high pressure situations.

I just chucked this problem statement into my design after my questions because I felt it should have been there. I suppose it’s the natural progression from understanding the brief and validating it. Ideally, it should encapsulate the core problem you’re trying to solve (as understood from your questioning) and the progress that the user is trying to achieve.

I chose this as a problem statement because of the dangers of partially cooked chicken, steak, etc. I made a conscious decision to go with this direction but my downfall was that I didn’t tie it back strongly to my actual design. I specified meats but failed to show examples of situations in my design where my solution shines when applied to cooking multiple meat-based dishes.

After this, I scribble down some other random thoughts:

• The app would do better via a tablet screen versus a smartphone. Chefs need to be able to get information quickly and don’t have time to swipe through the dishes they are to cook. Also, it can be a hazard in the workplace if the smartphone falls into a pot of soup, etc.
• To solve this problem, chefs could be utilising these other solutions: have sous chefs to help them stay organised, other systems like those you see in McDonalds or the old-school paper option that a lot of places still use where they stick the order in a queue. What workflow failures would my solution alleviate? How does my solution work better? I didn’t think about this consideration.
• Edge cases: how are changes to orders handled? i.e. when customer makes changes to an order after they’ve placed it? How does this update in the system?
• Potential Improvements: Chefs’ hands are busy. Would the input be voice? A kitchen is noisy. If the input is touch, is there a hygiene problem?

I think the points are definitely valid, but the problem is that there was no rhyme or reason to my process. I needed to calmly and coherently step the interviewer through from beginning to end, but I needed to find a way to “store” my thoughts for later.

After about this point, I’m down to about 10 minutes (remember that I gave myself 20 minutes all up for this challenge). With my flimsy understanding of the brief, I proceed to start sketching out a solution (seen below).

I throw in a search bar because… the brief asks for a search bar. Below it, I write some food listings because… the key user is a chef and chefs cook. Safe to say that my screens won’t be winning any design awards any time soon.

I could make an excuse and say that I only had 20 minutes, but I know I could have done a lot better had I referred to the Whiteboard Design Challenge Framework that I referenced in my last blog post. If I had drawn up the four quadrants to begin with, my thoughts would have been organised a lot better.

Conclusion

What I’ve learned from this design challenge is:

• It’s really easy to be overwhelmed by the process of organising your thoughts. You NEED a structure to let put everything in the right place.
• Ask more questions in the beginning, user needs phase. Think of the parable of the blind men and the elephant. Every question helps you add a bit more until you can confidently articulate the user goal.
• Remember to ask the key question that ties the specific thing you’re designing back to the user. In this case, asking what a scheduler would help a chef achieve forces you to look at how success is defined, the real problems to be solved, etc.

I reckon I’ll shelve this design for the time being and move onto another one. I might revisit it after I’ve been around the block a few times and flesh it out in its entirety, but considering that I achieved my goals, I’m going to move forward.