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 a search results view for a scheduler app to help chefs.
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.
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.